From kohanews at gmail.com  Sat Jun  2 04:20:54 2018
From: kohanews at gmail.com (kohanews)
Date: Fri, 1 Jun 2018 19:20:54 -0700
Subject: [Koha-devel] Koha Community Newsletter: May 2018
Message-ID: <5d02fb07-d18f-bf5d-c5c8-0af8790566fc@gmail.com>

The Koha Community Newsletter for May 2018 is here:
https://koha-community.org/koha-community-newsletter-may-2018/

Many thanks to the folks who submitted articles and news to this month's 
newsletter.

Please feel free to email me with any corrections or suggestions.

Thanks!

-- 
Chad Roseburg
Editor, Koha Community Newsletter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180601/677eaafe/attachment.html>

From indradg at l2c2.co.in  Sat Jun  2 11:21:48 2018
From: indradg at l2c2.co.in (Indranil Das Gupta)
Date: Sat, 2 Jun 2018 14:51:48 +0530
Subject: [Koha-devel] Koha Community Newsletter: May 2018
In-Reply-To: <5d02fb07-d18f-bf5d-c5c8-0af8790566fc@gmail.com>
References: <5d02fb07-d18f-bf5d-c5c8-0af8790566fc@gmail.com>
Message-ID: <CAJ0y-De-shk6Z1oa3MLUhvx4A0wKdkixRWU4hAz2L0Dz-_B0xw@mail.gmail.com>

Hi Chad,

this probably needs a correction - wrong version mentioned in the
sub-section.

//Koha 17.11.05 Released

by Nick Clemens
The Koha community is proud to announce the release of 17.11.06. This is a
maintenance release and contains many bugfixes and enhancements.//

cheers
indranil



-- 
Indranil Das Gupta
L2C2 Technologies

Phone : +91-98300-20971
Blog    : http://blog.l2c2.co.in
IRC     : indradg on irc://irc.freenode.net
Twitter : indradg

On 2 June 2018 at 07:50, kohanews <kohanews at gmail.com> wrote:

> The Koha Community Newsletter for May 2018 is here:
> https://koha-community.org/koha-community-newsletter-may-2018/
>
> Many thanks to the folks who submitted articles and news to this month's
> newsletter.
>
> Please feel free to email me with any corrections or suggestions.
>
> Thanks!
>
> --
> Chad Roseburg
> Editor, Koha Community Newsletter
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180602/ccb6cdbe/attachment.html>

From oleonard at myacpl.org  Mon Jun  4 18:10:21 2018
From: oleonard at myacpl.org (Owen Leonard)
Date: Mon, 4 Jun 2018 12:10:21 -0400
Subject: [Koha-devel] Request for feedback: Bug 20779 - Style refresh
 for patron detail page
In-Reply-To: <CAJzKNY7KcdfVt9HoEHUg1PXBc5B7uD-Ti_7dOvO5Ko0XpmqpeQ@mail.gmail.com>
References: <CAO4qe2MvbT0nsMmORwp5XeMb77iLBDaMPUzFNK=HebtLg11HcA@mail.gmail.com>
	<CAMSJbVub97XmKJLUy0vyB54YLPd3jbBNtJgKMy8n3M2Hw8f9LQ@mail.gmail.com>
	<CAMHz3NiNmNCP4mJyEA2fPG1x_LNXveObn4tuTEfv5pV4LZqjpw@mail.gmail.com>
	<CAJzKNY7KcdfVt9HoEHUg1PXBc5B7uD-Ti_7dOvO5Ko0XpmqpeQ@mail.gmail.com>
Message-ID: <CAO4qe2PJnTbmAAevf-Aqoqt+uaktwXJbA0vJu+7AFuLHr3JQbw@mail.gmail.com>

If there is consensus that the add/edit buttons should be in line with
the section headings:

https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=75780

 -- Owen

From severine.queune at bulac.fr  Mon Jun  4 18:27:53 2018
From: severine.queune at bulac.fr (=?UTF-8?Q?S=C3=A9verine_Queune?=)
Date: Mon, 4 Jun 2018 18:27:53 +0200
Subject: [Koha-devel] Request for feedback: Bug 20779 - Style refresh
 for patron detail page
In-Reply-To: <CAO4qe2PJnTbmAAevf-Aqoqt+uaktwXJbA0vJu+7AFuLHr3JQbw@mail.gmail.com>
References: <CAO4qe2MvbT0nsMmORwp5XeMb77iLBDaMPUzFNK=HebtLg11HcA@mail.gmail.com>
	<CAMSJbVub97XmKJLUy0vyB54YLPd3jbBNtJgKMy8n3M2Hw8f9LQ@mail.gmail.com>
	<CAMHz3NiNmNCP4mJyEA2fPG1x_LNXveObn4tuTEfv5pV4LZqjpw@mail.gmail.com>
	<CAJzKNY7KcdfVt9HoEHUg1PXBc5B7uD-Ti_7dOvO5Ko0XpmqpeQ@mail.gmail.com>
	<CAO4qe2PJnTbmAAevf-Aqoqt+uaktwXJbA0vJu+7AFuLHr3JQbw@mail.gmail.com>
Message-ID: <CAMHz3NiSo0vAEKUBE8R+wbLXcnyf14N6Ctd__zaofY5iaF=EgQ@mail.gmail.com>

I like that one !

2018-06-04 18:10 GMT+02:00 Owen Leonard <oleonard at myacpl.org>:

> If there is consensus that the add/edit buttons should be in line with
> the section headings:
>
> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=75780
>
>  -- Owen
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 

*S?verine QUEUNE*
Administrateur fonctionnel du SIGB
?quipe signalement et exposition des donn?es
P?le Flux et donn?es


<https://www.youtube-nocookie.com/embed/myZ2K_alngw>
[image: Logo BULAC]

Biblioth?que universitaire
des langues et civilisations


65 rue des Grands Moulins
F-75013 PARIS
T +33 1 81 69 *18 55*
www.bulac.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180604/ebbbf8c5/attachment.html>

From katrin.fischer.83 at web.de  Mon Jun  4 20:20:18 2018
From: katrin.fischer.83 at web.de (Katrin Fischer)
Date: Mon, 4 Jun 2018 20:20:18 +0200
Subject: [Koha-devel] Request for feedback: Bug 20779 - Style refresh
 for patron detail page
In-Reply-To: <CAMHz3NiSo0vAEKUBE8R+wbLXcnyf14N6Ctd__zaofY5iaF=EgQ@mail.gmail.com>
References: <CAO4qe2MvbT0nsMmORwp5XeMb77iLBDaMPUzFNK=HebtLg11HcA@mail.gmail.com>
	<CAMSJbVub97XmKJLUy0vyB54YLPd3jbBNtJgKMy8n3M2Hw8f9LQ@mail.gmail.com>
	<CAMHz3NiNmNCP4mJyEA2fPG1x_LNXveObn4tuTEfv5pV4LZqjpw@mail.gmail.com>
	<CAJzKNY7KcdfVt9HoEHUg1PXBc5B7uD-Ti_7dOvO5Ko0XpmqpeQ@mail.gmail.com>
	<CAO4qe2PJnTbmAAevf-Aqoqt+uaktwXJbA0vJu+7AFuLHr3JQbw@mail.gmail.com>
	<CAMHz3NiSo0vAEKUBE8R+wbLXcnyf14N6Ctd__zaofY5iaF=EgQ@mail.gmail.com>
Message-ID: <ddb0cffc-f229-a4de-db2a-f776f67f70f1@web.de>

+1 !

:)

On 04.06.2018 18:27, S?verine Queune wrote:
> I like that one !
>
> 2018-06-04 18:10 GMT+02:00 Owen Leonard <oleonard at myacpl.org 
> <mailto:oleonard at myacpl.org>>:
>
>     If there is consensus that the add/edit buttons should be in line with
>     the section headings:
>
>     https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=75780
>     <https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=75780>
>
>     ?-- Owen
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at lists.koha-community.org>
>     http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>     <http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel>
>     website : http://www.koha-community.org/
>     git : http://git.koha-community.org/
>     bugs : http://bugs.koha-community.org/
>     <http://bugs.koha-community.org/>
>
>
>
>
> -- 
> *
> *
> *S?verine QUEUNE*
> Administrateur fonctionnel du SIGB
> ?quipe signalement et exposition des donn?es
> P?le Flux et donn?es
>
>
> <https://www.youtube-nocookie.com/embed/myZ2K_alngw>
> Logo BULAC
> Biblioth?que universitaire
> des langues et civilisations
>
>
> 65 rue des Grands Moulins
> F-75013 PARIS
> T +33 1 81 69 *18 55*
> www.bulac.fr <http://www.bulac.fr>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180604/7811dbd6/attachment-0001.html>

From barton at bywatersolutions.com  Mon Jun  4 20:23:03 2018
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Mon, 4 Jun 2018 14:23:03 -0400
Subject: [Koha-devel] Request for feedback: Bug 20779 - Style refresh
 for patron detail page
In-Reply-To: <ddb0cffc-f229-a4de-db2a-f776f67f70f1@web.de>
References: <CAO4qe2MvbT0nsMmORwp5XeMb77iLBDaMPUzFNK=HebtLg11HcA@mail.gmail.com>
	<CAMSJbVub97XmKJLUy0vyB54YLPd3jbBNtJgKMy8n3M2Hw8f9LQ@mail.gmail.com>
	<CAMHz3NiNmNCP4mJyEA2fPG1x_LNXveObn4tuTEfv5pV4LZqjpw@mail.gmail.com>
	<CAJzKNY7KcdfVt9HoEHUg1PXBc5B7uD-Ti_7dOvO5Ko0XpmqpeQ@mail.gmail.com>
	<CAO4qe2PJnTbmAAevf-Aqoqt+uaktwXJbA0vJu+7AFuLHr3JQbw@mail.gmail.com>
	<CAMHz3NiSo0vAEKUBE8R+wbLXcnyf14N6Ctd__zaofY5iaF=EgQ@mail.gmail.com>
	<ddb0cffc-f229-a4de-db2a-f776f67f70f1@web.de>
Message-ID: <CAMSJbVsKYnMBrL-_GF8y6eX_E4GWAgQ7iFewfEFo5gt_M3bzpQ@mail.gmail.com>

+1


On Mon, Jun 4, 2018 at 2:20 PM, Katrin Fischer <katrin.fischer.83 at web.de>
wrote:

> +1 !
>
> :)
>
>
> On 04.06.2018 18:27, S?verine Queune wrote:
>
> I like that one !
>
> 2018-06-04 18:10 GMT+02:00 Owen Leonard <oleonard at myacpl.org>:
>
>> If there is consensus that the add/edit buttons should be in line with
>> the section headings:
>>
>> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=75780
>>
>>  -- Owen
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>
>
>
> --
>
> *S?verine QUEUNE*
> Administrateur fonctionnel du SIGB
> ?quipe signalement et exposition des donn?es
> P?le Flux et donn?es
>
>
> <https://www.youtube-nocookie.com/embed/myZ2K_alngw>
> [image: Logo BULAC]
>
> Biblioth?que universitaire
> des langues et civilisations
>
>
> 65 rue des Grands Moulins
> F-75013 PARIS
> T +33 1 81 69 *18 55*
> www.bulac.fr
>
>
> _______________________________________________
> Koha-devel mailing listKoha-devel at lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180604/4fffde30/attachment.html>

From tomascohen at gmail.com  Tue Jun  5 03:00:25 2018
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Mon, 4 Jun 2018 22:00:25 -0300
Subject: [Koha-devel] Request for feedback: Bug 20779 - Style refresh
 for patron detail page
In-Reply-To: <CAMSJbVsKYnMBrL-_GF8y6eX_E4GWAgQ7iFewfEFo5gt_M3bzpQ@mail.gmail.com>
References: <CAO4qe2MvbT0nsMmORwp5XeMb77iLBDaMPUzFNK=HebtLg11HcA@mail.gmail.com>
	<CAMSJbVub97XmKJLUy0vyB54YLPd3jbBNtJgKMy8n3M2Hw8f9LQ@mail.gmail.com>
	<CAMHz3NiNmNCP4mJyEA2fPG1x_LNXveObn4tuTEfv5pV4LZqjpw@mail.gmail.com>
	<CAJzKNY7KcdfVt9HoEHUg1PXBc5B7uD-Ti_7dOvO5Ko0XpmqpeQ@mail.gmail.com>
	<CAO4qe2PJnTbmAAevf-Aqoqt+uaktwXJbA0vJu+7AFuLHr3JQbw@mail.gmail.com>
	<CAMHz3NiSo0vAEKUBE8R+wbLXcnyf14N6Ctd__zaofY5iaF=EgQ@mail.gmail.com>
	<ddb0cffc-f229-a4de-db2a-f776f67f70f1@web.de>
	<CAMSJbVsKYnMBrL-_GF8y6eX_E4GWAgQ7iFewfEFo5gt_M3bzpQ@mail.gmail.com>
Message-ID: <CABZfb=W77G8ZRuStgbk+Z58Q0JT616AAVRD46v28ccVwK14Q_A@mail.gmail.com>

+1

El lun., 4 de jun. de 2018 3:23 p. m., Barton Chittenden <
barton at bywatersolutions.com> escribi?:

> +1
>
>
> On Mon, Jun 4, 2018 at 2:20 PM, Katrin Fischer <katrin.fischer.83 at web.de>
> wrote:
>
>> +1 !
>>
>> :)
>>
>>
>> On 04.06.2018 18:27, S?verine Queune wrote:
>>
>> I like that one !
>>
>> 2018-06-04 18:10 GMT+02:00 Owen Leonard <oleonard at myacpl.org>:
>>
>>> If there is consensus that the add/edit buttons should be in line with
>>> the section headings:
>>>
>>> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=75780
>>>
>>>  -- Owen
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at lists.koha-community.org
>>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>> website : http://www.koha-community.org/
>>> git : http://git.koha-community.org/
>>> bugs : http://bugs.koha-community.org/
>>>
>>
>>
>>
>> --
>>
>> *S?verine QUEUNE*
>> Administrateur fonctionnel du SIGB
>> ?quipe signalement et exposition des donn?es
>> P?le Flux et donn?es
>>
>>
>> <https://www.youtube-nocookie.com/embed/myZ2K_alngw>
>> [image: Logo BULAC]
>>
>> Biblioth?que universitaire
>> des langues et civilisations
>>
>>
>> 65 rue des Grands Moulins
>> F-75013 PARIS
>> T +33 1 81 69 *18 55*
>> www.bulac.fr
>>
>>
>> _______________________________________________
>> Koha-devel mailing listKoha-devel at lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-- 
Tom?s Cohen Arazi
Theke Solutions (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180604/4fa98cfe/attachment-0001.html>

From bob at calyx.net.au  Tue Jun  5 04:11:33 2018
From: bob at calyx.net.au (Bob Birchall)
Date: Tue, 5 Jun 2018 12:11:33 +1000
Subject: [Koha-devel] Request for feedback: Bug 20779 - Style refresh
 for patron detail page
In-Reply-To: <CABZfb=W77G8ZRuStgbk+Z58Q0JT616AAVRD46v28ccVwK14Q_A@mail.gmail.com>
References: <CAO4qe2MvbT0nsMmORwp5XeMb77iLBDaMPUzFNK=HebtLg11HcA@mail.gmail.com>
	<CAMSJbVub97XmKJLUy0vyB54YLPd3jbBNtJgKMy8n3M2Hw8f9LQ@mail.gmail.com>
	<CAMHz3NiNmNCP4mJyEA2fPG1x_LNXveObn4tuTEfv5pV4LZqjpw@mail.gmail.com>
	<CAJzKNY7KcdfVt9HoEHUg1PXBc5B7uD-Ti_7dOvO5Ko0XpmqpeQ@mail.gmail.com>
	<CAO4qe2PJnTbmAAevf-Aqoqt+uaktwXJbA0vJu+7AFuLHr3JQbw@mail.gmail.com>
	<CAMHz3NiSo0vAEKUBE8R+wbLXcnyf14N6Ctd__zaofY5iaF=EgQ@mail.gmail.com>
	<ddb0cffc-f229-a4de-db2a-f776f67f70f1@web.de>
	<CAMSJbVsKYnMBrL-_GF8y6eX_E4GWAgQ7iFewfEFo5gt_M3bzpQ@mail.gmail.com>
	<CABZfb=W77G8ZRuStgbk+Z58Q0JT616AAVRD46v28ccVwK14Q_A@mail.gmail.com>
Message-ID: <efa13069-6241-dc9c-0181-d3fa4369ecb3@calyx.net.au>

Beautiful :)

On 05/06/18 11:00, Tomas Cohen Arazi wrote:
> +1
>
> El lun., 4 de jun. de 2018 3:23 p. m., Barton Chittenden 
> <barton at bywatersolutions.com <mailto:barton at bywatersolutions.com>> 
> escribi?:
>
>     +1
>
>
>     On Mon, Jun 4, 2018 at 2:20 PM, Katrin Fischer
>     <katrin.fischer.83 at web.de <mailto:katrin.fischer.83 at web.de>> wrote:
>
>         +1 !
>
>         :)
>
>
>         On 04.06.2018 18:27, S?verine Queune wrote:
>>         I like that one !
>>
>>         2018-06-04 18:10 GMT+02:00 Owen Leonard <oleonard at myacpl.org
>>         <mailto:oleonard at myacpl.org>>:
>>
>>             If there is consensus that the add/edit buttons should be
>>             in line with
>>             the section headings:
>>
>>             https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=75780
>>
>>             ?-- Owen
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180605/d8143d69/attachment.html>

From arouss1980 at gmail.com  Thu Jun  7 09:21:58 2018
From: arouss1980 at gmail.com (Andreas Roussos)
Date: Thu, 7 Jun 2018 10:21:58 +0300
Subject: [Koha-devel] Staff/OPAC ISBD views and subfield visibility
Message-ID: <CAK0RUrtUaS4hMCHHa1Jm7ZztnHUAMAv+Kg__Vd7sG6WoiuGPvw@mail.gmail.com>

Dear Developers,

If you:

1) edit the ISBD and OPACISBD system preferences so that they contain the
following code:

#453| - translated as: |<a href="/cgi-bin/koha/catalogue/
detail.pl?biblionumber={4530}">{453t}</a> {(453d)}|
#454| - translation of: |<a href="/cgi-bin/koha/catalogue/
detail.pl?biblionumber={4540}">{454t}</a> {(454d)}|

2) set the visibility of (UNIMARC) fields 453$0 and 454$0 to 'hidden' in
the OPAC

...then the generated links will work fine in the Staff client but will be
broken in the OPAC (i.e. the URL will not include the biblionumber
contained in subfield 0 of fields 453/454).

I've tracked this down to ISBDdetail.pl and opac-ISBDdetail.pl calling the
GetISBDView subroutine, which (for some reason) excludes subfields that are
hidden in the OPAC:

https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L773-L776
https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L812-L815

What is the reasoning behind this?
In other words, why is _OPAC_ subfield visibility taken into account when
displaying the OPAC ISBD view (whereas visibility in Staff is not
considered)?

If anything, it is more likely to have subfield 0 hidden in OPAC, while
visible in Staff, so one would expect the opposite logic.

Thanks in advance for your time.

Kind regards,
Andreas Roussos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180607/a64773cd/attachment.html>

From nick at bywatersolutions.com  Thu Jun  7 19:47:53 2018
From: nick at bywatersolutions.com (Nick Clemens)
Date: Thu, 7 Jun 2018 13:47:53 -0400
Subject: [Koha-devel] Cronjob to run plugin cronjobs?
Message-ID: <CAA_eX3O1s6LNb4AKVgurUj61jWrpD-EN--gABUm3Kh=jthdwXw@mail.gmail.com>

Just an idea I had an bounced off Kyle, he suggested sending it out for
feedback, let us knwo what you think:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20897
-- 
Nick Clemens
Sonic Screwdriver (Development Support)
ByWater Solutions
IRC: kidclamp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180607/b35bd274/attachment.html>

From tomascohen at gmail.com  Thu Jun  7 19:57:17 2018
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 7 Jun 2018 14:57:17 -0300
Subject: [Koha-devel] Cronjob to run plugin cronjobs?
In-Reply-To: <CAA_eX3O1s6LNb4AKVgurUj61jWrpD-EN--gABUm3Kh=jthdwXw@mail.gmail.com>
References: <CAA_eX3O1s6LNb4AKVgurUj61jWrpD-EN--gABUm3Kh=jthdwXw@mail.gmail.com>
Message-ID: <CABZfb=Ueqw6m+0p8QwAuugmdRspKyDywdTDDPs9pS3AuT6J+4g@mail.gmail.com>

I would think it the other way around: why not trigger actions by hitting
URLs with POST?

El jue., 7 de jun. de 2018 2:48 p. m., Nick Clemens <
nick at bywatersolutions.com> escribi?:

> Just an idea I had an bounced off Kyle, he suggested sending it out for
> feedback, let us knwo what you think:
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20897
> --
> Nick Clemens
> Sonic Screwdriver (Development Support)
> ByWater Solutions
> IRC: kidclamp
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-- 
Tom?s Cohen Arazi
Theke Solutions (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180607/2ce78019/attachment.html>

From dcook at prosentient.com.au  Fri Jun  8 03:18:53 2018
From: dcook at prosentient.com.au (David Cook)
Date: Fri, 8 Jun 2018 11:18:53 +1000
Subject: [Koha-devel] Cronjob to run plugin cronjobs?
In-Reply-To: <CAA_eX3O1s6LNb4AKVgurUj61jWrpD-EN--gABUm3Kh=jthdwXw@mail.gmail.com>
References: <CAA_eX3O1s6LNb4AKVgurUj61jWrpD-EN--gABUm3Kh=jthdwXw@mail.gmail.com>
Message-ID: <0f6e01d3fec6$a9ec1f00$fdc45d00$@prosentient.com.au>

This kind of thing has been discussed periodically over the years but it never really gets anywhere.

 

I think using cron might be shoehorning things a bit. Cron is great for packaged routine cronjobs and system administration stuff, but for application workloads? I?m not so sure. What about Celery (http://www.celeryproject.org/) or Gearman (http://gearman.org/) or some other job server?

 

For https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662, I actually wrote my own job server using POE::Component::JobQueue (https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html <https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=10662&attachment=71008> &bug=10662&attachment=71008). (Originally, I wrote a generic job/task server for all of Koha but then I figured I was trying to be all things to all people, so I scrapped that idea and just made my OAI-PMH harvester daemon deal with OAI-PMH tasks/jobs. 

 

In my code, I actually have 2 job queues. The 1st queue is actually in the MySQL database, and the daemon polls the database to finds import jobs. It?s not the best solution, but I think I wanted a certain amount of persistence to that queue and to interrogate the data without talking to the job server. The 2nd queue is an in-memory queue. The Koha web user sends a message to the daemon telling it to down from an OAI-PMH server, the job server enqueues the job, and then a predetermined number of workers are forked to do the work of N jobs. 

 

Oh I also made the queue workers pluggable so that it was easy to make workers do whatever. I just made sure they had a run() method that expected certain arguments from the job server. After that, worker plugins were free to do whatever they needed to do. 

 

Anyway, that?s just my 2 cents.  Cron is a tried and true job scheduler for sure? but I don?t think it is the be all and end all. (If you do go with 1 cronjob to rule them all, you?ll need to think about locking, so that long-running cronjobs don?t end up clobbering each other and generally creating havoc. 

 

I was looking for more resources on task queues when I actually found this: ?A cron job makes an HTTP GET request to a URL as scheduled. The handler for that URL executes the logic when it is called.? https://cloud.google.com/appengine/docs/standard/python/config/cron. This doesn?t look like a true ?cron? job either though. It looks like a custom scheduler running for the App Engine. But I see how they contrast those regularly scheduled ?cron? jobs versus a task queue (https://cloud.google.com/appengine/docs/standard/python/taskqueue/) although Google?s implementation uses ?due dates? to let you do a one-off type of scheduling. 

 

Ultimately, it depends on how fine grained you want things to be. I suppose you could have cronjobs set up daily, hourly, monthly, and weekly (using cron.daily/cron.hourly/cron.monthly/cron.weekly? although I think some OSes use anacron for some of these?) and then have those poll the Koha database for a ?cron? table where plugins and such can configure jobs. I mean? it would be the ?lighest touch?. Like I said above,you?d want to think about locking, but other than that? it would work. 

 

Maybe a mix of all the above?

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Nick Clemens
Sent: Friday, 8 June 2018 3:48 AM
To: Koha Devel <koha-devel at lists.koha-community.org>
Subject: [Koha-devel] Cronjob to run plugin cronjobs?

 

Just an idea I had an bounced off Kyle, he suggested sending it out for feedback, let us knwo what you think:

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20897

-- 

Nick Clemens

Sonic Screwdriver (Development Support)

ByWater Solutions

IRC: kidclamp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180608/450f6c79/attachment.html>

From dcook at prosentient.com.au  Fri Jun  8 06:01:00 2018
From: dcook at prosentient.com.au (David Cook)
Date: Fri, 8 Jun 2018 14:01:00 +1000
Subject: [Koha-devel] CSS issue in Ordering information on
	/cgi-bin/koha/acqui/supplier.pl
Message-ID: <0fdf01d3fedd$4fe71c50$efb554f0$@prosentient.com.au>

I haven't checked master yet, but in the 17.xx versions, I'm noticing it is
really difficult to click the dropdown for "List prices are:" in "Ordering
information" on /cgi-bin/koha/acqui/supplier.pl.

 

When I look using the F12 tools in Chrome, I see that later "ol" elements
are overlapping earlier "li" elements. So the "ol" for the tax options is
sitting on top of the "li" for "List prices are:". Only a tiny part of the
"li" is clickable underneath that "ol". 

 

It looks like the floats in the "li" element are causing the sizing of the
"ol" to be no good. See
https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Block_formatting_cont
ext. 

 

There are a number of strategies for fixing this but I'm not sure what the
best one would be here.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180608/8d4e0354/attachment-0001.html>

From kohadevel at agogme.com  Mon Jun 11 17:38:58 2018
From: kohadevel at agogme.com (Thomas Dukleth)
Date: Mon, 11 Jun 2018 15:38:58 -0000
Subject: [Koha-devel] Add your KohaCon19 Hosting Proposal to wiki
In-Reply-To: <0fdf01d3fedd$4fe71c50$efb554f0$@prosentient.com.au>
References: <0fdf01d3fedd$4fe71c50$efb554f0$@prosentient.com.au>
Message-ID: <775aed025f4cad9fd60b55f368502ca4.squirrel@wmail.agogme.com>

Anyone who would like to host KohaCon19 (international Koha conference to
be held in 2019) should add some brief information about their proposal to
the proposals summary table in the page on the Koha Wiki which has been
prepared following the model used for previous KohaCons,
http://wiki.koha-community.org/wiki/KohaCon19_Proposals and for which
there is already a proposal from Stockholm University Library.  At the 6
June 2018 Koha General IRC meeting, people concluded that we should
solicit bids June to 1 August 2018.

Please link your summary proposal to a more detailed proposal preferably
in a new page on the Koha wiki or alternately hosted on your own
webserver.

If you have submitted a proposal for hosting KohaCon in the past but had
not been selected, please submit a new proposal if you are interested in
hosting KohaCon19.  Do not be discouraged that some other proposal had
been selected over yours in some previous year.  [In the interest of
promoting regional diversity in Koha, we have rules against selecting
KohaCon proposals from the same contintent within three years in case the
most populous regions might come to excessively dominate voting for
selecting a proposal.  The rule would be set aside for a particular year
if no proposal from a different continent has been introduced.  See
https://wiki.koha-community.org/wiki/Processes_for_KohaCons .]

Anyone should be free to add additional relevant information to proposal
information in the wiki, such as links and information for local hotel or
other accommodations, attractions, etc.  We want whatever information may
be helpful for linking to a community wide ballot for selecting a
particular proposal.

As with all wiki content, it should be easy enough to edit by examining
the form in which pre-existing content has been entered, when editing to
add your own content.  If you want more information about MediaWiki
tables, see http://www.mediawiki.org/wiki/Help:Tables .


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783



From philippe.blouin at inlibro.com  Tue Jun 12 17:41:59 2018
From: philippe.blouin at inlibro.com (Philippe Blouin)
Date: Tue, 12 Jun 2018 11:41:59 -0400
Subject: [Koha-devel] Cannot upgrade DB from 16.05 to 18.05.00. Solid crash
 and burn in updatedatabase.pl
Message-ID: <ef2a420c-b5f6-dd07-e067-e4ea2c4defaf@inlibro.com>

Hol?!

Currently migrating some 3.0 DB to 18.05.? A single hiccup with 
message_transport, no biggie.? Until...

16.06.00.042

Upgrade to 16.06.00.041 done (Bug 14629 - Add aggressive ISSN matching 
feature equivalent to the aggressive ISBN matcher)
DBD::mysql::st execute failed: Unknown column 'me.p_sep_by_space' in 
'field list' [for Statement "SELECT `me`.`currency`, `me`.`symbol`, 
`me`.`isocode`, `me`.`timestamp`, `me`.`rate`, `me`.`active`, 
`me`.`archived`, `me`.`p_sep_by_space` FROM `currency` `me` WHERE ( 
`active` = ? )" with ParamValues: 0=1] at 
/usr/local/share/perl/5.24.1/DBIx/Class/Storage/DBI.pm line 1836.
DBIx::Class::Storage::DBI::_dbh_execute(): Unknown column 
'me.p_sep_by_space' in 'field list' at 
/inlibro/git/koha-csf-prod-inlibro/Koha/Objects.pm line 209

Basically, the update code uses Koha::Number::Price, which in full 
modern object mode goes for its newly added *p_sep_by_space* _in the 
18.05 code_.? But the DB doesn't have it yet (it comes with 17.12.00.022).

Big crash big time.? The process stops.

Any workaround? (didn't see anything in the list, nor bugzilla, did I 
miss it?).

Thanks,

PS this is bound to happen whenever Koha objects are used in 
updatedatabase.pl.

-- 
Philippe Blouin,
Responsable du d?veloppement informatique

T?l.??: (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180612/91931bf7/attachment.html>

From jonathan.druart at bugs.koha-community.org  Tue Jun 12 17:55:17 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Tue, 12 Jun 2018 12:55:17 -0300
Subject: [Koha-devel] Cannot upgrade DB from 16.05 to 18.05.00. Solid
 crash and burn in updatedatabase.pl
In-Reply-To: <ef2a420c-b5f6-dd07-e067-e4ea2c4defaf@inlibro.com>
References: <ef2a420c-b5f6-dd07-e067-e4ea2c4defaf@inlibro.com>
Message-ID: <CAJzKNY7hbvJmQzyyDocJ9v_h43SEcPNtbyBsDQrhyo2v8wCp1Q@mail.gmail.com>

It's a bug, please open a new bug report.
Indeed we should not use Koha::Object packages during the update database
process, they are using the DBIx::Class schema. It's in the coding
guidelines already ;)


On Tue, 12 Jun 2018 at 12:41 Philippe Blouin <philippe.blouin at inlibro.com>
wrote:

> Hol?!
>
> Currently migrating some 3.0 DB to 18.05.  A single hiccup with
> message_transport, no biggie.  Until...
>
> 16.06.00.042
>
> Upgrade to 16.06.00.041 done (Bug 14629 - Add aggressive ISSN matching
> feature equivalent to the aggressive ISBN matcher)
> DBD::mysql::st execute failed: Unknown column 'me.p_sep_by_space' in
> 'field list' [for Statement "SELECT `me`.`currency`, `me`.`symbol`,
> `me`.`isocode`, `me`.`timestamp`, `me`.`rate`, `me`.`active`,
> `me`.`archived`, `me`.`p_sep_by_space` FROM `currency` `me` WHERE (
> `active` = ? )" with ParamValues: 0=1] at
> /usr/local/share/perl/5.24.1/DBIx/Class/Storage/DBI.pm line 1836.
> DBIx::Class::Storage::DBI::_dbh_execute(): Unknown column
> 'me.p_sep_by_space' in 'field list' at
> /inlibro/git/koha-csf-prod-inlibro/Koha/Objects.pm line 209
>
> Basically, the update code uses Koha::Number::Price, which in full modern
> object mode goes for its newly added *p_sep_by_space* *in the 18.05 code*.
> But the DB doesn't have it yet (it comes with 17.12.00.022).
>
> Big crash big time.  The process stops.
>
> Any workaround? (didn't see anything in the list, nor bugzilla, did I miss
> it?).
>
> Thanks,
>
> PS this is bound to happen whenever Koha objects are used in
> updatedatabase.pl.
> --
> Philippe Blouin,
> Responsable du d?veloppement informatique
>
> T?l.  : (888) 604-2627
> philippe.blouin at inLibro.com
> inLibro | pour esprit libre | www.inLibro.com
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180612/6c84357b/attachment.html>

From jonathan.druart at bugs.koha-community.org  Tue Jun 12 18:11:28 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Tue, 12 Jun 2018 13:11:28 -0300
Subject: [Koha-devel] Cannot upgrade DB from 16.05 to 18.05.00. Solid
 crash and burn in updatedatabase.pl
In-Reply-To: <CAJzKNY7hbvJmQzyyDocJ9v_h43SEcPNtbyBsDQrhyo2v8wCp1Q@mail.gmail.com>
References: <ef2a420c-b5f6-dd07-e067-e4ea2c4defaf@inlibro.com>
	<CAJzKNY7hbvJmQzyyDocJ9v_h43SEcPNtbyBsDQrhyo2v8wCp1Q@mail.gmail.com>
Message-ID: <CAJzKNY5198_fxDad23iBvxEcw3pbFovA5gLWZL8Zaou_Nv0fqg@mail.gmail.com>

 I opened it, see bug 20922.
I am going to provide a patch very soon.

On Tue, 12 Jun 2018 at 12:55 Jonathan Druart <
jonathan.druart at bugs.koha-community.org> wrote:

> It's a bug, please open a new bug report.
> Indeed we should not use Koha::Object packages during the update database
> process, they are using the DBIx::Class schema. It's in the coding
> guidelines already ;)
>
>
> On Tue, 12 Jun 2018 at 12:41 Philippe Blouin <philippe.blouin at inlibro.com>
> wrote:
>
>> Hol?!
>>
>> Currently migrating some 3.0 DB to 18.05.  A single hiccup with
>> message_transport, no biggie.  Until...
>>
>> 16.06.00.042
>>
>> Upgrade to 16.06.00.041 done (Bug 14629 - Add aggressive ISSN matching
>> feature equivalent to the aggressive ISBN matcher)
>> DBD::mysql::st execute failed: Unknown column 'me.p_sep_by_space' in
>> 'field list' [for Statement "SELECT `me`.`currency`, `me`.`symbol`,
>> `me`.`isocode`, `me`.`timestamp`, `me`.`rate`, `me`.`active`,
>> `me`.`archived`, `me`.`p_sep_by_space` FROM `currency` `me` WHERE (
>> `active` = ? )" with ParamValues: 0=1] at
>> /usr/local/share/perl/5.24.1/DBIx/Class/Storage/DBI.pm line 1836.
>> DBIx::Class::Storage::DBI::_dbh_execute(): Unknown column
>> 'me.p_sep_by_space' in 'field list' at
>> /inlibro/git/koha-csf-prod-inlibro/Koha/Objects.pm line 209
>>
>> Basically, the update code uses Koha::Number::Price, which in full modern
>> object mode goes for its newly added *p_sep_by_space* *in the 18.05 code*.
>> But the DB doesn't have it yet (it comes with 17.12.00.022).
>>
>> Big crash big time.  The process stops.
>>
>> Any workaround? (didn't see anything in the list, nor bugzilla, did I
>> miss it?).
>>
>> Thanks,
>>
>> PS this is bound to happen whenever Koha objects are used in
>> updatedatabase.pl.
>> --
>> Philippe Blouin,
>> Responsable du d?veloppement informatique
>>
>> T?l.  : (888) 604-2627
>> philippe.blouin at inLibro.com
>> inLibro | pour esprit libre | www.inLibro.com
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180612/f6795efc/attachment-0001.html>

From philippe.blouin at inlibro.com  Tue Jun 12 23:00:46 2018
From: philippe.blouin at inlibro.com (Philippe Blouin)
Date: Tue, 12 Jun 2018 17:00:46 -0400
Subject: [Koha-devel] Cannot upgrade DB from 16.05 to 18.05.00. Solid
 crash and burn in updatedatabase.pl
In-Reply-To: <CAJzKNY5198_fxDad23iBvxEcw3pbFovA5gLWZL8Zaou_Nv0fqg@mail.gmail.com>
References: <ef2a420c-b5f6-dd07-e067-e4ea2c4defaf@inlibro.com>
	<CAJzKNY7hbvJmQzyyDocJ9v_h43SEcPNtbyBsDQrhyo2v8wCp1Q@mail.gmail.com>
	<CAJzKNY5198_fxDad23iBvxEcw3pbFovA5gLWZL8Zaou_Nv0fqg@mail.gmail.com>
Message-ID: <a73af77a-b0db-7b54-ab6f-ecfa9c1ba720@inlibro.com>

Great many thanks for the patch, Jonathan!

Philippe Blouin,
Responsable du d?veloppement informatique

T?l.??: (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
On 06/12/2018 12:11 PM, Jonathan Druart wrote:
> ?I opened it, see bug 20922.
> I am going to provide a patch very soon.
>
> On Tue, 12 Jun 2018 at 12:55 Jonathan Druart 
> <jonathan.druart at bugs.koha-community.org 
> <mailto:jonathan.druart at bugs.koha-community.org>> wrote:
>
>     It's a bug, please open a new bug report.
>     Indeed we should not use Koha::Object packages during the update
>     database process, they are using the DBIx::Class schema. It's in
>     the coding guidelines already ;)
>
>
>     On Tue, 12 Jun 2018 at 12:41 Philippe Blouin
>     <philippe.blouin at inlibro.com <mailto:philippe.blouin at inlibro.com>>
>     wrote:
>
>         Hol?!
>
>         Currently migrating some 3.0 DB to 18.05.? A single hiccup
>         with message_transport, no biggie.? Until...
>
>         16.06.00.042
>
>         Upgrade to 16.06.00.041 done (Bug 14629 - Add aggressive ISSN
>         matching feature equivalent to the aggressive ISBN matcher)
>         DBD::mysql::st execute failed: Unknown column
>         'me.p_sep_by_space' in 'field list' [for Statement "SELECT
>         `me`.`currency`, `me`.`symbol`, `me`.`isocode`,
>         `me`.`timestamp`, `me`.`rate`, `me`.`active`, `me`.`archived`,
>         `me`.`p_sep_by_space` FROM `currency` `me` WHERE ( `active` =
>         ? )" with ParamValues: 0=1] at
>         /usr/local/share/perl/5.24.1/DBIx/Class/Storage/DBI.pm line 1836.
>         DBIx::Class::Storage::DBI::_dbh_execute(): Unknown column
>         'me.p_sep_by_space' in 'field list' at
>         /inlibro/git/koha-csf-prod-inlibro/Koha/Objects.pm line 209
>
>         Basically, the update code uses Koha::Number::Price, which in
>         full modern object mode goes for its newly added
>         *p_sep_by_space* _in the 18.05 code_.? But the DB doesn't have
>         it yet (it comes with 17.12.00.022).
>
>         Big crash big time.? The process stops.
>
>         Any workaround? (didn't see anything in the list, nor
>         bugzilla, did I miss it?).
>
>         Thanks,
>
>         PS this is bound to happen whenever Koha objects are used in
>         updatedatabase.pl <http://updatedatabase.pl>.
>
>         -- 
>         Philippe Blouin,
>         Responsable du d?veloppement informatique
>
>         T?l.??: (888) 604-2627
>         philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>
>
>         inLibro | pour esprit libre | www.inLibro.com
>         <http://www.inLibro.com>
>         _______________________________________________
>         Koha-devel mailing list
>         Koha-devel at lists.koha-community.org
>         <mailto:Koha-devel at lists.koha-community.org>
>         http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>         website : http://www.koha-community.org/
>         git : http://git.koha-community.org/
>         bugs : http://bugs.koha-community.org/
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180612/3c8bc8d1/attachment.html>

From chris at bigballofwax.co.nz  Tue Jun 12 23:09:45 2018
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Wed, 13 Jun 2018 09:09:45 +1200
Subject: [Koha-devel] bugs.koha-community.org outage warning
Message-ID: <CA+95qVQYukaPvXsrGEYu_Adg1X=LjdM0PaW=yZd82eRpNu+=PQ@mail.gmail.com>

Hi All

The linode bugzilla (and a few outher services like the dashboard) is
on is going down for a bit now to be upgraded to the next size up.

This will cause a brief outage

It should be back shortly

Chris

From barton at bywatersolutions.com  Wed Jun 13 19:23:59 2018
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Wed, 13 Jun 2018 13:23:59 -0400
Subject: [Koha-devel] Proposed coding standard: always check for object
	existence before use
Message-ID: <CAMSJbVusXP2hDm7t7LffvU-YH6VsuGjk_eKNgYNy4GKXrPcOiQ@mail.gmail.com>

Calling a method or accessing a member of an undefined object will throw a
fatal error that looks like this:  "can't call method * on an undefined
value at ..."

For example, this code will cause a software error if $data->{itemnumber}
exists, but the item doesn't exist (maybe it's been deleted?):

my $item = Koha::Items->find( $data->{itemnumber} );
my $biblio = $item->biblio;

How this is handled will of course depend on context -- maybe we should
carp and continue, or maybe just

my $item = Koha::Items->find( $data->{itemnumber} );
my $biblio = $item->biblio if defined $item;

I would like to add a coding standard that we always check for this.

Thanks,

--Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180613/aa8c132b/attachment.html>

From jonathan.druart at bugs.koha-community.org  Wed Jun 13 21:07:06 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Wed, 13 Jun 2018 16:07:06 -0300
Subject: [Koha-devel] Proposed coding standard: always check for object
 existence before use
In-Reply-To: <CAMSJbVusXP2hDm7t7LffvU-YH6VsuGjk_eKNgYNy4GKXrPcOiQ@mail.gmail.com>
References: <CAMSJbVusXP2hDm7t7LffvU-YH6VsuGjk_eKNgYNy4GKXrPcOiQ@mail.gmail.com>
Message-ID: <CAJzKNY5tPJcOt=GimO0hSdDiiUyCjL==3vhqd=30P-MT_gZ9TA@mail.gmail.com>

Hi Barton,

Yes, and no. It depends.

Example 1)
  my $biblio_to_edit = Koha::Biblios->find( $query->param('biblionumber') );
  say sprintf "you are editing %s", $biblio_to_edit->title;
Here we need to display a message if the biblio you want to edit does no
longer exist (or invalid id).

Example 2)
  sub one_more_sub {
    my ( $itemnumber ) = @_;
    my $item = Koha::Items->find( $itemnumber );
    return unless $item;
    say $item->homebranch->branchname;
    say Koha::Frameworks->find($item->biblio->frameworkcode);
  }
Here we do not need to make sure the homebranch or the biblio or the
framework exist. The DB constraints take care of that for us. If the
itemnumber exists, other objects exist.


In that case of 1) we should stop the process at that point if the biblio
does not exist, no need to continue.
On bug 18403 I have introduced a way to do that, it is as much useful as
ugly. We wanted to display a message if 1. the borrowernumber does not
exist, or 2. the logged-in patron does not have the permission to view
patron's info for a given borrowernumber. It looks like:

  my $logged_in_user = Koha::Patrons->find( $loggedinuser )
                                     or die "Not logged in";
  output_and_exit_if_error( $input, $cookie, $template, { module =>
'members', logged_in_user => $logged_in_user, current_patron => $patron } );

What does it do? It dies in case $logged_in_user does not exist (it should
*never* happen, but... who really knows?)
And will render the template by setting an error flag "unknown_patron" or
"cannot_see_patron_infos" if needed (for more info, see
C4::Output::output_and_exit_if_error and blocking_errors.inc).

Basically, we should avoid indentation blocks (if ( defined $item ) { #
then continue }), it is usually a bad idea.

See also:
*Bug 20661*
<https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20661> - Implement
blocking errors for circulation scripts
*Bug 20351*
<https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20351> - Implement
blocking errors for serials scripts
Help me to make them in, and I will implement more.

Going further, see a previous discussion "Expected behaviour if itemtype
does not exist" -
http://lists.koha-community.org/pipermail/koha-devel/2017-August/043924.html

Cheers,
Jonathan

On Wed, 13 Jun 2018 at 14:23 Barton Chittenden <barton at bywatersolutions.com>
wrote:

> Calling a method or accessing a member of an undefined object will throw a
> fatal error that looks like this:  "can't call method * on an undefined
> value at ..."
>
> For example, this code will cause a software error if $data->{itemnumber}
> exists, but the item doesn't exist (maybe it's been deleted?):
>
> my $item = Koha::Items->find( $data->{itemnumber} );
> my $biblio = $item->biblio;
>
> How this is handled will of course depend on context -- maybe we should
> carp and continue, or maybe just
>
> my $item = Koha::Items->find( $data->{itemnumber} );
> my $biblio = $item->biblio if defined $item;
>
> I would like to add a coding standard that we always check for this.
>
> Thanks,
>
> --Barton
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180613/a927a061/attachment.html>

From chrisc at catalyst.net.nz  Wed Jun 13 21:58:14 2018
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Thu, 14 Jun 2018 07:58:14 +1200
Subject: [Koha-devel] [Koha] How to introduce a new user-permission to
	Koha?
In-Reply-To: <CAK+4ReEi4Ct30Omz5E_Wnic+fznZnHu77yyZUDbUpj_obsuzEg@mail.gmail.com>
References: <CAK+4ReEi4Ct30Omz5E_Wnic+fznZnHu77yyZUDbUpj_obsuzEg@mail.gmail.com>
Message-ID: <DD7DEE73-E28C-4386-ADF0-501ABAD500DA@catalyst.net.nz>

Kia ora Markus

Shifting this over to the development list.
As you are more likely to get an answer there.

If no one has answered by the time I get in front of a computer, I'll try :)

Chris 

On 14 June 2018 7:02:30 AM NZST, Markus Becker <beckmarkus at gmail.com> wrote:
>Dear Koha-Community,
>
>i did not find any hint oder documentation, where the permissions for
>using tools etc. are stored.
>
>My example:
>For testing purpose i want to insert my own perl-script into Koha and
>it should appear on the "tools"-page.
>
>The links on this page are shown to the user or not depending on the
>permissions he has:
>(tools-home.tt)
>
> [% IF ( CAN_user_tools_manage_staged_marc ) %]
><dt><a
>href="/cgi-bin/koha/tools/bibliotheca_convert.pl">Bibliotheca-Datei
>hochladen</a></dt>
><dd>Werkzeug um BIBLIOTHECAplus-Exportdatei f?r den Import
>hochzuladen</dd>
> [% END %]
>
>I can not find the place, where these rights are deposited. How does
>Koha know if a certain right is existing?
>I found the file permissions.inc but changes there did not having any
>effect.
>
>Of cource i could use the permission
>"CAN_user_tools_manage_staged_marc" for my own script (and then the
>link is shown), but IMHO it would be not correct to "steal" the
>permission of another script.
>
>I would be very grateful if someone could give me a hint how to
>introduce the permission to start my script to Koha.
>
>Thank You very much in Advance,
>Markus Becker
>_______________________________________________
>Koha mailing list  http://koha-community.org
>Koha at lists.katipo.co.nz
>https://lists.katipo.co.nz/mailman/listinfo/koha

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180614/7cf20801/attachment.html>

From jonathan.druart at bugs.koha-community.org  Wed Jun 13 22:30:55 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Wed, 13 Jun 2018 17:30:55 -0300
Subject: [Koha-devel] [Koha] How to introduce a new user-permission to
	Koha?
In-Reply-To: <DD7DEE73-E28C-4386-ADF0-501ABAD500DA@catalyst.net.nz>
References: <CAK+4ReEi4Ct30Omz5E_Wnic+fznZnHu77yyZUDbUpj_obsuzEg@mail.gmail.com>
	<DD7DEE73-E28C-4386-ADF0-501ABAD500DA@catalyst.net.nz>
Message-ID: <CAJzKNY5gW91DYL3WB5=Q334LrUNc=Di7CuLUd5c_DSbG2aLMYw@mail.gmail.com>

Hi Markus,

Permissions are stored in the tables 'permissions' and 'userflags'
For instance "tools" is a group of permissions (userflags.flag="tools" with
a bit=13), and the permissions table will contain the subpermissions.

  select * from permissions where module_bit=13;
will give your the subpermissions for tools.

To use the script tools/modborrowers.pl (edit patrons in a batch) you will
need the subpermission edit_patrons of the tools module. If you edit this
file you will find the following line:
  flagsrequired   => { tools => "edit_patrons" }

The CAN_* flags in the template are set in C4::Auth
"CAN_user_tools" means all the "tools" subpermissions
CAN_user_tools_edit_patrons means the edit_patrons subpermission of the
"tools" module.

Take a look at
  commit  f56d6530bc7ea00db0d2b158a8b2667d5ba16a41
  Bug 16978: Add delete reports user permission
it added the "reports => delete_reports" subpermission.

Good luck :)
Hope that makes sense!

Jonathan

On Wed, 13 Jun 2018 at 16:58 Chris Cormack <chrisc at catalyst.net.nz> wrote:

> Kia ora Markus
>
> Shifting this over to the development list.
> As you are more likely to get an answer there.
>
> If no one has answered by the time I get in front of a computer, I'll try
> :)
>
> Chris
>
> On 14 June 2018 7:02:30 AM NZST, Markus Becker <beckmarkus at gmail.com>
> wrote:
>
>> Dear Koha-Community,
>>
>> i did not find any hint oder documentation, where the permissions for
>> using tools etc. are stored.
>>
>> My example:
>> For testing purpose i want to insert my own perl-script into Koha and
>> it should appear on the "tools"-page.
>>
>> The links on this page are shown to the user or not depending on the
>> permissions he has:
>> (tools-home.tt)
>>
>>  [% IF ( CAN_user_tools_manage_staged_marc ) %]
>>  <dt><a href="/cgi-bin/koha/tools/bibliotheca_convert.pl">Bibliotheca-Datei
>> hochladen</a></dt>
>>  <dd>Werkzeug um BIBLIOTHECAplus-Exportdatei f?r den Import hochzuladen</dd>
>>  [% END %]
>>
>> I can not find the place, where these rights are deposited. How does
>> Koha know if a certain right is existing?
>> I found the file permissions.inc but changes there did not having any effect.
>>
>> Of cource i could use the permission
>> "CAN_user_tools_manage_staged_marc" for my own script (and then the
>> link is shown), but IMHO it would be not correct to "steal" the
>> permission of another script.
>>
>> I would be very grateful if someone could give me a hint how to
>> introduce the permission to start my script to Koha.
>>
>> Thank You very much in Advance,
>> Markus Becker
>> ------------------------------
>>
>> Koha mailing list  http://koha-community.org
>> Koha at lists.katipo.co.nz
>> https://lists.katipo.co.nz/mailman/listinfo/koha
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180613/63ddcbc2/attachment-0001.html>

From barton at bywatersolutions.com  Thu Jun 14 02:52:39 2018
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Wed, 13 Jun 2018 20:52:39 -0400
Subject: [Koha-devel] Proposed coding standard: always check for object
 existence before use
In-Reply-To: <CAJzKNY5tPJcOt=GimO0hSdDiiUyCjL==3vhqd=30P-MT_gZ9TA@mail.gmail.com>
References: <CAMSJbVusXP2hDm7t7LffvU-YH6VsuGjk_eKNgYNy4GKXrPcOiQ@mail.gmail.com>
	<CAJzKNY5tPJcOt=GimO0hSdDiiUyCjL==3vhqd=30P-MT_gZ9TA@mail.gmail.com>
Message-ID: <CAMSJbVtRXctHaxB-=gZb88jov7w0L-+rbGhUs4tzsBwq4RdfXw@mail.gmail.com>

On Wed, Jun 13, 2018 at 3:07 PM, Jonathan Druart <
jonathan.druart at bugs.koha-community.org> wrote:

> Hi Barton,
>
> Yes, and no. It depends.
>

... the dark side of TMTOWTDI ;-)

I read through your examples, they all made good sense.

Basically, we should avoid indentation blocks (if ( defined $item ) { #
> then continue }), it is usually a bad idea.
>

I'm not quite clear on what you mean here... do you mean that we should
either find a good object or fail gracefully?

I'm going to give a more concrete example... this was new code in 17.11,
but it's no longer in master...

sub GetMemberAccountRecords {
    my ($borrowernumber) = @_;
    my $dbh = C4::Context->dbh;
    my @acctlines;
    my $numlines = 0;
    my $strsth      = qq(
                        SELECT *
                        FROM accountlines
                        WHERE borrowernumber=?);
    $strsth.=" ORDER BY accountlines_id desc";
    my $sth= $dbh->prepare( $strsth );
    $sth->execute( $borrowernumber );

    my $total = 0;
    while ( my $data = $sth->fetchrow_hashref ) {
        if ( $data->{itemnumber} ) {
            my $item = Koha::Items->find( $data->{itemnumber} );
            my $biblio = $item->biblio;

Here, we're traversing accountlines...  $data->{itemnumber} comes from
accountlines. We find the item object based on that itemnumber, and then
attempt to create a biblio record from that... which is fine, as long as
the item hasn't been deleted.

 my $biblio = $item->biblio;

is a fatal error in this case. I don't think that we're doing anything
terribly consequential with $biblio...

I totally agree that how we handle this depends on context... sometimes the
instantiated object is critical, sometimes it's not...  but I would assert
that we *always* need to check to make sure that objects are defined before
they're used.

   my $object = Koha::Foo->find( $something );
   $object->{bar};

or

   my $object = Koha::Foo->new();
   $object->{bar};

Without any error checking on $object should be a violation of coding
standards... assuming that $object is defined simply isn't safe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180613/44af7052/attachment.html>

From kohanews at gmail.com  Thu Jun 14 02:58:08 2018
From: kohanews at gmail.com (kohanews)
Date: Wed, 13 Jun 2018 17:58:08 -0700
Subject: [Koha-devel] Call for News: June 2018 Newsletter
Message-ID: <dfcd206d-43b9-b933-6d1b-04e1f1f4e3d3@gmail.com>

I'm collecting news for the June newsletter. Send anything noteworthy to:

k o h a news AT gmail dot com

News criteria:
---------------------------

** For events **:
 ?? - Please include dates for past events. If I can't find dates I may 
not add it.
 ?? - Announcements for future events with dates T.B.A. are fine ...Eg., 
Kohacon
 ?? - For past events , **** one month back is the cut-off? ****.

* News items can be of any length.
* Images are fine
* Anything and everything Koha.
* Submit by the 26th of the month.

If you are working on an interesting project or development related to
Koha, please let me know and I'll include it in the development section.

Thank you!

-- 
Chad Roseburg
Editor, Koha Community Newsletter


From barton at bywatersolutions.com  Thu Jun 14 17:59:56 2018
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Thu, 14 Jun 2018 11:59:56 -0400
Subject: [Koha-devel] Bug 1993 - Task Scheduler Needs Re-write
Message-ID: <CAMSJbVudPmVKORnOajvZHEdQ_v6W=Wd1ZKkJ0W6jdMkyyoJS=Q@mail.gmail.com>

This is an old issue that's never really been addressed. As I understand
it, at one time, we had a tool that used the unix 'at' scheduler to run
requested reports. This was a huge security hole, and we disabled it....
and it's never worked since.

As such, those who host servers must add calls to runreport.pl by hand.

Bug 1993 was opened to address this. It was marked as 'In Discussion' in
2013. I would like to see this move forward -- server admins are dying from
a thousand paper cuts, and I think that users would benefit from having
more control over when their reports are scheduled.

What still needs to be discussed here?

Thanks,

--Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180614/b719c182/attachment.html>

From jonathan.druart at bugs.koha-community.org  Thu Jun 14 18:16:12 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Thu, 14 Jun 2018 13:16:12 -0300
Subject: [Koha-devel] Bug 1993 - Task Scheduler Needs Re-write
In-Reply-To: <CAMSJbVudPmVKORnOajvZHEdQ_v6W=Wd1ZKkJ0W6jdMkyyoJS=Q@mail.gmail.com>
References: <CAMSJbVudPmVKORnOajvZHEdQ_v6W=Wd1ZKkJ0W6jdMkyyoJS=Q@mail.gmail.com>
Message-ID: <CAJzKNY7ZjZ9cBEva=35CtZxFzTunHvAPCFsfjYJKmOpqcobiOg@mail.gmail.com>

Few links:
http://lists.koha-community.org/pipermail/koha-devel/2017-February/043489.html
*Bug 10662*
<https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662> - Build
OAI-PMH Harvesting Client
*Bug 15032*
<https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15032> - [Plack]
Scripts that fork (like stage-marc-import.pl) don't work as expected

Basically we need a daemon watching a job queue (DB table) to answer all
these needs at once.
I have started something already, I will get back to it when I will have
time (and motivation).

Cheers,
Jonathan

On Thu, 14 Jun 2018 at 12:59 Barton Chittenden <barton at bywatersolutions.com>
wrote:

> This is an old issue that's never really been addressed. As I understand
> it, at one time, we had a tool that used the unix 'at' scheduler to run
> requested reports. This was a huge security hole, and we disabled it....
> and it's never worked since.
>
> As such, those who host servers must add calls to runreport.pl by hand.
>
> Bug 1993 was opened to address this. It was marked as 'In Discussion' in
> 2013. I would like to see this move forward -- server admins are dying from
> a thousand paper cuts, and I think that users would benefit from having
> more control over when their reports are scheduled.
>
> What still needs to be discussed here?
>
> Thanks,
>
> --Barton
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180614/62ba2601/attachment.html>

From indradg at l2c2.co.in  Fri Jun 15 12:40:56 2018
From: indradg at l2c2.co.in (Indranil Das Gupta)
Date: Fri, 15 Jun 2018 16:10:56 +0530
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email via message
	queue?
Message-ID: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>

Hi all,

I was wondering why we do not push the ACCTDETAILS email via  the message
queue.

Is it just one of those cases of "as things have always been done" OR there
is a reason that I'm missing out?

cheers
indranil.

Indranil Das Gupta
L2C2 Technologies

Phone : +91-98300-20971
Blog    : http://blog.l2c2.co.in
IRC     : indradg on irc://irc.freenode.net
Twitter : indradg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180615/2a43315b/attachment.html>

From sophie.meynieux at biblibre.com  Fri Jun 15 13:33:03 2018
From: sophie.meynieux at biblibre.com (Sophie Meynieux)
Date: Fri, 15 Jun 2018 13:33:03 +0200
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email via
 message queue?
In-Reply-To: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>
References: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>
Message-ID: <e4037673-769f-beac-478e-8721661a637c@biblibre.com>

Maybe because for this message you're expecting it is sent immediately 
while message_queue table could be processed more occasionally ?

Best regards

S. Meynieux

-- 
Responsable support
BibLibre
+ 33 (0)4 91 81 35 08
http://www.biblibre.com

Le 15/06/2018 ? 12:40, Indranil Das Gupta a ?crit?:
> Hi all,
>
> I was wondering why we do not push the ACCTDETAILS email via? the 
> message queue.
>
> Is it just one of those cases of "as things have always been done" OR 
> there is a reason that I'm missing out?
>
> cheers
> indranil.
>
> Indranil Das Gupta
> L2C2 Technologies
>
> Phone : +91-98300-20971
> Blog ? ?: http://blog.l2c2.co.in
> IRC ? ? : indradg on irc://irc.freenode.net <http://irc.freenode.net>
> Twitter : indradg
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180615/817f2cbb/attachment.html>

From barton at bywatersolutions.com  Sat Jun 16 03:31:55 2018
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Fri, 15 Jun 2018 21:31:55 -0400
Subject: [Koha-devel] Should the first 3 digits of cn_sort be sorted for
	dewey decimal?
Message-ID: <CAMSJbVsH7==Ccd+ggmKStFP+mb27JTnpV4VqYG+cie15sa82Sw@mail.gmail.com>

The documentation for GetClassSortKey says

* Concatenates class and item part.
* Converts to uppercase.
* Removes leading and trailing whitespace and '/'
* Separates alphabetic prefix from the rest of the call number
* Splits into tokens on whitespaces and periods.
* Leaves first digit group as is.
...

this means that callnumbers

9.1 => 9_100000000000000
80.1 => 80_100000000000000
700.1 => 700_100000000000000

when sorted ascending by cn_sort

700.1 => 700_100000000000000
80.1 =>  80_100000000000000
9.1 => 9_100000000000000

Shouldn't these be zero padded to 3 digits, so that they sort as follows?

009_100000000000000
080_100000000000000
700_100000000000000
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180615/38b3a82e/attachment.html>

From mik at adminkuhn.ch  Sat Jun 16 08:37:10 2018
From: mik at adminkuhn.ch (Michael Kuhn)
Date: Sat, 16 Jun 2018 08:37:10 +0200
Subject: [Koha-devel] Should the first 3 digits of cn_sort be sorted for
 dewey decimal?
In-Reply-To: <CAMSJbVsH7==Ccd+ggmKStFP+mb27JTnpV4VqYG+cie15sa82Sw@mail.gmail.com>
References: <CAMSJbVsH7==Ccd+ggmKStFP+mb27JTnpV4VqYG+cie15sa82Sw@mail.gmail.com>
Message-ID: <bbe7e1e6-0af2-d921-6f64-46b86c6a0308@adminkuhn.ch>

Hi Barton

 > this means that callnumbers
 >
 > 9.1 => 9_100000000000000
 > 80.1 => 80_100000000000000
 > 700.1 => 700_100000000000000
 >
 > when sorted ascending by cn_sort
 >
 > 700.1 => 700_100000000000000
 > 80.1 =>  80_100000000000000
 > 9.1 => 9_100000000000000
 >
 > Shouldn't these be zero padded to 3 digits, so that they sort as
 > follows?
 >
 > 009_100000000000000
 > 080_100000000000000
 > 700_100000000000000

Dewey Decimal Classification uses characters that indeed do look like 
Arabic numbers (standing for classes, divisions, sections), but these 
characters do not behave like numbers, so the correct sorting is 
actually not as you would expect (namely seen from the right to left)

   1
   2
  11
  21
100
230

but (and thus seen from left to right)

1
100
11
2
21
230

Hope this helps.

Best wishes: Michael
-- 
Gesch?ftsf?hrer ? Diplombibliothekar BBS, Informatiker eidg. Fachausweis
Admin Kuhn GmbH ? Pappelstrasse 20 ? 4123 Allschwil ? Schweiz
T 0041 (0)61 261 55 61 ? E mik at adminkuhn.ch ? W www.adminkuhn.ch

From barton at bywatersolutions.com  Sat Jun 16 17:11:39 2018
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Sat, 16 Jun 2018 11:11:39 -0400
Subject: [Koha-devel] Should the first 3 digits of cn_sort be sorted for
 dewey decimal?
In-Reply-To: <bbe7e1e6-0af2-d921-6f64-46b86c6a0308@adminkuhn.ch>
References: <CAMSJbVsH7==Ccd+ggmKStFP+mb27JTnpV4VqYG+cie15sa82Sw@mail.gmail.com>
	<bbe7e1e6-0af2-d921-6f64-46b86c6a0308@adminkuhn.ch>
Message-ID: <CAMSJbVtRXLC55V-1nPm2MK_ogkzZ_j9bCVtFh+g6iXactM7N3A@mail.gmail.com>

On Sat, Jun 16, 2018 at 2:37 AM, Michael Kuhn <mik at adminkuhn.ch> wrote:

>
> Dewey Decimal Classification uses characters that indeed do look like
> Arabic numbers (standing for classes, divisions, sections), but these
> characters do not behave like numbers, so the correct sorting is actually
> not as you would expect (namely seen from the right to left)
>
>   1
>   2
>  11
>  21
> 100
> 230
>
> but (and thus seen from left to right)
>
> 1
> 100
> 11
> 2
> 21
> 230
>
> Hope this helps.
>
> That's' not the way I understand it. The Dewey classes:

000 ? Computer science, information & general works
100 ? Philosophy and psychology
200 ? Religion
300 ? Social sciences
400 ? Language
500 ? Pure Science
600 ? Technology
700 ? Arts & recreation
800 ? Literature
900 ? History & geography

000 is sub-divided into the hundreds group

000 Computer science, knowledge & systems
010 Bibliographies
020 Library & information sciences
030 Encyclopedias & books of facts
040 [Unassigned]
050 Magazines, journals & serials
060 Associations, organizations & museums
070 News media, journalism & publishing
080 Quotations
090 Manuscripts & rare books

and then sub-divided again into the thousands groups...

000 Computer science, information & general works
001 Knowledge
002 The book
003 Systems
004 Data processing & computer science
005 Computer programming, programs & data
006 Special computer methods
007 [Unassigned]
008 [Unassigned]
009 [Unassigned]

...and then sub-divisions of the thousands are done after the decimal
point  -- 001.1, 001.2, etc...

as such, I don't think that callnumber 1.1 is a valid DDC number... it
lacks the class and hundred-level group, and should, for the purposes of
cn_sort, be converted to 001_100000000000000.

(Numbers above are taken from
https://www.oclc.org/content/dam/oclc/dewey/DDC%2023_Summaries.pdf).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180616/181d6923/attachment.html>

From mik at adminkuhn.ch  Sat Jun 16 18:03:03 2018
From: mik at adminkuhn.ch (Michael Kuhn)
Date: Sat, 16 Jun 2018 18:03:03 +0200
Subject: [Koha-devel] Should the first 3 digits of cn_sort be sorted for
 dewey decimal?
In-Reply-To: <CAMSJbVtRXLC55V-1nPm2MK_ogkzZ_j9bCVtFh+g6iXactM7N3A@mail.gmail.com>
References: <CAMSJbVsH7==Ccd+ggmKStFP+mb27JTnpV4VqYG+cie15sa82Sw@mail.gmail.com>
	<bbe7e1e6-0af2-d921-6f64-46b86c6a0308@adminkuhn.ch>
	<CAMSJbVtRXLC55V-1nPm2MK_ogkzZ_j9bCVtFh+g6iXactM7N3A@mail.gmail.com>
Message-ID: <f0c36ab6-9512-305f-806b-b04add64b2fc@adminkuhn.ch>

Hi Barton

 > ...and then sub-divisions of the thousands are done after the decimal
 > point  -- 001.1, 001.2, etc...
 >
 > as such, I don't think that callnumber 1.1 is a valid DDC number... it
 > lacks the class and hundred-level group, and should, for the purposes
 > of cn_sort, be converted to 001_100000000000000.
 >
 > (Numbers above are taken from
 > https://www.oclc.org/content/dam/oclc/dewey/DDC%2023_Summaries.pdf).

Looking deeper into it it seems I was just talking about the classic 
"decimal classification" which doesn't have leading zeroes. There are 
too many variants of it, one of them being the Dewey Decimal 
Classification / DDC - which actually seems to behave as you say, 
including leading zeroes. I wasn't aware of that difference. As far as I 
know the DDC is mostly used in the USA but also in Europe many peop?le 
are referring to "Dewey" when they actually mean their local decimal 
classification.

So I guess many libraries are filling the DDC fields with content that 
is actually not proper DDC but their own variant of a decimal 
classification (for example I would think in Europe it will often be 
another hairy variant of the Universal Decimal Classification / UDC that 
behaves the way I described - see 
https://en.wikipedia.org/wiki/Universal_Decimal_Classification).

Best wishes: Michael
-- 
Gesch?ftsf?hrer ? Diplombibliothekar BBS, Informatiker eidg. Fachausweis
Admin Kuhn GmbH ? Pappelstrasse 20 ? 4123 Allschwil ? Schweiz
T 0041 (0)61 261 55 61 ? E mik at adminkuhn.ch ? W www.adminkuhn.ch

From barton at bywatersolutions.com  Sat Jun 16 21:32:20 2018
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Sat, 16 Jun 2018 15:32:20 -0400
Subject: [Koha-devel] Should the first 3 digits of cn_sort be sorted for
 dewey decimal?
In-Reply-To: <f0c36ab6-9512-305f-806b-b04add64b2fc@adminkuhn.ch>
References: <CAMSJbVsH7==Ccd+ggmKStFP+mb27JTnpV4VqYG+cie15sa82Sw@mail.gmail.com>
	<bbe7e1e6-0af2-d921-6f64-46b86c6a0308@adminkuhn.ch>
	<CAMSJbVtRXLC55V-1nPm2MK_ogkzZ_j9bCVtFh+g6iXactM7N3A@mail.gmail.com>
	<f0c36ab6-9512-305f-806b-b04add64b2fc@adminkuhn.ch>
Message-ID: <CAMSJbVtY+W6qPa89cVuRM3_kQ6mnMw_g+f7KAVaBGVDR-JWaxg@mail.gmail.com>

Very interesting!

Thanks for the link.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180616/bc7dff2c/attachment.html>

From martin.renvoize at ptfs-europe.com  Mon Jun 18 09:46:49 2018
From: martin.renvoize at ptfs-europe.com (Renvoize, Martin)
Date: Mon, 18 Jun 2018 08:46:49 +0100
Subject: [Koha-devel] Bug 1993 - Task Scheduler Needs Re-write
In-Reply-To: <CAJzKNY7ZjZ9cBEva=35CtZxFzTunHvAPCFsfjYJKmOpqcobiOg@mail.gmail.com>
References: <CAMSJbVudPmVKORnOajvZHEdQ_v6W=Wd1ZKkJ0W6jdMkyyoJS=Q@mail.gmail.com>
	<CAJzKNY7ZjZ9cBEva=35CtZxFzTunHvAPCFsfjYJKmOpqcobiOg@mail.gmail.com>
Message-ID: <CAB7SL8CQwS8D_MjOazMm6-k31o8=nXBvZBgHjfWkQ75Eq_LLkQ@mail.gmail.com>

Interested to see what you've started Jonathan,

In rebus:list we used Minion, the job queue spin-off project from the same
guys that wrote Mojolicious. Granted, it works best with a PostgreSQL
backend, but I believe there are MySQL backends too.. I'd probably start
there... the more I worked with them the more complicated I came to realise
queues are.. lean on the shoulders of giants and all that ;)

Martin

*Martin Renvoize*

Development Manager




*T:* +44 (0) 1483 378728

*F:* +44 (0) 800 756 6384

*E:* martin.renvoize at ptfs-europe.com

www.ptfs-europe.com



<https://www.ptfs-europe.com>



Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at info at ptfs-europe.com


On 14 June 2018 at 17:16, Jonathan Druart <
jonathan.druart at bugs.koha-community.org> wrote:

> Few links:
> http://lists.koha-community.org/pipermail/koha-devel/2017-
> February/043489.html
> *Bug 10662*
> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662> - Build
> OAI-PMH Harvesting Client
> *Bug 15032*
> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15032> - [Plack]
> Scripts that fork (like stage-marc-import.pl) don't work as expected
>
> Basically we need a daemon watching a job queue (DB table) to answer all
> these needs at once.
> I have started something already, I will get back to it when I will have
> time (and motivation).
>
> Cheers,
> Jonathan
>
> On Thu, 14 Jun 2018 at 12:59 Barton Chittenden <
> barton at bywatersolutions.com> wrote:
>
>> This is an old issue that's never really been addressed. As I understand
>> it, at one time, we had a tool that used the unix 'at' scheduler to run
>> requested reports. This was a huge security hole, and we disabled it....
>> and it's never worked since.
>>
>> As such, those who host servers must add calls to runreport.pl by hand.
>>
>> Bug 1993 was opened to address this. It was marked as 'In Discussion' in
>> 2013. I would like to see this move forward -- server admins are dying from
>> a thousand paper cuts, and I think that users would benefit from having
>> more control over when their reports are scheduled.
>>
>> What still needs to be discussed here?
>>
>> Thanks,
>>
>> --Barton
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180618/ce48dc42/attachment.html>

From dcook at prosentient.com.au  Mon Jun 18 10:11:22 2018
From: dcook at prosentient.com.au (David Cook)
Date: Mon, 18 Jun 2018 18:11:22 +1000
Subject: [Koha-devel] Bug 1993 - Task Scheduler Needs Re-write
In-Reply-To: <CAB7SL8CQwS8D_MjOazMm6-k31o8=nXBvZBgHjfWkQ75Eq_LLkQ@mail.gmail.com>
References: <CAMSJbVudPmVKORnOajvZHEdQ_v6W=Wd1ZKkJ0W6jdMkyyoJS=Q@mail.gmail.com>	<CAJzKNY7ZjZ9cBEva=35CtZxFzTunHvAPCFsfjYJKmOpqcobiOg@mail.gmail.com>
	<CAB7SL8CQwS8D_MjOazMm6-k31o8=nXBvZBgHjfWkQ75Eq_LLkQ@mail.gmail.com>
Message-ID: <040601d406db$f20d9d50$d628d7f0$@prosentient.com.au>

I recently wrote to Nick about this as well: http://lists.koha-community.org/pipermail/koha-devel/2018-June/044605.html. I wrote my own job server for Bug 10662 but figured the Koha community would never accept it, so I scrapped it and made a purpose-built scheduler just for OAI-PMH harvesting, since the sponsor had particular requirements. 

 

I?m also interested to see the work Jonathan does on this. I know I?m pretty time poor at the moment (for many reasons), so I can?t offer much except feedback.

 

When I was working on Bug 10662, I looked at Minion? and I think the main reasons I didn?t use it were because Koha hadn?t really adopted Mojolicious yet and I couldn?t see a way to tell a worker to cancel in-progress tasks/jobs and I couldn?t remove queued jobs that were already enqueued and it used a database whereas I wanted to use an in-memory queue to keep it separate from Koha.  But if Koha does further embrace Mojolicious and we?re not needing to interact with jobs/tasks once they?ve been queued and we don?t mind baking the scheduler into the Koha database schema? I would be in favour of using Minion. 

 

Standing on the shoulders of giants sounds like a plan to me.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Renvoize, Martin
Sent: Monday, 18 June 2018 5:47 PM
To: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Cc: Koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Bug 1993 - Task Scheduler Needs Re-write

 

Interested to see what you've started Jonathan,

 

In rebus:list we used Minion, the job queue spin-off project from the same guys that wrote Mojolicious. Granted, it works best with a PostgreSQL backend, but I believe there are MySQL backends too.. I'd probably start there... the more I worked with them the more complicated I came to realise queues are.. lean on the shoulders of giants and all that ;)

 

Martin





Martin Renvoize


Development Manager

	

 


T: +44 (0) 1483 378728

	

F: +44 (0) 800 756 6384

	

E:  <mailto:martin.renvoize at ptfs-europe.com> martin.renvoize at ptfs-europe.com

	

 <https://www.ptfs-europe.com> www.ptfs-europe.com

	

 

	

 <https://www.ptfs-europe.com> 

		
		

 


Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

 

The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info at ptfs-europe.com <mailto:info at ptfs-europe.com> 

 

 

On 14 June 2018 at 17:16, Jonathan Druart <jonathan.druart at bugs.koha-community.org <mailto:jonathan.druart at bugs.koha-community.org> > wrote:

Few links:

http://lists.koha-community.org/pipermail/koha-devel/2017-February/043489.html

 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662> Bug 10662 - Build OAI-PMH Harvesting Client

 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15032> Bug 15032 - [Plack] Scripts that fork (like stage-marc-import.pl <http://stage-marc-import.pl> ) don't work as expected

 

Basically we need a daemon watching a job queue (DB table) to answer all these needs at once.

I have started something already, I will get back to it when I will have time (and motivation).

 

Cheers,

Jonathan

 

On Thu, 14 Jun 2018 at 12:59 Barton Chittenden <barton at bywatersolutions.com <mailto:barton at bywatersolutions.com> > wrote:

This is an old issue that's never really been addressed. As I understand it, at one time, we had a tool that used the unix 'at' scheduler to run requested reports. This was a huge security hole, and we disabled it.... and it's never worked since.

 

As such, those who host servers must add calls to runreport.pl <http://runreport.pl>  by hand.

 

Bug 1993 was opened to address this. It was marked as 'In Discussion' in 2013. I would like to see this move forward -- server admins are dying from a thousand paper cuts, and I think that users would benefit from having more control over when their reports are scheduled.

 

What still needs to be discussed here?

 

Thanks,

 

--Barton

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180618/20f1b9cc/attachment-0001.html>

From dcook at prosentient.com.au  Mon Jun 18 10:14:54 2018
From: dcook at prosentient.com.au (David Cook)
Date: Mon, 18 Jun 2018 18:14:54 +1000
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email via
	message queue?
In-Reply-To: <e4037673-769f-beac-478e-8721661a637c@biblibre.com>
References: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>
	<e4037673-769f-beac-478e-8721661a637c@biblibre.com>
Message-ID: <040b01d406dc$701e1b20$505a5160$@prosentient.com.au>

Considering that the borrower?s password is typically in the ACCTDETAILS email, I think using the message_queue for ACCTDETAILS would be a bad idea and would probably violate the GDPR in Europe.

 

Just imagine looking through your database and seeing all those plain text passwords, especially for people who re-use the same password for everything. I think it would be a security and privacy nightmare.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Sophie Meynieux
Sent: Friday, 15 June 2018 9:33 PM
To: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?

 

Maybe because for this message you're expecting it is sent immediately while message_queue table could be processed more occasionally ? 

Best regards

S. Meynieux

-- 
Responsable support 
BibLibre
+ 33 (0)4 91 81 35 08
http://www.biblibre.com

Le 15/06/2018 ? 12:40, Indranil Das Gupta a ?crit :

Hi all, 

 

I was wondering why we do not push the ACCTDETAILS email via  the message queue.

 

Is it just one of those cases of "as things have always been done" OR there is a reason that I'm missing out?

 

cheers

indranil.


Indranil Das Gupta
L2C2 Technologies

Phone : +91-98300-20971
Blog    : http://blog.l2c2.co.in
IRC     : indradg on irc://irc.freenode.net <http://irc.freenode.net> 
Twitter : indradg






_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180618/da9da967/attachment.html>

From chris.nighswonger at gmail.com  Mon Jun 18 15:11:45 2018
From: chris.nighswonger at gmail.com (Christopher Nighswonger)
Date: Mon, 18 Jun 2018 09:11:45 -0400
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email via
	message queue?
In-Reply-To: <040b01d406dc$701e1b20$505a5160$@prosentient.com.au>
References: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>
	<e4037673-769f-beac-478e-8721661a637c@biblibre.com>
	<040b01d406dc$701e1b20$505a5160$@prosentient.com.au>
Message-ID: <CAA7=B8wB37-9NkgwzJ3XTCf3nxwNh4BFcZZpaJcWnkrwgy5Okg@mail.gmail.com>

Considering that email is plaintext (AKA "postcard") mail, I'm surprised we
would send a user's password in an email in any case.

On Mon, Jun 18, 2018 at 4:14 AM, David Cook <dcook at prosentient.com.au>
wrote:

> Considering that the borrower?s password is typically in the ACCTDETAILS
> email, I think using the message_queue for ACCTDETAILS would be a bad idea
> and would probably violate the GDPR in Europe.
>
>
>
> Just imagine looking through your database and seeing all those plain text
> passwords, especially for people who re-use the same password for
> everything. I think it would be a security and privacy nightmare.
>
>
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
>
>
> Office: 02 9212 0899
>
> Direct: 02 8005 0595
>
>
>
> *From:* koha-devel-bounces at lists.koha-community.org [mailto:
> koha-devel-bounces at lists.koha-community.org] *On Behalf Of *Sophie
> Meynieux
> *Sent:* Friday, 15 June 2018 9:33 PM
> *To:* koha-devel at lists.koha-community.org
> *Subject:* Re: [Koha-devel] Why we do not push the ACCTDETAILS email via
> message queue?
>
>
>
> Maybe because for this message you're expecting it is sent immediately
> while message_queue table could be processed more occasionally ?
>
> Best regards
>
> S. Meynieux
>
> --
>
> Responsable support
>
> BibLibre
>
> + 33 (0)4 91 81 35 08
>
> http://www.biblibre.com
>
> Le 15/06/2018 ? 12:40, Indranil Das Gupta a ?crit :
>
> Hi all,
>
>
>
> I was wondering why we do not push the ACCTDETAILS email via  the message
> queue.
>
>
>
> Is it just one of those cases of "as things have always been done" OR
> there is a reason that I'm missing out?
>
>
>
> cheers
>
> indranil.
>
>
> Indranil Das Gupta
> L2C2 Technologies
>
> Phone : +91-98300-20971
> Blog    : http://blog.l2c2.co.in
> IRC     : indradg on irc://irc.freenode.net
> Twitter : indradg
>
>
>
>
> _______________________________________________
>
> Koha-devel mailing list
>
> Koha-devel at lists.koha-community.org
>
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>
> website : http://www.koha-community.org/
>
> git : http://git.koha-community.org/
>
> bugs : http://bugs.koha-community.org/
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180618/7fba0c80/attachment.html>

From jonathan.druart at bugs.koha-community.org  Mon Jun 18 15:17:59 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Mon, 18 Jun 2018 10:17:59 -0300
Subject: [Koha-devel] Bug 1993 - Task Scheduler Needs Re-write
In-Reply-To: <CAB7SL8CQwS8D_MjOazMm6-k31o8=nXBvZBgHjfWkQ75Eq_LLkQ@mail.gmail.com>
References: <CAMSJbVudPmVKORnOajvZHEdQ_v6W=Wd1ZKkJ0W6jdMkyyoJS=Q@mail.gmail.com>
	<CAJzKNY7ZjZ9cBEva=35CtZxFzTunHvAPCFsfjYJKmOpqcobiOg@mail.gmail.com>
	<CAB7SL8CQwS8D_MjOazMm6-k31o8=nXBvZBgHjfWkQ75Eq_LLkQ@mail.gmail.com>
Message-ID: <CAJzKNY7GJiFObe4-xz53gPTWxbxVbXApiFsKC=hcT8f1P2GLgQ@mail.gmail.com>

My work was focused on the issue we face for background jobs.

I have just pushed my local branch to
https://gitlab.com/joubu/Koha/commits/bug_15032_other_tries (last 7 commits)
There is nothing to process the queued jobs actually, so I guess it is not
what you expected.
IIRC my conclusion was that it is not possible to fix it (i.e. we cannot
have the progress bar working correctly under plack). We should just
display a "job submitted" message and provide a view to monitor the running
job, and finally show the results of the job (but not as simply as it
sounds).

Cheers,
Jonathan

On Mon, 18 Jun 2018 at 04:46 Renvoize, Martin <
martin.renvoize at ptfs-europe.com> wrote:

> Interested to see what you've started Jonathan,
>
> In rebus:list we used Minion, the job queue spin-off project from the same
> guys that wrote Mojolicious. Granted, it works best with a PostgreSQL
> backend, but I believe there are MySQL backends too.. I'd probably start
> there... the more I worked with them the more complicated I came to realise
> queues are.. lean on the shoulders of giants and all that ;)
>
> Martin
>
> *Martin Renvoize*
>
> Development Manager
>
>
>
>
> *T:* +44 (0) 1483 378728 <+44%201483%20378728>
>
> *F:* +44 (0) 800 756 6384 <+44%20800%20756%206384>
>
> *E:* martin.renvoize at ptfs-europe.com
>
> www.ptfs-europe.com
>
>
>
> <https://www.ptfs-europe.com>
>
>
>
> Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30
>
> The information contained in this email message may be privileged,
> confidential and protected from disclosure. If you are not the intended
> recipient, any dissemination, distribution or copying is strictly
> prohibited. If you think that you have received this email message in
> error, please email the sender at info at ptfs-europe.com
>
>
> On 14 June 2018 at 17:16, Jonathan Druart <
> jonathan.druart at bugs.koha-community.org> wrote:
>
>> Few links:
>>
>> http://lists.koha-community.org/pipermail/koha-devel/2017-February/043489.html
>> *Bug 10662*
>> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662> - Build
>> OAI-PMH Harvesting Client
>> *Bug 15032*
>> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15032> - [Plack]
>> Scripts that fork (like stage-marc-import.pl) don't work as expected
>>
>> Basically we need a daemon watching a job queue (DB table) to answer all
>> these needs at once.
>> I have started something already, I will get back to it when I will have
>> time (and motivation).
>>
>> Cheers,
>> Jonathan
>>
>> On Thu, 14 Jun 2018 at 12:59 Barton Chittenden <
>> barton at bywatersolutions.com> wrote:
>>
>>> This is an old issue that's never really been addressed. As I understand
>>> it, at one time, we had a tool that used the unix 'at' scheduler to run
>>> requested reports. This was a huge security hole, and we disabled it....
>>> and it's never worked since.
>>>
>>> As such, those who host servers must add calls to runreport.pl by hand.
>>>
>>> Bug 1993 was opened to address this. It was marked as 'In Discussion' in
>>> 2013. I would like to see this move forward -- server admins are dying from
>>> a thousand paper cuts, and I think that users would benefit from having
>>> more control over when their reports are scheduled.
>>>
>>> What still needs to be discussed here?
>>>
>>> Thanks,
>>>
>>> --Barton
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at lists.koha-community.org
>>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>> website : http://www.koha-community.org/
>>> git : http://git.koha-community.org/
>>> bugs : http://bugs.koha-community.org/
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180618/666abb50/attachment-0001.html>

From fridolin.somers at biblibre.com  Mon Jun 18 15:38:47 2018
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Mon, 18 Jun 2018 15:38:47 +0200
Subject: [Koha-devel] Cronjob to run plugin cronjobs?
In-Reply-To: <CAA_eX3O1s6LNb4AKVgurUj61jWrpD-EN--gABUm3Kh=jthdwXw@mail.gmail.com>
References: <CAA_eX3O1s6LNb4AKVgurUj61jWrpD-EN--gABUm3Kh=jthdwXw@mail.gmail.com>
Message-ID: <ca123593-304a-2a30-7c2a-20d8fdcd18e4@biblibre.com>

Nice idea I would say.
I think may PHP softwares with plugins do this and you usually have only 
1 job in crontab  ^ ^

Le 07/06/2018 ? 19:47, Nick Clemens a ?crit?:
> Just an idea I had an bounced off Kyle, he suggested sending it out for
> feedback, let us knwo what you think:
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20897
> 
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
BibLibre, France - software and system maintainer

From jonathan.druart at bugs.koha-community.org  Mon Jun 18 16:07:03 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Mon, 18 Jun 2018 11:07:03 -0300
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email via
	message queue?
In-Reply-To: <CAA7=B8wB37-9NkgwzJ3XTCf3nxwNh4BFcZZpaJcWnkrwgy5Okg@mail.gmail.com>
References: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>
	<e4037673-769f-beac-478e-8721661a637c@biblibre.com>
	<040b01d406dc$701e1b20$505a5160$@prosentient.com.au>
	<CAA7=B8wB37-9NkgwzJ3XTCf3nxwNh4BFcZZpaJcWnkrwgy5Okg@mail.gmail.com>
Message-ID: <CAJzKNY59WRhA56ySBb_v+8SCdPVgD2guGPzXM12EuMkQESbsUA@mail.gmail.com>

It has been reported (by David) on our bug tracker already (20796, security
area, which does no longer make sense at it is public now...)

For information this notice contains the password in clear for... 10 years
now (bug 2149) and the behavior is turned off by default
(AutoEmailOpacUser).


On Mon, 18 Jun 2018 at 10:11 Christopher Nighswonger <
chris.nighswonger at gmail.com> wrote:

> Considering that email is plaintext (AKA "postcard") mail, I'm surprised
> we would send a user's password in an email in any case.
>
>
> On Mon, Jun 18, 2018 at 4:14 AM, David Cook <dcook at prosentient.com.au>
> wrote:
>
>> Considering that the borrower?s password is typically in the ACCTDETAILS
>> email, I think using the message_queue for ACCTDETAILS would be a bad idea
>> and would probably violate the GDPR in Europe.
>>
>>
>>
>> Just imagine looking through your database and seeing all those plain
>> text passwords, especially for people who re-use the same password for
>> everything. I think it would be a security and privacy nightmare.
>>
>>
>>
>> David Cook
>>
>> Systems Librarian
>>
>> Prosentient Systems
>>
>> 72/330 Wattle St
>>
>> Ultimo, NSW 2007
>>
>> Australia
>>
>>
>>
>> Office: 02 9212 0899 <02%2092%2012%2008%2099>
>>
>> Direct: 02 8005 0595 <02%2080%2005%2005%2095>
>>
>>
>>
>> *From:* koha-devel-bounces at lists.koha-community.org [mailto:
>> koha-devel-bounces at lists.koha-community.org] *On Behalf Of *Sophie
>> Meynieux
>> *Sent:* Friday, 15 June 2018 9:33 PM
>> *To:* koha-devel at lists.koha-community.org
>> *Subject:* Re: [Koha-devel] Why we do not push the ACCTDETAILS email via
>> message queue?
>>
>>
>>
>> Maybe because for this message you're expecting it is sent immediately
>> while message_queue table could be processed more occasionally ?
>>
>> Best regards
>>
>> S. Meynieux
>>
>> --
>>
>> Responsable support
>>
>> BibLibre
>>
>> + 33 (0)4 91 81 35 08 <04%2091%2081%2035%2008>
>>
>> http://www.biblibre.com
>>
>> Le 15/06/2018 ? 12:40, Indranil Das Gupta a ?crit :
>>
>> Hi all,
>>
>>
>>
>> I was wondering why we do not push the ACCTDETAILS email via  the message
>> queue.
>>
>>
>>
>> Is it just one of those cases of "as things have always been done" OR
>> there is a reason that I'm missing out?
>>
>>
>>
>> cheers
>>
>> indranil.
>>
>>
>> Indranil Das Gupta
>> L2C2 Technologies
>>
>> Phone : +91-98300-20971 <+91%2098300%2020971>
>> Blog    : http://blog.l2c2.co.in
>> IRC     : indradg on irc://irc.freenode.net
>> Twitter : indradg
>>
>>
>>
>>
>> _______________________________________________
>>
>> Koha-devel mailing list
>>
>> Koha-devel at lists.koha-community.org
>>
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>
>> website : http://www.koha-community.org/
>>
>> git : http://git.koha-community.org/
>>
>> bugs : http://bugs.koha-community.org/
>>
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180618/3a922332/attachment.html>

From katrin.fischer.83 at web.de  Mon Jun 18 22:22:05 2018
From: katrin.fischer.83 at web.de (Katrin Fischer)
Date: Mon, 18 Jun 2018 22:22:05 +0200
Subject: [Koha-devel] Staff/OPAC ISBD views and subfield visibility
In-Reply-To: <CAK0RUrtUaS4hMCHHa1Jm7ZztnHUAMAv+Kg__Vd7sG6WoiuGPvw@mail.gmail.com>
References: <CAK0RUrtUaS4hMCHHa1Jm7ZztnHUAMAv+Kg__Vd7sG6WoiuGPvw@mail.gmail.com>
Message-ID: <30185c75-94e7-2707-cc35-b8f6ef205888@web.de>

Hi Andreas,

I might be misunderstanding your question, but the OPAC visibility 
setting should take effect on all pages and views in the OPAC now. It 
didn't use to, which was considered a long standing bug and finally 
fixed. Now it's possible to hide fields from OPAC that can still appear 
in staff in a reliable way. The preconfigured visibility settings in the 
frameworks might not always be ideal - if that's what you mean, we could 
work on improving them.

Hope that helps,

Katrin

On 07.06.2018 09:21, Andreas Roussos wrote:
> Dear Developers,
>
> If you:
>
> 1) edit the ISBD and OPACISBD system preferences so that they contain 
> the following code:
>
> #453| - translated as: |<a 
> href="/cgi-bin/koha/catalogue/detail.pl?biblionumber={4530} 
> <http://detail.pl?biblionumber=%7B4530%7D>">{453t}</a> {(453d)}|
> #454| - translation of: |<a 
> href="/cgi-bin/koha/catalogue/detail.pl?biblionumber={4540} 
> <http://detail.pl?biblionumber=%7B4540%7D>">{454t}</a> {(454d)}|
>
> 2) set the visibility of (UNIMARC) fields 453$0 and 454$0 to 'hidden' 
> in the OPAC
>
> ...then the generated links will work fine in the Staff client but 
> will be broken in the OPAC (i.e. the URL will not include the 
> biblionumber contained in subfield 0 of fields 453/454).
>
> I've tracked this down to ISBDdetail.pl and opac-ISBDdetail.pl calling 
> the GetISBDView subroutine, which (for some reason) excludes subfields 
> that are hidden in the OPAC:
>
> https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L773-L776
> https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L812-L815
>
> What is the reasoning behind this?
> In other words, why is _OPAC_ subfield visibility taken into account 
> when displaying the OPAC ISBD view (whereas visibility in Staff is not 
> considered)?
>
> If anything, it is more likely to have subfield 0 hidden in OPAC, 
> while visible in Staff, so one would expect the opposite logic.
>
> Thanks in advance for your time.
>
> Kind regards,
> Andreas Roussos
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180618/ddd4f4b4/attachment-0001.html>

From barton at bywatersolutions.com  Tue Jun 19 01:15:39 2018
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Mon, 18 Jun 2018 19:15:39 -0400
Subject: [Koha-devel] Should the first 3 digits of cn_sort be sorted for
 dewey decimal?
In-Reply-To: <CAMSJbVtY+W6qPa89cVuRM3_kQ6mnMw_g+f7KAVaBGVDR-JWaxg@mail.gmail.com>
References: <CAMSJbVsH7==Ccd+ggmKStFP+mb27JTnpV4VqYG+cie15sa82Sw@mail.gmail.com>
	<bbe7e1e6-0af2-d921-6f64-46b86c6a0308@adminkuhn.ch>
	<CAMSJbVtRXLC55V-1nPm2MK_ogkzZ_j9bCVtFh+g6iXactM7N3A@mail.gmail.com>
	<f0c36ab6-9512-305f-806b-b04add64b2fc@adminkuhn.ch>
	<CAMSJbVtY+W6qPa89cVuRM3_kQ6mnMw_g+f7KAVaBGVDR-JWaxg@mail.gmail.com>
Message-ID: <CAMSJbVt8kUnOnHOTr8DeDFhG125tyv5nSwLu6WuTyABp4SaSiw@mail.gmail.com>

I've filed

Bug 20961   : cn_sort for DDC callnumbers should between 1 and 99 should be
formatted as 001.* - 099.*
URL         :
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20961
Priority    : P5 - low
Assigned To : koha-bugs at lists.koha-community.org
Urgency     : enhancement
Status      : NEW


On Sat, Jun 16, 2018 at 3:32 PM, Barton Chittenden <
barton at bywatersolutions.com> wrote:

> Very interesting!
>
> Thanks for the link.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180618/a34cec6d/attachment.html>

From dcook at prosentient.com.au  Tue Jun 19 02:21:11 2018
From: dcook at prosentient.com.au (David Cook)
Date: Tue, 19 Jun 2018 10:21:11 +1000
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email via
	message queue?
In-Reply-To: <CAJzKNY59WRhA56ySBb_v+8SCdPVgD2guGPzXM12EuMkQESbsUA@mail.gmail.com>
References: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>
	<e4037673-769f-beac-478e-8721661a637c@biblibre.com>
	<040b01d406dc$701e1b20$505a5160$@prosentient.com.au>
	<CAA7=B8wB37-9NkgwzJ3XTCf3nxwNh4BFcZZpaJcWnkrwgy5Okg@mail.gmail.com>
	<CAJzKNY59WRhA56ySBb_v+8SCdPVgD2guGPzXM12EuMkQESbsUA@mail.gmail.com>
Message-ID: <049f01d40763$6ce87f40$46b97dc0$@prosentient.com.au>

Cheers, Jonathan. I had totally forgotten about that. Yikes.

 

Good call, Chris. While I think many mail servers these days use TLS to secure the email between the mail servers, an unscrupulous administrator could still certainly take advantage of people on either end. The best idea probably is to just not use AutoEmailOpacUser, as Jonathan seems to suggest. 

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: Jonathan Druart [mailto:jonathan.druart at bugs.koha-community.org] 
Sent: Tuesday, 19 June 2018 12:07 AM
To: Christopher Nighswonger <chris.nighswonger at gmail.com>
Cc: David Cook <dcook at prosentient.com.au>; Koha Devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?

 

It has been reported (by David) on our bug tracker already (20796, security area, which does no longer make sense at it is public now...)

 

For information this notice contains the password in clear for... 10 years now (bug 2149) and the behavior is turned off by default (AutoEmailOpacUser).

 

 

On Mon, 18 Jun 2018 at 10:11 Christopher Nighswonger <chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com> > wrote:

Considering that email is plaintext (AKA "postcard") mail, I'm surprised we would send a user's password in an email in any case.

 

 

On Mon, Jun 18, 2018 at 4:14 AM, David Cook <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > wrote:

Considering that the borrower?s password is typically in the ACCTDETAILS email, I think using the message_queue for ACCTDETAILS would be a bad idea and would probably violate the GDPR in Europe.

 

Just imagine looking through your database and seeing all those plain text passwords, especially for people who re-use the same password for everything. I think it would be a security and privacy nightmare.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899 <tel:02%2092%2012%2008%2099> 

Direct: 02 8005 0595 <tel:02%2080%2005%2005%2095> 

 

From: koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org>  [mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> ] On Behalf Of Sophie Meynieux
Sent: Friday, 15 June 2018 9:33 PM
To: koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> 
Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?

 

Maybe because for this message you're expecting it is sent immediately while message_queue table could be processed more occasionally ? 

Best regards

S. Meynieux

-- 
Responsable support 
BibLibre
+ 33 (0)4 91 81 35 08 <tel:04%2091%2081%2035%2008> 
http://www.biblibre.com

Le 15/06/2018 ? 12:40, Indranil Das Gupta a ?crit :

Hi all, 

 

I was wondering why we do not push the ACCTDETAILS email via  the message queue.

 

Is it just one of those cases of "as things have always been done" OR there is a reason that I'm missing out?

 

cheers

indranil.


Indranil Das Gupta
L2C2 Technologies

Phone : +91-98300-20971 <tel:+91%2098300%2020971> 
Blog    : http://blog.l2c2.co.in
IRC     : indradg on irc://irc.freenode.net <http://irc.freenode.net> 
Twitter : indradg





_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

 


_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

 

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180619/6cc804c6/attachment.html>

From liz at catalyst.net.nz  Tue Jun 19 04:25:53 2018
From: liz at catalyst.net.nz (Liz Rea)
Date: Tue, 19 Jun 2018 14:25:53 +1200
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email via
 message queue?
In-Reply-To: <049f01d40763$6ce87f40$46b97dc0$@prosentient.com.au>
References: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>
	<e4037673-769f-beac-478e-8721661a637c@biblibre.com>
	<040b01d406dc$701e1b20$505a5160$@prosentient.com.au>
	<CAA7=B8wB37-9NkgwzJ3XTCf3nxwNh4BFcZZpaJcWnkrwgy5Okg@mail.gmail.com>
	<CAJzKNY59WRhA56ySBb_v+8SCdPVgD2guGPzXM12EuMkQESbsUA@mail.gmail.com>
	<049f01d40763$6ce87f40$46b97dc0$@prosentient.com.au>
Message-ID: <73dea149-f45c-2926-0f8d-5f8383d8ba30@catalyst.net.nz>

I feel like instead of sending people a password, we should send them to
the "forgot password reset page" with a couple of slight changes for new
account holders, so they can set their own passwords.

Seems better than sending the password in the clear in an email.

Cheers,
Liz


On 19/06/18 12:21, David Cook wrote:
> Cheers, Jonathan. I had totally forgotten about that. Yikes.
>
>  
>
> Good call, Chris. While I think many mail servers these days use TLS to secure the email between the mail servers, an unscrupulous administrator could still certainly take advantage of people on either end. The best idea probably is to just not use AutoEmailOpacUser, as Jonathan seems to suggest. 
>
>  
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
>  
>
> Office: 02 9212 0899
>
> Direct: 02 8005 0595
>
>  
>
> From: Jonathan Druart [mailto:jonathan.druart at bugs.koha-community.org] 
> Sent: Tuesday, 19 June 2018 12:07 AM
> To: Christopher Nighswonger <chris.nighswonger at gmail.com>
> Cc: David Cook <dcook at prosentient.com.au>; Koha Devel <koha-devel at lists.koha-community.org>
> Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?
>
>  
>
> It has been reported (by David) on our bug tracker already (20796, security area, which does no longer make sense at it is public now...)
>
>  
>
> For information this notice contains the password in clear for... 10 years now (bug 2149) and the behavior is turned off by default (AutoEmailOpacUser).
>
>  
>
>  
>
> On Mon, 18 Jun 2018 at 10:11 Christopher Nighswonger <chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com> > wrote:
>
> Considering that email is plaintext (AKA "postcard") mail, I'm surprised we would send a user's password in an email in any case.
>
>  
>
>  
>
> On Mon, Jun 18, 2018 at 4:14 AM, David Cook <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > wrote:
>
> Considering that the borrower?s password is typically in the ACCTDETAILS email, I think using the message_queue for ACCTDETAILS would be a bad idea and would probably violate the GDPR in Europe.
>
>  
>
> Just imagine looking through your database and seeing all those plain text passwords, especially for people who re-use the same password for everything. I think it would be a security and privacy nightmare.
>
>  
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
>  
>
> Office: 02 9212 0899 <tel:02%2092%2012%2008%2099> 
>
> Direct: 02 8005 0595 <tel:02%2080%2005%2005%2095> 
>
>  
>
> From: koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org>  [mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> ] On Behalf Of Sophie Meynieux
> Sent: Friday, 15 June 2018 9:33 PM
> To: koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> 
> Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?
>
>  
>
> Maybe because for this message you're expecting it is sent immediately while message_queue table could be processed more occasionally ? 
>
> Best regards
>
> S. Meynieux
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142
04 803 2265

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180619/ee4c5818/attachment-0001.html>

From paul.poulain at biblibre.com  Tue Jun 19 13:26:29 2018
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 19 Jun 2018 13:26:29 +0200
Subject: [Koha-devel] Partnership between BibLibre and Orex
Message-ID: <31005b65-d04d-8cfa-4fb7-693b893f283a@biblibre.com>

Hello Koha,

Hugo & I are happy and proud to announce our partnership to increase 
Koha deployment in Spain and other Spanish speaking countries : 
https://www.biblibre.com/en/blog/orex-and-biblibre-join-their-strength-to-propose-open-source-solutions-to-spanish-libraries/

-- 
Paul Poulain, Associ?-g?rant / co-owner
BibLibre, Services en logiciels libres pour les biblioth?ques
BibLibre, Open Source software and services for libraries


From dcook at prosentient.com.au  Wed Jun 20 02:06:52 2018
From: dcook at prosentient.com.au (David Cook)
Date: Wed, 20 Jun 2018 10:06:52 +1000
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email via
	message queue?
In-Reply-To: <73dea149-f45c-2926-0f8d-5f8383d8ba30@catalyst.net.nz>
References: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>	<e4037673-769f-beac-478e-8721661a637c@biblibre.com>	<040b01d406dc$701e1b20$505a5160$@prosentient.com.au>	<CAA7=B8wB37-9NkgwzJ3XTCf3nxwNh4BFcZZpaJcWnkrwgy5Okg@mail.gmail.com>	<CAJzKNY59WRhA56ySBb_v+8SCdPVgD2guGPzXM12EuMkQESbsUA@mail.gmail.com>	<049f01d40763$6ce87f40$46b97dc0$@prosentient.com.au>
	<73dea149-f45c-2926-0f8d-5f8383d8ba30@catalyst.net.nz>
Message-ID: <04ec01d4082a$97555e70$c6001b50$@prosentient.com.au>

I think that would probably be the best way of going about it, but I?m sure there are a lot of libraries that wouldn?t be happy about it. 

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Liz Rea
Sent: Tuesday, 19 June 2018 12:26 PM
To: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?

 

I feel like instead of sending people a password, we should send them to the "forgot password reset page" with a couple of slight changes for new account holders, so they can set their own passwords.

Seems better than sending the password in the clear in an email.

Cheers,
Liz

 

On 19/06/18 12:21, David Cook wrote:

Cheers, Jonathan. I had totally forgotten about that. Yikes.
 
 
 
Good call, Chris. While I think many mail servers these days use TLS to secure the email between the mail servers, an unscrupulous administrator could still certainly take advantage of people on either end. The best idea probably is to just not use AutoEmailOpacUser, as Jonathan seems to suggest. 
 
 
 
David Cook
 
Systems Librarian
 
Prosentient Systems
 
72/330 Wattle St
 
Ultimo, NSW 2007
 
Australia
 
 
 
Office: 02 9212 0899
 
Direct: 02 8005 0595
 
 
 
From: Jonathan Druart [mailto:jonathan.druart at bugs.koha-community.org] 
Sent: Tuesday, 19 June 2018 12:07 AM
To: Christopher Nighswonger  <mailto:chris.nighswonger at gmail.com> <chris.nighswonger at gmail.com>
Cc: David Cook  <mailto:dcook at prosentient.com.au> <dcook at prosentient.com.au>; Koha Devel  <mailto:koha-devel at lists.koha-community.org> <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?
 
 
 
It has been reported (by David) on our bug tracker already (20796, security area, which does no longer make sense at it is public now...)
 
 
 
For information this notice contains the password in clear for... 10 years now (bug 2149) and the behavior is turned off by default (AutoEmailOpacUser).
 
 
 
 
 
On Mon, 18 Jun 2018 at 10:11 Christopher Nighswonger <chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com>   <mailto:chris.nighswonger at gmail.com> <mailto:chris.nighswonger at gmail.com> > wrote:
 
Considering that email is plaintext (AKA "postcard") mail, I'm surprised we would send a user's password in an email in any case.
 
 
 
 
 
On Mon, Jun 18, 2018 at 4:14 AM, David Cook <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>   <mailto:dcook at prosentient.com.au> <mailto:dcook at prosentient.com.au> > wrote:
 
Considering that the borrower?s password is typically in the ACCTDETAILS email, I think using the message_queue for ACCTDETAILS would be a bad idea and would probably violate the GDPR in Europe.
 
 
 
Just imagine looking through your database and seeing all those plain text passwords, especially for people who re-use the same password for everything. I think it would be a security and privacy nightmare.
 
 
 
David Cook
 
Systems Librarian
 
Prosentient Systems
 
72/330 Wattle St
 
Ultimo, NSW 2007
 
Australia
 
 
 
Office: 02 9212 0899 <tel:02%2092%2012%2008%2099> 
 
Direct: 02 8005 0595 <tel:02%2080%2005%2005%2095> 
 
 
 
From: koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org>   <mailto:koha-devel-bounces at lists.koha-community.org> <mailto:koha-devel-bounces at lists.koha-community.org>  [mailto:koha-devel-bounces at lists.koha-community.org  <mailto:koha-devel-bounces at lists.koha-community.org> <mailto:koha-devel-bounces at lists.koha-community.org> ] On Behalf Of Sophie Meynieux
Sent: Friday, 15 June 2018 9:33 PM
To: koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org>   <mailto:koha-devel at lists.koha-community.org> <mailto:koha-devel at lists.koha-community.org> 
Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?
 
 
 
Maybe because for this message you're expecting it is sent immediately while message_queue table could be processed more occasionally ? 
 
Best regards
 
S. Meynieux
 






_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/





-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142
04 803 2265
 
GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180620/882d749a/attachment.html>

From chrisc at catalyst.net.nz  Wed Jun 20 02:12:10 2018
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Wed, 20 Jun 2018 12:12:10 +1200
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email
	via	message queue?
In-Reply-To: <04ec01d4082a$97555e70$c6001b50$@prosentient.com.au>
References: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>
	<e4037673-769f-beac-478e-8721661a637c@biblibre.com>
	<040b01d406dc$701e1b20$505a5160$@prosentient.com.au>
	<CAA7=B8wB37-9NkgwzJ3XTCf3nxwNh4BFcZZpaJcWnkrwgy5Okg@mail.gmail.com>
	<CAJzKNY59WRhA56ySBb_v+8SCdPVgD2guGPzXM12EuMkQESbsUA@mail.gmail.com>
	<049f01d40763$6ce87f40$46b97dc0$@prosentient.com.au>
	<73dea149-f45c-2926-0f8d-5f8383d8ba30@catalyst.net.nz>
	<04ec01d4082a$97555e70$c6001b50$@prosentient.com.au>
Message-ID: <CE015A21-1EA4-41BE-AFFA-778904BF14E6@catalyst.net.nz>

We could make a list of them. It could be the "libraries who don't care about their users privacy" list.

I'm only mostly joking

Chris 

On June 20, 2018 12:06:52 PM GMT+12:00, David Cook <dcook at prosentient.com.au> wrote:
>I think that would probably be the best way of going about it, but I?m
>sure there are a lot of libraries that wouldn?t be happy about it. 
>
> 
>
>David Cook
>
>Systems Librarian
>
>Prosentient Systems
>
>72/330 Wattle St
>
>Ultimo, NSW 2007
>
>Australia
>
> 
>
>Office: 02 9212 0899
>
>Direct: 02 8005 0595
>
> 
>
>From: koha-devel-bounces at lists.koha-community.org
>[mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Liz
>Rea
>Sent: Tuesday, 19 June 2018 12:26 PM
>To: koha-devel at lists.koha-community.org
>Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via
>message queue?
>
> 
>
>I feel like instead of sending people a password, we should send them
>to the "forgot password reset page" with a couple of slight changes for
>new account holders, so they can set their own passwords.
>
>Seems better than sending the password in the clear in an email.
>
>Cheers,
>Liz
>
> 
>
>On 19/06/18 12:21, David Cook wrote:
>
>Cheers, Jonathan. I had totally forgotten about that. Yikes.
> 
> 
> 
>Good call, Chris. While I think many mail servers these days use TLS to
>secure the email between the mail servers, an unscrupulous
>administrator could still certainly take advantage of people on either
>end. The best idea probably is to just not use AutoEmailOpacUser, as
>Jonathan seems to suggest. 
> 
> 
> 
>David Cook
> 
>Systems Librarian
> 
>Prosentient Systems
> 
>72/330 Wattle St
> 
>Ultimo, NSW 2007
> 
>Australia
> 
> 
> 
>Office: 02 9212 0899
> 
>Direct: 02 8005 0595
> 
> 
> 
>From: Jonathan Druart [mailto:jonathan.druart at bugs.koha-community.org] 
>Sent: Tuesday, 19 June 2018 12:07 AM
>To: Christopher Nighswonger  <mailto:chris.nighswonger at gmail.com>
><chris.nighswonger at gmail.com>
>Cc: David Cook  <mailto:dcook at prosentient.com.au>
><dcook at prosentient.com.au>; Koha Devel 
><mailto:koha-devel at lists.koha-community.org>
><koha-devel at lists.koha-community.org>
>Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via
>message queue?
> 
> 
> 
>It has been reported (by David) on our bug tracker already (20796,
>security area, which does no longer make sense at it is public now...)
> 
> 
> 
>For information this notice contains the password in clear for... 10
>years now (bug 2149) and the behavior is turned off by default
>(AutoEmailOpacUser).
> 
> 
> 
> 
> 
>On Mon, 18 Jun 2018 at 10:11 Christopher Nighswonger
><chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com>  
><mailto:chris.nighswonger at gmail.com>
><mailto:chris.nighswonger at gmail.com> > wrote:
> 
>Considering that email is plaintext (AKA "postcard") mail, I'm
>surprised we would send a user's password in an email in any case.
> 
> 
> 
> 
> 
>On Mon, Jun 18, 2018 at 4:14 AM, David Cook <dcook at prosentient.com.au
><mailto:dcook at prosentient.com.au>   <mailto:dcook at prosentient.com.au>
><mailto:dcook at prosentient.com.au> > wrote:
> 
>Considering that the borrower?s password is typically in the
>ACCTDETAILS email, I think using the message_queue for ACCTDETAILS
>would be a bad idea and would probably violate the GDPR in Europe.
> 
> 
> 
>Just imagine looking through your database and seeing all those plain
>text passwords, especially for people who re-use the same password for
>everything. I think it would be a security and privacy nightmare.
> 
> 
> 
>David Cook
> 
>Systems Librarian
> 
>Prosentient Systems
> 
>72/330 Wattle St
> 
>Ultimo, NSW 2007
> 
>Australia
> 
> 
> 
>Office: 02 9212 0899 <tel:02%2092%2012%2008%2099> 
> 
>Direct: 02 8005 0595 <tel:02%2080%2005%2005%2095> 
> 
> 
> 
>From: koha-devel-bounces at lists.koha-community.org
><mailto:koha-devel-bounces at lists.koha-community.org>  
><mailto:koha-devel-bounces at lists.koha-community.org>
><mailto:koha-devel-bounces at lists.koha-community.org> 
>[mailto:koha-devel-bounces at lists.koha-community.org 
><mailto:koha-devel-bounces at lists.koha-community.org>
><mailto:koha-devel-bounces at lists.koha-community.org> ] On Behalf Of
>Sophie Meynieux
>Sent: Friday, 15 June 2018 9:33 PM
>To: koha-devel at lists.koha-community.org
><mailto:koha-devel at lists.koha-community.org>  
><mailto:koha-devel at lists.koha-community.org>
><mailto:koha-devel at lists.koha-community.org> 
>Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via
>message queue?
> 
> 
> 
>Maybe because for this message you're expecting it is sent immediately
>while message_queue table could be processed more occasionally ? 
> 
>Best regards
> 
>S. Meynieux
> 
>
>
>
>
>
>
>_______________________________________________
>Koha-devel mailing list
>Koha-devel at lists.koha-community.org
><mailto:Koha-devel at lists.koha-community.org> 
>http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>website : http://www.koha-community.org/
>git : http://git.koha-community.org/
>bugs : http://bugs.koha-community.org/
>
>
>
>
>
>-- 
>--
>Liz Rea
>Catalyst.Net Limited
>Level 6, Catalyst House, 
>150 Willis Street, Wellington.
>P.O Box 11053, Manners Street, 
>Wellington 6142
>04 803 2265
> 
>GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180620/8cf771e4/attachment-0001.html>

From dcook at prosentient.com.au  Wed Jun 20 02:19:51 2018
From: dcook at prosentient.com.au (David Cook)
Date: Wed, 20 Jun 2018 10:19:51 +1000
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email
	via	message queue?
In-Reply-To: <CE015A21-1EA4-41BE-AFFA-778904BF14E6@catalyst.net.nz>
References: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>
	<e4037673-769f-beac-478e-8721661a637c@biblibre.com>
	<040b01d406dc$701e1b20$505a5160$@prosentient.com.au>
	<CAA7=B8wB37-9NkgwzJ3XTCf3nxwNh4BFcZZpaJcWnkrwgy5Okg@mail.gmail.com>
	<CAJzKNY59WRhA56ySBb_v+8SCdPVgD2guGPzXM12EuMkQESbsUA@mail.gmail.com>
	<049f01d40763$6ce87f40$46b97dc0$@prosentient.com.au>
	<73dea149-f45c-2926-0f8d-5f8383d8ba30@catalyst.net.nz>
	<04ec01d4082a$97555e70$c6001b50$@prosentient.com.au>
	<CE015A21-1EA4-41BE-AFFA-778904BF14E6@catalyst.net.nz>
Message-ID: <04fa01d4082c$67fd6530$37f82f90$@prosentient.com.au>

I think that?s not a bad way of looking at it. If people do complain, we can say that the change away was because of a commitment to patron security and privacy. I would hope that people would find that difficult to argue against. 

 

If I recall correctly, I think DSpace does it this way. When you create a new user, I think it sends an email containing a URL with a token to the user, and then they set their own password from there. It works pretty well. Surely we could say ?everybody else is doing it? as well. 

 

But I know that there are a lot of libraries using this feature, and it would be disruptive to their existing workflows for it to go away. But? that?s also progress for you. So long as people have notice that it?s going away before the upgrade, they?d have time to change their workflows and adapt to a safer way of doing things?

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: Chris Cormack [mailto:chrisc at catalyst.net.nz] 
Sent: Wednesday, 20 June 2018 10:12 AM
To: koha-devel at lists.koha-community.org; David Cook <dcook at prosentient.com.au>; 'Liz Rea' <liz at catalyst.net.nz>
Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?

 

We could make a list of them. It could be the "libraries who don't care about their users privacy" list.

I'm only mostly joking

Chris 

On June 20, 2018 12:06:52 PM GMT+12:00, David Cook <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > wrote:

I think that would probably be the best way of going about it, but I?m sure there are a lot of libraries that wouldn?t be happy about it. 

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org>  [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Liz Rea
Sent: Tuesday, 19 June 2018 12:26 PM
To: koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> 
Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?

 

I feel like instead of sending people a password, we should send them to the "forgot password reset page" with a couple of slight changes for new account holders, so they can set their own passwords.

Seems better than sending the password in the clear in an email.

Cheers,
Liz

 

On 19/06/18 12:21, David Cook wrote:

Cheers, Jonathan. I had totally forgotten about that. Yikes.
 
 
 
Good call, Chris. While I think many mail servers these days use TLS to secure the email between the mail servers, an unscrupulous administrator could still certainly take advantage of people on either end. The best idea probably is to just not use AutoEmailOpacUser, as Jonathan seems to suggest. 
 
 
 
David Cook
 
Systems Librarian
 
Prosentient Systems
 
72/330 Wattle St
 
Ultimo, NSW 2007
 
Australia
 
 
 
Office: 02 9212 0899
 
Direct: 02 8005 0595
 
 
 
From: Jonathan Druart [mailto:jonathan.druart at bugs.koha-community.org] 
Sent: Tuesday, 19 June 2018 12:07 AM
To: Christopher Nighswonger  <mailto:chris.nighswonger at gmail.com> <chris.nighswonger at gmail.com>
Cc: David Cook  <mailto:dcook at prosentient.com.au> <dcook at prosentient.com.au>; Koha Devel  <mailto:koha-devel at lists.koha-community.org> <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?
 
 
 
It has been reported (by David) on our bug tracker already (20796, security area, which does no longer make sense at it is public now...)
 
 
 
For information this notice contains the password in clear for... 10 years now (bug 2149) and the behavior is turned off by default (AutoEmailOpacUser).
 
 
 
 
 
On Mon, 18 Jun 2018 at 10:11 Christopher Nighswonger <chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com>   <mailto:chris.nighswonger at gmail.com> <mailto:chris.nighswonger at gmail.com> > wrote:
 
Considering that email is plaintext (AKA "postcard") mail, I'm surprised we would send a user's password in an email in any case.
 
 
 
 
 
On Mon, Jun 18, 2018 at 4:14 AM, David Cook <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>   <mailto:dcook at prosentient.com.au> <mailto:dcook at prosentient.com.au> > wrote:
 
Considering that the borrower?s password is typically in the ACCTDETAILS email, I think using the message_queue for ACCTDETAILS would be a bad idea and would probably violate the GDPR in Europe.
 
 
 
Just imagine looking through your database and seeing all those plain text passwords, especially for people who re-use the same password for everything. I think it would be a security and privacy nightmare.
 
 
 
David Cook
 
Systems Librarian
 
Prosentient Systems
 
72/330 Wattle St
 
Ultimo, NSW 2007
 
Australia
 
 
 
Office: 02 9212 0899 <tel:02%2092%2012%2008%2099> 
 
Direct: 02 8005 0595 <tel:02%2080%2005%2005%2095> 
 
 
 
From: koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org>   <mailto:koha-devel-bounces at lists.koha-community.org> <mailto:koha-devel-bounces at lists.koha-community.org>  [mailto:koha-devel-bounces at lists.koha-community.org  <mailto:koha-devel-bounces at lists.koha-community.org> <mailto:koha-devel-bounces at lists.koha-community.org> ] On Behalf Of Sophie Meynieux
Sent: Friday, 15 June 2018 9:33 PM
To: koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org>   <mailto:koha-devel at lists.koha-community.org> <mailto:koha-devel at lists.koha-community.org> 
Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?
 
 
 
Maybe because for this message you're expecting it is sent immediately while message_queue table could be processed more occasionally ? 
 
Best regards
 
S. Meynieux
 





_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

 

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142
04 803 2265
 
GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180620/15d64fe9/attachment.html>

From liz at catalyst.net.nz  Wed Jun 20 02:25:23 2018
From: liz at catalyst.net.nz (Liz Rea)
Date: Wed, 20 Jun 2018 12:25:23 +1200
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email via
 message queue?
In-Reply-To: <04fa01d4082c$67fd6530$37f82f90$@prosentient.com.au>
References: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>
	<e4037673-769f-beac-478e-8721661a637c@biblibre.com>
	<040b01d406dc$701e1b20$505a5160$@prosentient.com.au>
	<CAA7=B8wB37-9NkgwzJ3XTCf3nxwNh4BFcZZpaJcWnkrwgy5Okg@mail.gmail.com>
	<CAJzKNY59WRhA56ySBb_v+8SCdPVgD2guGPzXM12EuMkQESbsUA@mail.gmail.com>
	<049f01d40763$6ce87f40$46b97dc0$@prosentient.com.au>
	<73dea149-f45c-2926-0f8d-5f8383d8ba30@catalyst.net.nz>
	<04ec01d4082a$97555e70$c6001b50$@prosentient.com.au>
	<CE015A21-1EA4-41BE-AFFA-778904BF14E6@catalyst.net.nz>
	<04fa01d4082c$67fd6530$37f82f90$@prosentient.com.au>
Message-ID: <0c1dcf01-3448-db9c-2530-f97a85d66a9a@catalyst.net.nz>

The easy answer is : leave it alone for existing installs, default it on 
for new ones.



On 20/06/18 12:19, David Cook wrote:
>
> I think that?s not a bad way of looking at it. If people do complain, 
> we can say that the change away was because of a commitment to patron 
> security and privacy. I would hope that people would find that 
> difficult to argue against.
>
> If I recall correctly, I think DSpace does it this way. When you 
> create a new user, I think it sends an email containing a URL with a 
> token to the user, and then they set their own password from there. It 
> works pretty well. Surely we could say ?everybody else is doing it? as 
> well.
>
> But I know that there are a lot of libraries using this feature, and 
> it would be disruptive to their existing workflows for it to go away. 
> But? that?s also progress for you. So long as people have notice that 
> it?s going away before the upgrade, they?d have time to change their 
> workflows and adapt to a safer way of doing things?
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
> Office: 02 9212 0899
>
> Direct: 02 8005 0595
>
> *From:*Chris Cormack [mailto:chrisc at catalyst.net.nz]
> *Sent:* Wednesday, 20 June 2018 10:12 AM
> *To:* koha-devel at lists.koha-community.org; David Cook 
> <dcook at prosentient.com.au>; 'Liz Rea' <liz at catalyst.net.nz>
> *Subject:* Re: [Koha-devel] Why we do not push the ACCTDETAILS email 
> via message queue?
>
> We could make a list of them. It could be the "libraries who don't 
> care about their users privacy" list.
>
> I'm only mostly joking
>
> Chris
>
> On June 20, 2018 12:06:52 PM GMT+12:00, David Cook 
> <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>> wrote:
>
>     I think that would probably be the best way of going about it, but
>     I?m sure there are a lot of libraries that wouldn?t be happy about
>     it.
>
>     David Cook
>
>     Systems Librarian
>
>     Prosentient Systems
>
>     72/330 Wattle St
>
>     Ultimo, NSW 2007
>
>     Australia
>
>     Office: 02 9212 0899
>
>     Direct: 02 8005 0595
>
>     *From:*koha-devel-bounces at lists.koha-community.org
>     <mailto:koha-devel-bounces at lists.koha-community.org>
>     [mailto:koha-devel-bounces at lists.koha-community.org] *On Behalf Of
>     *Liz Rea
>     *Sent:* Tuesday, 19 June 2018 12:26 PM
>     *To:* koha-devel at lists.koha-community.org
>     <mailto:koha-devel at lists.koha-community.org>
>     *Subject:* Re: [Koha-devel] Why we do not push the ACCTDETAILS
>     email via message queue?
>
>     I feel like instead of sending people a password, we should send
>     them to the "forgot password reset page" with a couple of slight
>     changes for new account holders, so they can set their own passwords.
>
>     Seems better than sending the password in the clear in an email.
>
>     Cheers,
>     Liz
>
>     On 19/06/18 12:21, David Cook wrote:
>
>         Cheers, Jonathan. I had totally forgotten about that. Yikes.
>
>           
>
>         Good call, Chris. While I think many mail servers these days use TLS to secure the email between the mail servers, an unscrupulous administrator could still certainly take advantage of people on either end. The best idea probably is to just not use AutoEmailOpacUser, as Jonathan seems to suggest.
>
>           
>
>         David Cook
>
>         Systems Librarian
>
>         Prosentient Systems
>
>         72/330 Wattle St
>
>         Ultimo, NSW 2007
>
>         Australia
>
>           
>
>         Office: 02 9212 0899
>
>         Direct: 02 8005 0595
>
>           
>
>         From: Jonathan Druart [mailto:jonathan.druart at bugs.koha-community.org]
>
>         Sent: Tuesday, 19 June 2018 12:07 AM
>
>         To: Christopher Nighswonger<chris.nighswonger at gmail.com> <mailto:chris.nighswonger at gmail.com>
>
>         Cc: David Cook<dcook at prosentient.com.au> <mailto:dcook at prosentient.com.au>; Koha Devel<koha-devel at lists.koha-community.org>
>         <mailto:koha-devel at lists.koha-community.org>
>
>         Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?
>
>           
>
>         It has been reported (by David) on our bug tracker already (20796, security area, which does no longer make sense at it is public now...)
>
>           
>
>         For information this notice contains the password in clear for... 10 years now (bug 2149) and the behavior is turned off by default (AutoEmailOpacUser).
>
>           
>
>           
>
>         On Mon, 18 Jun 2018 at 10:11 Christopher Nighswonger <chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com>  <mailto:chris.nighswonger at gmail.com>
>         <mailto:chris.nighswonger at gmail.com>  > wrote:
>
>         Considering that email is plaintext (AKA "postcard") mail, I'm surprised we would send a user's password in an email in any case.
>
>           
>
>           
>
>         On Mon, Jun 18, 2018 at 4:14 AM, David Cook <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>  <mailto:dcook at prosentient.com.au>
>         <mailto:dcook at prosentient.com.au>  > wrote:
>
>         Considering that the borrower?s password is typically in the ACCTDETAILS email, I think using the message_queue for ACCTDETAILS would be a bad idea and would probably violate the GDPR in Europe.
>
>           
>
>         Just imagine looking through your database and seeing all those plain text passwords, especially for people who re-use the same password for everything. I think it would be a security and privacy nightmare.
>
>           
>
>         David Cook
>
>         Systems Librarian
>
>         Prosentient Systems
>
>         72/330 Wattle St
>
>         Ultimo, NSW 2007
>
>         Australia
>
>           
>
>         Office: 02 9212 0899 <tel:02%2092%2012%2008%2099> 
>
>         Direct: 02 8005 0595 <tel:02%2080%2005%2005%2095> 
>
>           
>
>         From:koha-devel-bounces at lists.koha-community.org
>         <mailto:koha-devel-bounces at lists.koha-community.org>  <mailto:koha-devel-bounces at lists.koha-community.org>
>         <mailto:koha-devel-bounces at lists.koha-community.org> ? [mailto:koha-devel-bounces at lists.koha-community.org  <mailto:koha-devel-bounces at lists.koha-community.org>
>         <mailto:koha-devel-bounces at lists.koha-community.org>  ] On Behalf Of Sophie Meynieux
>
>         Sent: Friday, 15 June 2018 9:33 PM
>
>         To:koha-devel at lists.koha-community.org
>         <mailto:koha-devel at lists.koha-community.org>  <mailto:koha-devel at lists.koha-community.org>
>         <mailto:koha-devel at lists.koha-community.org>  
>
>         Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?
>
>           
>
>         Maybe because for this message you're expecting it is sent immediately while message_queue table could be processed more occasionally ?
>
>         Best regards
>
>         S. Meynieux
>
>
>
>         _______________________________________________
>
>         Koha-devel mailing list
>
>         Koha-devel at lists.koha-community.org
>         <mailto:Koha-devel at lists.koha-community.org>
>
>         http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>
>         website :http://www.koha-community.org/
>
>         git :http://git.koha-community.org/
>
>         bugs :http://bugs.koha-community.org/
>
>     -- 
>
>     --
>
>     Liz Rea
>
>     Catalyst.Net Limited
>
>     Level 6, Catalyst House,
>
>     150 Willis Street, Wellington.
>
>     P.O Box 11053, Manners Street,
>
>     Wellington 6142
>
>     04 803 2265
>
>     GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7
>
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>


From tomascohen at gmail.com  Wed Jun 20 03:01:36 2018
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Tue, 19 Jun 2018 22:01:36 -0300
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email via
	message queue?
In-Reply-To: <0c1dcf01-3448-db9c-2530-f97a85d66a9a@catalyst.net.nz>
References: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>
	<e4037673-769f-beac-478e-8721661a637c@biblibre.com>
	<040b01d406dc$701e1b20$505a5160$@prosentient.com.au>
	<CAA7=B8wB37-9NkgwzJ3XTCf3nxwNh4BFcZZpaJcWnkrwgy5Okg@mail.gmail.com>
	<CAJzKNY59WRhA56ySBb_v+8SCdPVgD2guGPzXM12EuMkQESbsUA@mail.gmail.com>
	<049f01d40763$6ce87f40$46b97dc0$@prosentient.com.au>
	<73dea149-f45c-2926-0f8d-5f8383d8ba30@catalyst.net.nz>
	<04ec01d4082a$97555e70$c6001b50$@prosentient.com.au>
	<CE015A21-1EA4-41BE-AFFA-778904BF14E6@catalyst.net.nz>
	<04fa01d4082c$67fd6530$37f82f90$@prosentient.com.au>
	<0c1dcf01-3448-db9c-2530-f97a85d66a9a@catalyst.net.nz>
Message-ID: <CABZfb=VAzpKy5=HbxA-WFTcn8oRa2PaKv6VMn3LOZkDsy-qFUA@mail.gmail.com>

The way we do this is having a syspref to choose between both ways, and a
big sign ok to of the release notes asking users to switch.

El mar., 19 de jun. de 2018 9:25 p. m., Liz Rea <liz at catalyst.net.nz>
escribi?:

> The easy answer is : leave it alone for existing installs, default it on
> for new ones.
>
>
>
> On 20/06/18 12:19, David Cook wrote:
> >
> > I think that?s not a bad way of looking at it. If people do complain,
> > we can say that the change away was because of a commitment to patron
> > security and privacy. I would hope that people would find that
> > difficult to argue against.
> >
> > If I recall correctly, I think DSpace does it this way. When you
> > create a new user, I think it sends an email containing a URL with a
> > token to the user, and then they set their own password from there. It
> > works pretty well. Surely we could say ?everybody else is doing it? as
> > well.
> >
> > But I know that there are a lot of libraries using this feature, and
> > it would be disruptive to their existing workflows for it to go away.
> > But? that?s also progress for you. So long as people have notice that
> > it?s going away before the upgrade, they?d have time to change their
> > workflows and adapt to a safer way of doing things?
> >
> > David Cook
> >
> > Systems Librarian
> >
> > Prosentient Systems
> >
> > 72/330 Wattle St
> >
> > Ultimo, NSW 2007
> >
> > Australia
> >
> > Office: 02 9212 0899
> >
> > Direct: 02 8005 0595
> >
> > *From:*Chris Cormack [mailto:chrisc at catalyst.net.nz]
> > *Sent:* Wednesday, 20 June 2018 10:12 AM
> > *To:* koha-devel at lists.koha-community.org; David Cook
> > <dcook at prosentient.com.au>; 'Liz Rea' <liz at catalyst.net.nz>
> > *Subject:* Re: [Koha-devel] Why we do not push the ACCTDETAILS email
> > via message queue?
> >
> > We could make a list of them. It could be the "libraries who don't
> > care about their users privacy" list.
> >
> > I'm only mostly joking
> >
> > Chris
> >
> > On June 20, 2018 12:06:52 PM GMT+12:00, David Cook
> > <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>> wrote:
> >
> >     I think that would probably be the best way of going about it, but
> >     I?m sure there are a lot of libraries that wouldn?t be happy about
> >     it.
> >
> >     David Cook
> >
> >     Systems Librarian
> >
> >     Prosentient Systems
> >
> >     72/330 Wattle St
> >
> >     Ultimo, NSW 2007
> >
> >     Australia
> >
> >     Office: 02 9212 0899
> >
> >     Direct: 02 8005 0595
> >
> >     *From:*koha-devel-bounces at lists.koha-community.org
> >     <mailto:koha-devel-bounces at lists.koha-community.org>
> >     [mailto:koha-devel-bounces at lists.koha-community.org] *On Behalf Of
> >     *Liz Rea
> >     *Sent:* Tuesday, 19 June 2018 12:26 PM
> >     *To:* koha-devel at lists.koha-community.org
> >     <mailto:koha-devel at lists.koha-community.org>
> >     *Subject:* Re: [Koha-devel] Why we do not push the ACCTDETAILS
> >     email via message queue?
> >
> >     I feel like instead of sending people a password, we should send
> >     them to the "forgot password reset page" with a couple of slight
> >     changes for new account holders, so they can set their own passwords.
> >
> >     Seems better than sending the password in the clear in an email.
> >
> >     Cheers,
> >     Liz
> >
> >     On 19/06/18 12:21, David Cook wrote:
> >
> >         Cheers, Jonathan. I had totally forgotten about that. Yikes.
> >
> >
> >
> >         Good call, Chris. While I think many mail servers these days use
> TLS to secure the email between the mail servers, an unscrupulous
> administrator could still certainly take advantage of people on either end.
> The best idea probably is to just not use AutoEmailOpacUser, as Jonathan
> seems to suggest.
> >
> >
> >
> >         David Cook
> >
> >         Systems Librarian
> >
> >         Prosentient Systems
> >
> >         72/330 Wattle St
> >
> >         Ultimo, NSW 2007
> >
> >         Australia
> >
> >
> >
> >         Office: 02 9212 0899
> >
> >         Direct: 02 8005 0595
> >
> >
> >
> >         From: Jonathan Druart [mailto:
> jonathan.druart at bugs.koha-community.org]
> >
> >         Sent: Tuesday, 19 June 2018 12:07 AM
> >
> >         To: Christopher Nighswonger<chris.nighswonger at gmail.com>
> <mailto:chris.nighswonger at gmail.com>
> >
> >         Cc: David Cook<dcook at prosentient.com.au> <mailto:
> dcook at prosentient.com.au>; Koha Devel<koha-devel at lists.koha-community.org>
> >         <mailto:koha-devel at lists.koha-community.org>
> >
> >         Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS
> email via message queue?
> >
> >
> >
> >         It has been reported (by David) on our bug tracker already
> (20796, security area, which does no longer make sense at it is public
> now...)
> >
> >
> >
> >         For information this notice contains the password in clear
> for... 10 years now (bug 2149) and the behavior is turned off by default
> (AutoEmailOpacUser).
> >
> >
> >
> >
> >
> >         On Mon, 18 Jun 2018 at 10:11 Christopher Nighswonger <
> chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com>  <mailto:
> chris.nighswonger at gmail.com>
> >         <mailto:chris.nighswonger at gmail.com>  > wrote:
> >
> >         Considering that email is plaintext (AKA "postcard") mail, I'm
> surprised we would send a user's password in an email in any case.
> >
> >
> >
> >
> >
> >         On Mon, Jun 18, 2018 at 4:14 AM, David Cook <
> dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>  <mailto:
> dcook at prosentient.com.au>
> >         <mailto:dcook at prosentient.com.au>  > wrote:
> >
> >         Considering that the borrower?s password is typically in the
> ACCTDETAILS email, I think using the message_queue for ACCTDETAILS would be
> a bad idea and would probably violate the GDPR in Europe.
> >
> >
> >
> >         Just imagine looking through your database and seeing all those
> plain text passwords, especially for people who re-use the same password
> for everything. I think it would be a security and privacy nightmare.
> >
> >
> >
> >         David Cook
> >
> >         Systems Librarian
> >
> >         Prosentient Systems
> >
> >         72/330 Wattle St
> >
> >         Ultimo, NSW 2007
> >
> >         Australia
> >
> >
> >
> >         Office: 02 9212 0899 <tel:02%2092%2012%2008%2099>
> >
> >         Direct: 02 8005 0595 <tel:02%2080%2005%2005%2095>
> >
> >
> >
> >         From:koha-devel-bounces at lists.koha-community.org
> >         <mailto:koha-devel-bounces at lists.koha-community.org>  <mailto:
> koha-devel-bounces at lists.koha-community.org>
> >         <mailto:koha-devel-bounces at lists.koha-community.org>   [mailto:
> koha-devel-bounces at lists.koha-community.org  <mailto:
> koha-devel-bounces at lists.koha-community.org>
> >         <mailto:koha-devel-bounces at lists.koha-community.org>  ] On
> Behalf Of Sophie Meynieux
> >
> >         Sent: Friday, 15 June 2018 9:33 PM
> >
> >         To:koha-devel at lists.koha-community.org
> >         <mailto:koha-devel at lists.koha-community.org>  <mailto:
> koha-devel at lists.koha-community.org>
> >         <mailto:koha-devel at lists.koha-community.org>
> >
> >         Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS
> email via message queue?
> >
> >
> >
> >         Maybe because for this message you're expecting it is sent
> immediately while message_queue table could be processed more occasionally ?
> >
> >         Best regards
> >
> >         S. Meynieux
> >
> >
> >
> >         _______________________________________________
> >
> >         Koha-devel mailing list
> >
> >         Koha-devel at lists.koha-community.org
> >         <mailto:Koha-devel at lists.koha-community.org>
> >
> >
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> >
> >         website :http://www.koha-community.org/
> >
> >         git :http://git.koha-community.org/
> >
> >         bugs :http://bugs.koha-community.org/
> >
> >     --
> >
> >     --
> >
> >     Liz Rea
> >
> >     Catalyst.Net Limited
> >
> >     Level 6, Catalyst House,
> >
> >     150 Willis Street, Wellington.
> >
> >     P.O Box 11053, Manners Street,
> >
> >     Wellington 6142
> >
> >     04 803 2265
> >
> >     GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7
> >
> >
> > --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-- 
Tom?s Cohen Arazi
Theke Solutions (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180619/a6f03f12/attachment-0001.html>

From dcook at prosentient.com.au  Wed Jun 20 03:53:01 2018
From: dcook at prosentient.com.au (David Cook)
Date: Wed, 20 Jun 2018 11:53:01 +1000
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email
	via	message queue?
In-Reply-To: <CABZfb=VAzpKy5=HbxA-WFTcn8oRa2PaKv6VMn3LOZkDsy-qFUA@mail.gmail.com>
References: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>	<e4037673-769f-beac-478e-8721661a637c@biblibre.com>	<040b01d406dc$701e1b20$505a5160$@prosentient.com.au>	<CAA7=B8wB37-9NkgwzJ3XTCf3nxwNh4BFcZZpaJcWnkrwgy5Okg@mail.gmail.com>	<CAJzKNY59WRhA56ySBb_v+8SCdPVgD2guGPzXM12EuMkQESbsUA@mail.gmail.com>	<049f01d40763$6ce87f40$46b97dc0$@prosentient.com.au>	<73dea149-f45c-2926-0f8d-5f8383d8ba30@catalyst.net.nz>	<04ec01d4082a$97555e70$c6001b50$@prosentient.com.au>	<CE015A21-1EA4-41BE-AFFA-778904BF14E6@catalyst.net.nz>	<04fa01d4082c$67fd6530$37f82f90$@prosentient.com.au>	<0c1dcf01-3448-db9c-2530-f97a85d66a9a@catalyst.net.nz>
	<CABZfb=VAzpKy5=HbxA-WFTcn8oRa2PaKv6VMn3LOZkDsy-qFUA@mail.gmail.com>
Message-ID: <050f01d40839$6bcfde10$436f9a30$@prosentient.com.au>

Yeah, I keep thinking that people won?t do something more secure if it?s less convenient for them. I suppose that?s their choice in the end though? and we can provide better options for those that do care more.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Tomas Cohen Arazi
Sent: Wednesday, 20 June 2018 11:02 AM
To: koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?

 

The way we do this is having a syspref to choose between both ways, and a big sign ok to of the release notes asking users to switch.

El mar., 19 de jun. de 2018 9:25 p. m., Liz Rea <liz at catalyst.net.nz <mailto:liz at catalyst.net.nz> > escribi?:

The easy answer is : leave it alone for existing installs, default it on 
for new ones.



On 20/06/18 12:19, David Cook wrote:
>
> I think that?s not a bad way of looking at it. If people do complain, 
> we can say that the change away was because of a commitment to patron 
> security and privacy. I would hope that people would find that 
> difficult to argue against.
>
> If I recall correctly, I think DSpace does it this way. When you 
> create a new user, I think it sends an email containing a URL with a 
> token to the user, and then they set their own password from there. It 
> works pretty well. Surely we could say ?everybody else is doing it? as 
> well.
>
> But I know that there are a lot of libraries using this feature, and 
> it would be disruptive to their existing workflows for it to go away. 
> But? that?s also progress for you. So long as people have notice that 
> it?s going away before the upgrade, they?d have time to change their 
> workflows and adapt to a safer way of doing things?
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
> Office: 02 9212 0899
>
> Direct: 02 8005 0595
>
> *From:*Chris Cormack [mailto:chrisc at catalyst.net.nz <mailto:chrisc at catalyst.net.nz> ]
> *Sent:* Wednesday, 20 June 2018 10:12 AM
> *To:* koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> ; David Cook 
> <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> >; 'Liz Rea' <liz at catalyst.net.nz <mailto:liz at catalyst.net.nz> >
> *Subject:* Re: [Koha-devel] Why we do not push the ACCTDETAILS email 
> via message queue?
>
> We could make a list of them. It could be the "libraries who don't 
> care about their users privacy" list.
>
> I'm only mostly joking
>
> Chris
>
> On June 20, 2018 12:06:52 PM GMT+12:00, David Cook 
> <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>  <mailto:dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> >> wrote:
>
>     I think that would probably be the best way of going about it, but
>     I?m sure there are a lot of libraries that wouldn?t be happy about
>     it.
>
>     David Cook
>
>     Systems Librarian
>
>     Prosentient Systems
>
>     72/330 Wattle St
>
>     Ultimo, NSW 2007
>
>     Australia
>
>     Office: 02 9212 0899
>
>     Direct: 02 8005 0595
>
>     *From:*koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> 
>     <mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> >
>     [mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> ] *On Behalf Of
>     *Liz Rea
>     *Sent:* Tuesday, 19 June 2018 12:26 PM
>     *To:* koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> 
>     <mailto:koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >
>     *Subject:* Re: [Koha-devel] Why we do not push the ACCTDETAILS
>     email via message queue?
>
>     I feel like instead of sending people a password, we should send
>     them to the "forgot password reset page" with a couple of slight
>     changes for new account holders, so they can set their own passwords.
>
>     Seems better than sending the password in the clear in an email.
>
>     Cheers,
>     Liz
>
>     On 19/06/18 12:21, David Cook wrote:
>
>         Cheers, Jonathan. I had totally forgotten about that. Yikes.
>
>           
>
>         Good call, Chris. While I think many mail servers these days use TLS to secure the email between the mail servers, an unscrupulous administrator could still certainly take advantage of people on either end. The best idea probably is to just not use AutoEmailOpacUser, as Jonathan seems to suggest.
>
>           
>
>         David Cook
>
>         Systems Librarian
>
>         Prosentient Systems
>
>         72/330 Wattle St
>
>         Ultimo, NSW 2007
>
>         Australia
>
>           
>
>         Office: 02 9212 0899
>
>         Direct: 02 8005 0595
>
>           
>
>         From: Jonathan Druart [mailto:jonathan.druart at bugs.koha-community.org <mailto:jonathan.druart at bugs.koha-community.org> ]
>
>         Sent: Tuesday, 19 June 2018 12:07 AM
>
>         To: Christopher Nighswonger<chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com> > <mailto:chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com> >
>
>         Cc: David Cook<dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > <mailto:dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> >; Koha Devel<koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >
>         <mailto:koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >
>
>         Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?
>
>           
>
>         It has been reported (by David) on our bug tracker already (20796, security area, which does no longer make sense at it is public now...)
>
>           
>
>         For information this notice contains the password in clear for... 10 years now (bug 2149) and the behavior is turned off by default (AutoEmailOpacUser).
>
>           
>
>           
>
>         On Mon, 18 Jun 2018 at 10:11 Christopher Nighswonger <chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com>  <mailto:chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com> >  <mailto:chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com> >
>         <mailto:chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com> >  > wrote:
>
>         Considering that email is plaintext (AKA "postcard") mail, I'm surprised we would send a user's password in an email in any case.
>
>           
>
>           
>
>         On Mon, Jun 18, 2018 at 4:14 AM, David Cook <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>  <mailto:dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> >  <mailto:dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> >
>         <mailto:dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> >  > wrote:
>
>         Considering that the borrower?s password is typically in the ACCTDETAILS email, I think using the message_queue for ACCTDETAILS would be a bad idea and would probably violate the GDPR in Europe.
>
>           
>
>         Just imagine looking through your database and seeing all those plain text passwords, especially for people who re-use the same password for everything. I think it would be a security and privacy nightmare.
>
>           
>
>         David Cook
>
>         Systems Librarian
>
>         Prosentient Systems
>
>         72/330 Wattle St
>
>         Ultimo, NSW 2007
>
>         Australia
>
>           
>
>         Office: 02 9212 0899 <tel:02%2092%2012%2008%2099> 
>
>         Direct: 02 8005 0595 <tel:02%2080%2005%2005%2095> 
>
>           
>
>         From:koha-devel-bounces at lists.koha-community.org <mailto:From%3Akoha-devel-bounces at lists.koha-community.org> 
>         <mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> >  <mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> >
>         <mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> >   [mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org>   <mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> >
>         <mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> >  ] On Behalf Of Sophie Meynieux
>
>         Sent: Friday, 15 June 2018 9:33 PM
>
>         To:koha-devel at lists.koha-community.org <mailto:To%3Akoha-devel at lists.koha-community.org> 
>         <mailto:koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >  <mailto:koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >
>         <mailto:koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >  
>
>         Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS email via message queue?
>
>           
>
>         Maybe because for this message you're expecting it is sent immediately while message_queue table could be processed more occasionally ?
>
>         Best regards
>
>         S. Meynieux
>
>
>
>         _______________________________________________
>
>         Koha-devel mailing list
>
>         Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
>         <mailto:Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> >
>
>         http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>
>         website :http://www.koha-community.org/
>
>         git :http://git.koha-community.org/
>
>         bugs :http://bugs.koha-community.org/
>
>     -- 
>
>     --
>
>     Liz Rea
>
>     Catalyst.Net Limited
>
>     Level 6, Catalyst House,
>
>     150 Willis Street, Wellington.
>
>     P.O Box 11053, Manners Street,
>
>     Wellington 6142
>
>     04 803 2265
>
>     GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7
>
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

-- 

Tom?s Cohen Arazi

Theke Solutions (https://theke.io <http://theke.io/> )
? +54 9351 3513384
GPG: B2F3C15F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180620/c811de82/attachment-0001.html>

From arouss1980 at gmail.com  Wed Jun 20 09:51:08 2018
From: arouss1980 at gmail.com (Andreas Roussos)
Date: Wed, 20 Jun 2018 10:51:08 +0300
Subject: [Koha-devel] Staff/OPAC ISBD views and subfield visibility
In-Reply-To: <30185c75-94e7-2707-cc35-b8f6ef205888@web.de>
References: <CAK0RUrtUaS4hMCHHa1Jm7ZztnHUAMAv+Kg__Vd7sG6WoiuGPvw@mail.gmail.com>
	<30185c75-94e7-2707-cc35-b8f6ef205888@web.de>
Message-ID: <CAK0RUrtp6SYswHZG38X5PvGgHst91JqedpthjJcXX_46_oDOSg@mail.gmail.com>

Hi Katrin,

Thank you for your reply.

The issue we are facing is this: unless a subfield (e.g. UNIMARC 453$0,
Bibliographic Record Identifier) is marked as visible in the OPAC, the
links (URLs) using that subfield will be broken in the ISBD view.
And this happens (according to the code snippets in my original message)
only when GetISBDView is called with 'template' = 'opac', not 'intranet'
(i.e. only in OPAC ISBD view, not in Staff ISBD view).

I hope this makes more sense.

Regards,
Andreas

On 18 June 2018 at 23:22, Katrin Fischer <katrin.fischer.83 at web.de> wrote:

> Hi Andreas,
>
> I might be misunderstanding your question, but the OPAC visibility setting
> should take effect on all pages and views in the OPAC now. It didn't use
> to, which was considered a long standing bug and finally fixed. Now it's
> possible to hide fields from OPAC that can still appear in staff in a
> reliable way. The preconfigured visibility settings in the frameworks might
> not always be ideal - if that's what you mean, we could work on improving
> them.
>
> Hope that helps,
>
> Katrin
>
>
> On 07.06.2018 09:21, Andreas Roussos wrote:
>
> Dear Developers,
>
> If you:
>
> 1) edit the ISBD and OPACISBD system preferences so that they contain the
> following code:
>
> #453| - translated as: |<a href="/cgi-bin/koha/catalogue/
> detail.pl?biblionumber={4530} <http://detail.pl?biblionumber=%7B4530%7D>">{453t}</a>
> {(453d)}|
> #454| - translation of: |<a href="/cgi-bin/koha/catalogue/
> detail.pl?biblionumber={4540} <http://detail.pl?biblionumber=%7B4540%7D>">{454t}</a>
> {(454d)}|
>
> 2) set the visibility of (UNIMARC) fields 453$0 and 454$0 to 'hidden' in
> the OPAC
>
> ...then the generated links will work fine in the Staff client but will be
> broken in the OPAC (i.e. the URL will not include the biblionumber
> contained in subfield 0 of fields 453/454).
>
> I've tracked this down to ISBDdetail.pl and opac-ISBDdetail.pl calling the
> GetISBDView subroutine, which (for some reason) excludes subfields that are
> hidden in the OPAC:
>
> https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L773-L776
> https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L812-L815
>
> What is the reasoning behind this?
> In other words, why is _OPAC_ subfield visibility taken into account when
> displaying the OPAC ISBD view (whereas visibility in Staff is not
> considered)?
>
> If anything, it is more likely to have subfield 0 hidden in OPAC, while
> visible in Staff, so one would expect the opposite logic.
>
> Thanks in advance for your time.
>
> Kind regards,
> Andreas Roussos
>
>
> _______________________________________________
> Koha-devel mailing listKoha-devel at lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180620/1a611b1c/attachment.html>

From martin.renvoize at ptfs-europe.com  Wed Jun 20 11:39:26 2018
From: martin.renvoize at ptfs-europe.com (Renvoize, Martin)
Date: Wed, 20 Jun 2018 10:39:26 +0100
Subject: [Koha-devel] Why we do not push the ACCTDETAILS email via
	message queue?
In-Reply-To: <050f01d40839$6bcfde10$436f9a30$@prosentient.com.au>
References: <CAJ0y-DfBdvYtt-H-1Eu+kXeUZhzbcY83=ZshjS=uTZBtb37R0Q@mail.gmail.com>
	<e4037673-769f-beac-478e-8721661a637c@biblibre.com>
	<040b01d406dc$701e1b20$505a5160$@prosentient.com.au>
	<CAA7=B8wB37-9NkgwzJ3XTCf3nxwNh4BFcZZpaJcWnkrwgy5Okg@mail.gmail.com>
	<CAJzKNY59WRhA56ySBb_v+8SCdPVgD2guGPzXM12EuMkQESbsUA@mail.gmail.com>
	<049f01d40763$6ce87f40$46b97dc0$@prosentient.com.au>
	<73dea149-f45c-2926-0f8d-5f8383d8ba30@catalyst.net.nz>
	<04ec01d4082a$97555e70$c6001b50$@prosentient.com.au>
	<CE015A21-1EA4-41BE-AFFA-778904BF14E6@catalyst.net.nz>
	<04fa01d4082c$67fd6530$37f82f90$@prosentient.com.au>
	<0c1dcf01-3448-db9c-2530-f97a85d66a9a@catalyst.net.nz>
	<CABZfb=VAzpKy5=HbxA-WFTcn8oRa2PaKv6VMn3LOZkDsy-qFUA@mail.gmail.com>
	<050f01d40839$6bcfde10$436f9a30$@prosentient.com.au>
Message-ID: <CAB7SL8DO=hEQttkykHMEdb9ezTNFMwAq1PSBSGemTO9=4bDQ_A@mail.gmail.com>

Is it really any less convenient to click a link and fill in your own
password vs getting a random password in your mail and having to manually
navigate to the site and login if you want to change it?

Devils advocate, I personally think this is a case where we can justifiably
break the old functionality as there is a clear and near seamless
alternative that doesn't result in any real lose and only leads to a more
secure and privacy-conscious system.

Martin

*Martin Renvoize*

Development Manager




*T:* +44 (0) 1483 378728

*F:* +44 (0) 800 756 6384

*E:* martin.renvoize at ptfs-europe.com

www.ptfs-europe.com



<https://www.ptfs-europe.com>



Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at info at ptfs-europe.com


On 20 June 2018 at 02:53, David Cook <dcook at prosentient.com.au> wrote:

> Yeah, I keep thinking that people won?t do something more secure if it?s
> less convenient for them. I suppose that?s their choice in the end though?
> and we can provide better options for those that do care more.
>
>
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
>
>
> Office: 02 9212 0899
>
> Direct: 02 8005 0595
>
>
>
> *From:* koha-devel-bounces at lists.koha-community.org [mailto:
> koha-devel-bounces at lists.koha-community.org] *On Behalf Of *Tomas Cohen
> Arazi
> *Sent:* Wednesday, 20 June 2018 11:02 AM
> *To:* koha-devel <koha-devel at lists.koha-community.org>
>
> *Subject:* Re: [Koha-devel] Why we do not push the ACCTDETAILS email via
> message queue?
>
>
>
> The way we do this is having a syspref to choose between both ways, and a
> big sign ok to of the release notes asking users to switch.
>
> El mar., 19 de jun. de 2018 9:25 p. m., Liz Rea <liz at catalyst.net.nz>
> escribi?:
>
> The easy answer is : leave it alone for existing installs, default it on
> for new ones.
>
>
>
> On 20/06/18 12:19, David Cook wrote:
> >
> > I think that?s not a bad way of looking at it. If people do complain,
> > we can say that the change away was because of a commitment to patron
> > security and privacy. I would hope that people would find that
> > difficult to argue against.
> >
> > If I recall correctly, I think DSpace does it this way. When you
> > create a new user, I think it sends an email containing a URL with a
> > token to the user, and then they set their own password from there. It
> > works pretty well. Surely we could say ?everybody else is doing it? as
> > well.
> >
> > But I know that there are a lot of libraries using this feature, and
> > it would be disruptive to their existing workflows for it to go away.
> > But? that?s also progress for you. So long as people have notice that
> > it?s going away before the upgrade, they?d have time to change their
> > workflows and adapt to a safer way of doing things?
> >
> > David Cook
> >
> > Systems Librarian
> >
> > Prosentient Systems
> >
> > 72/330 Wattle St
> >
> > Ultimo, NSW 2007
> >
> > Australia
> >
> > Office: 02 9212 0899
> >
> > Direct: 02 8005 0595
> >
> > *From:*Chris Cormack [mailto:chrisc at catalyst.net.nz]
> > *Sent:* Wednesday, 20 June 2018 10:12 AM
> > *To:* koha-devel at lists.koha-community.org; David Cook
> > <dcook at prosentient.com.au>; 'Liz Rea' <liz at catalyst.net.nz>
> > *Subject:* Re: [Koha-devel] Why we do not push the ACCTDETAILS email
> > via message queue?
> >
> > We could make a list of them. It could be the "libraries who don't
> > care about their users privacy" list.
> >
> > I'm only mostly joking
> >
> > Chris
> >
> > On June 20, 2018 12:06:52 PM GMT+12:00, David Cook
> > <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>> wrote:
> >
> >     I think that would probably be the best way of going about it, but
> >     I?m sure there are a lot of libraries that wouldn?t be happy about
> >     it.
> >
> >     David Cook
> >
> >     Systems Librarian
> >
> >     Prosentient Systems
> >
> >     72/330 Wattle St
> >
> >     Ultimo, NSW 2007
> >
> >     Australia
> >
> >     Office: 02 9212 0899
> >
> >     Direct: 02 8005 0595
> >
> >     *From:*koha-devel-bounces at lists.koha-community.org
> >     <mailto:koha-devel-bounces at lists.koha-community.org>
> >     [mailto:koha-devel-bounces at lists.koha-community.org] *On Behalf Of
> >     *Liz Rea
> >     *Sent:* Tuesday, 19 June 2018 12:26 PM
> >     *To:* koha-devel at lists.koha-community.org
> >     <mailto:koha-devel at lists.koha-community.org>
> >     *Subject:* Re: [Koha-devel] Why we do not push the ACCTDETAILS
> >     email via message queue?
> >
> >     I feel like instead of sending people a password, we should send
> >     them to the "forgot password reset page" with a couple of slight
> >     changes for new account holders, so they can set their own passwords.
> >
> >     Seems better than sending the password in the clear in an email.
> >
> >     Cheers,
> >     Liz
> >
> >     On 19/06/18 12:21, David Cook wrote:
> >
> >         Cheers, Jonathan. I had totally forgotten about that. Yikes.
> >
> >
> >
> >         Good call, Chris. While I think many mail servers these days use
> TLS to secure the email between the mail servers, an unscrupulous
> administrator could still certainly take advantage of people on either end.
> The best idea probably is to just not use AutoEmailOpacUser, as Jonathan
> seems to suggest.
> >
> >
> >
> >         David Cook
> >
> >         Systems Librarian
> >
> >         Prosentient Systems
> >
> >         72/330 Wattle St
> >
> >         Ultimo, NSW 2007
> >
> >         Australia
> >
> >
> >
> >         Office: 02 9212 0899
> >
> >         Direct: 02 8005 0595
> >
> >
> >
> >         From: Jonathan Druart [mailto:jonathan.druart at bugs.
> koha-community.org]
> >
> >         Sent: Tuesday, 19 June 2018 12:07 AM
> >
> >         To: Christopher Nighswonger<chris.nighswonger at gmail.com>
> <mailto:chris.nighswonger at gmail.com>
> >
> >         Cc: David Cook<dcook at prosentient.com.au> <mailto:
> dcook at prosentient.com.au>; Koha Devel<koha-devel at lists.koha-community.org>
> >         <mailto:koha-devel at lists.koha-community.org>
> >
> >         Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS
> email via message queue?
> >
> >
> >
> >         It has been reported (by David) on our bug tracker already
> (20796, security area, which does no longer make sense at it is public
> now...)
> >
> >
> >
> >         For information this notice contains the password in clear
> for... 10 years now (bug 2149) and the behavior is turned off by default
> (AutoEmailOpacUser).
> >
> >
> >
> >
> >
> >         On Mon, 18 Jun 2018 at 10:11 Christopher Nighswonger <
> chris.nighswonger at gmail.com <mailto:chris.nighswonger at gmail.com>  <mailto:
> chris.nighswonger at gmail.com>
> >         <mailto:chris.nighswonger at gmail.com>  > wrote:
> >
> >         Considering that email is plaintext (AKA "postcard") mail, I'm
> surprised we would send a user's password in an email in any case.
> >
> >
> >
> >
> >
> >         On Mon, Jun 18, 2018 at 4:14 AM, David Cook <
> dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>  <mailto:
> dcook at prosentient.com.au>
> >         <mailto:dcook at prosentient.com.au>  > wrote:
> >
> >         Considering that the borrower?s password is typically in the
> ACCTDETAILS email, I think using the message_queue for ACCTDETAILS would be
> a bad idea and would probably violate the GDPR in Europe.
> >
> >
> >
> >         Just imagine looking through your database and seeing all those
> plain text passwords, especially for people who re-use the same password
> for everything. I think it would be a security and privacy nightmare.
> >
> >
> >
> >         David Cook
> >
> >         Systems Librarian
> >
> >         Prosentient Systems
> >
> >         72/330 Wattle St
> >
> >         Ultimo, NSW 2007
> >
> >         Australia
> >
> >
> >
> >         Office: 02 9212 0899 <tel:02%2092%2012%2008%2099
> <02%2092%2012%2008%2099>>
> >
> >         Direct: 02 8005 0595 <tel:02%2080%2005%2005%2095
> <02%2080%2005%2005%2095>>
> >
> >
> >
> >         From:koha-devel-bounces at lists.koha-community.org
> >         <mailto:koha-devel-bounces at lists.koha-community.org>  <mailto:
> koha-devel-bounces at lists.koha-community.org>
> >         <mailto:koha-devel-bounces at lists.koha-community.org>   [mailto:
> koha-devel-bounces at lists.koha-community.org  <mailto:koha-devel-bounces@
> lists.koha-community.org>
> >         <mailto:koha-devel-bounces at lists.koha-community.org>  ] On
> Behalf Of Sophie Meynieux
> >
> >         Sent: Friday, 15 June 2018 9:33 PM
> >
> >         To:koha-devel at lists.koha-community.org
> >         <mailto:koha-devel at lists.koha-community.org>  <mailto:
> koha-devel at lists.koha-community.org>
> >         <mailto:koha-devel at lists.koha-community.org>
> >
> >         Subject: Re: [Koha-devel] Why we do not push the ACCTDETAILS
> email via message queue?
> >
> >
> >
> >         Maybe because for this message you're expecting it is sent
> immediately while message_queue table could be processed more occasionally ?
> >
> >         Best regards
> >
> >         S. Meynieux
> >
> >
> >
> >         _______________________________________________
> >
> >         Koha-devel mailing list
> >
> >         Koha-devel at lists.koha-community.org
> >         <mailto:Koha-devel at lists.koha-community.org>
> >
> >         http://lists.koha-community.org/cgi-bin/mailman/listinfo/
> koha-devel
> >
> >         website :http://www.koha-community.org/
> >
> >         git :http://git.koha-community.org/
> >
> >         bugs :http://bugs.koha-community.org/
> >
> >     --
> >
> >     --
> >
> >     Liz Rea
> >
> >     Catalyst.Net Limited
> >
> >     Level 6, Catalyst House,
> >
> >     150 Willis Street, Wellington.
> >
> >     P.O Box 11053, Manners Street,
> >
> >     Wellington 6142
> >
> >     04 803 2265
> >
> >     GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7
> >
> >
> > --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
> --
>
> Tom?s Cohen Arazi
>
> Theke Solutions (https://theke.io <http://theke.io/>)
> ? +54 9351 3513384
> GPG: B2F3C15F
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180620/f474e518/attachment-0001.html>

From katrin.fischer.83 at web.de  Thu Jun 21 08:11:36 2018
From: katrin.fischer.83 at web.de (Katrin Fischer)
Date: Thu, 21 Jun 2018 08:11:36 +0200
Subject: [Koha-devel] Staff/OPAC ISBD views and subfield visibility
In-Reply-To: <CAK0RUrtp6SYswHZG38X5PvGgHst91JqedpthjJcXX_46_oDOSg@mail.gmail.com>
References: <CAK0RUrtUaS4hMCHHa1Jm7ZztnHUAMAv+Kg__Vd7sG6WoiuGPvw@mail.gmail.com>
	<30185c75-94e7-2707-cc35-b8f6ef205888@web.de>
	<CAK0RUrtp6SYswHZG38X5PvGgHst91JqedpthjJcXX_46_oDOSg@mail.gmail.com>
Message-ID: <57e33989-85c0-e2f4-405d-79708503f2c6@web.de>

Hi Andreas,

makes sense for me. Why not mark them as visible in the OPAC?

Katrin


On 20.06.2018 09:51, Andreas Roussos wrote:
> Hi Katrin,
>
> Thank you for your reply.
>
> The issue we are facing is this: unless a subfield (e.g. UNIMARC 
> 453$0, Bibliographic Record Identifier) is marked as visible in the 
> OPAC, the links (URLs) using that subfield will be broken in the ISBD 
> view.
> And this happens (according to the code snippets in my original 
> message) only when GetISBDView is called with 'template' = 'opac', not 
> 'intranet' (i.e. only in OPAC ISBD view, not in Staff ISBD view).
>
> I hope this makes more sense.
>
> Regards,
> Andreas
>
> On 18 June 2018 at 23:22, Katrin Fischer <katrin.fischer.83 at web.de 
> <mailto:katrin.fischer.83 at web.de>> wrote:
>
>     Hi Andreas,
>
>     I might be misunderstanding your question, but the OPAC visibility
>     setting should take effect on all pages and views in the OPAC now.
>     It didn't use to, which was considered a long standing bug and
>     finally fixed. Now it's possible to hide fields from OPAC that can
>     still appear in staff in a reliable way. The preconfigured
>     visibility settings in the frameworks might not always be ideal -
>     if that's what you mean, we could work on improving them.
>
>     Hope that helps,
>
>     Katrin
>
>
>     On 07.06.2018 09:21, Andreas Roussos wrote:
>>     Dear Developers,
>>
>>     If you:
>>
>>     1) edit the ISBD and OPACISBD system preferences so that they
>>     contain the following code:
>>
>>     #453| - translated as: |<a
>>     href="/cgi-bin/koha/catalogue/detail.pl?biblionumber={4530}
>>     <http://detail.pl?biblionumber=%7B4530%7D>">{453t}</a> {(453d)}|
>>     #454| - translation of: |<a
>>     href="/cgi-bin/koha/catalogue/detail.pl?biblionumber={4540}
>>     <http://detail.pl?biblionumber=%7B4540%7D>">{454t}</a> {(454d)}|
>>
>>     2) set the visibility of (UNIMARC) fields 453$0 and 454$0 to
>>     'hidden' in the OPAC
>>
>>     ...then the generated links will work fine in the Staff client
>>     but will be broken in the OPAC (i.e. the URL will not include the
>>     biblionumber contained in subfield 0 of fields 453/454).
>>
>>     I've tracked this down to ISBDdetail.pl and opac-ISBDdetail.pl
>>     calling the GetISBDView subroutine, which (for some reason)
>>     excludes subfields that are hidden in the OPAC:
>>
>>     https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L773-L776
>>     <https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L773-L776>
>>     https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L812-L815
>>     <https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L812-L815>
>>
>>     What is the reasoning behind this?
>>     In other words, why is _OPAC_ subfield visibility taken into
>>     account when displaying the OPAC ISBD view (whereas visibility in
>>     Staff is not considered)?
>>
>>     If anything, it is more likely to have subfield 0 hidden in OPAC,
>>     while visible in Staff, so one would expect the opposite logic.
>>
>>     Thanks in advance for your time.
>>
>>     Kind regards,
>>     Andreas Roussos
>>
>>
>>     _______________________________________________
>>     Koha-devel mailing list
>>     Koha-devel at lists.koha-community.org
>>     <mailto:Koha-devel at lists.koha-community.org>
>>     http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>     <http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel>
>>     website :http://www.koha-community.org/
>>     git :http://git.koha-community.org/
>>     bugs :http://bugs.koha-community.org/ <http://bugs.koha-community.org/>
>
>
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at lists.koha-community.org>
>     http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>     <http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel>
>     website : http://www.koha-community.org/
>     git : http://git.koha-community.org/
>     bugs : http://bugs.koha-community.org/
>     <http://bugs.koha-community.org/>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180621/22c05aef/attachment.html>

From bargioni at pusc.it  Fri Jun 22 11:18:54 2018
From: bargioni at pusc.it (Stefano Bargioni)
Date: Fri, 22 Jun 2018 11:18:54 +0200
Subject: [Koha-devel] Preserve white spaces of Control Fields
Message-ID: <5A179E3C-79B8-49DC-B1CA-6B6719647E0A@pusc.it>

Hi, 
I added a new entry in the jQuery Library:
<https://wiki.koha-community.org/wiki/JQuery_Library#Preserve_white_spaces_of_Control_Fields>

The purpose is to simplify the analysis of control fields 00x, especially 000, 006, 007, 008.
They are shown preserving white spaces, each char in a box, and its position is shown on mouse hover.
You can test it opening a bib or auth record in MARC view, and pasting the code in the browser console.
Any comment is appreciated.
Stefano

From jonathan.druart at bugs.koha-community.org  Fri Jun 22 14:35:01 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Fri, 22 Jun 2018 09:35:01 -0300
Subject: [Koha-devel] Centralize and move to gitlab
In-Reply-To: <CAJzKNY7dt3s0ibfU9WggD99HAVgjGqpn-Jk7WLJLK1W=JT0ESQ@mail.gmail.com>
References: <CAJzKNY7dt3s0ibfU9WggD99HAVgjGqpn-Jk7WLJLK1W=JT0ESQ@mail.gmail.com>
Message-ID: <CAJzKNY4WPng1wru9wumjXALf_Rw8_9rQ559j40_FNT=BJiqQqg@mail.gmail.com>

A quick update to let you know that we have:
- kohadevbox
- koha-testing-docker
- koha-release-notes
- release-tools
- koha-dashboard
- koha-manual (was kohadocs)
now moved to gitlab/koha-community

https://gitlab.com/koha-community
If you have the necessary permissions on former locations it may be great
to mirror these new ones.
Or, mark them as "obsolete", for instance on
https://gitlab.com/koha-community-devs-users/kohadocs/ I have blanked the
README with a "This repository is obsolete" notice. Also the project as
been marked as "archived" (gitlab feature IIRC)

On Tue, 23 Jan 2018 at 16:46 Jonathan Druart <
jonathan.druart at bugs.koha-community.org> wrote:

> Hi devs,
>
> (Spoiler: I am not talking about a move from bugzilla to gitlab for the
> Koha git repo)
>
> Just a quick comment: gitlab has the ability to move projects with all the
> issues.
>
> From the export page of a project, they say:
> """
> The following items will be exported:
> Project and wiki repositories
> Project uploads
> Project configuration including web hooks and services
> Issues with comments, merge requests with diffs and comments, labels,
> milestones, snippets, and other project entities
> """
>
> So that will be easy to move (already discussed with Chris, will do in May)
> * koha-community-devs-users/kohadocs to koha-community/kohadocs
> * https://gitlab.com/koha-dashboard/koha-dashboard to
> koha-community/koha-dashboard
>
> And the ones from github too:
> * joubu/koha-misc4dev to koha-community/koha-misc4dev
> * Koha-Community/qa-test-tools to koha-community/qa-test-tools
>
> Then, maybe:
> koha-testing-docker
> koha-release-notes
> kohadevbox
> koha-howto
>
> The idea is to centralize our things in one place, ease the PRs and the
> ability to clone/fork keeping the visibility on what is the reference
> (account 'koha-community'). I would also like to generate a CI
> configuration for some of them.
> CI file for Koha: https://tree.taiga.io/project/joubu-koha-rm-1711/us/146
> (I am going to submit that on bugzilla soon)
> CI file for the manual:
> https://gitlab.com/koha-community-devs-users/kohadocs/blob/master/.gitlab-ci.yml
>
> Any pros/cons?
>
> Cheers,
> Jonathan
>
> (No troll please)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180622/1d90d40c/attachment.html>

From kyle.m.hall at gmail.com  Fri Jun 22 20:02:12 2018
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Fri, 22 Jun 2018 14:02:12 -0400
Subject: [Koha-devel] Centralize and move to gitlab
In-Reply-To: <a229f8ca-1750-f2eb-fb52-66ed47def716@web.de>
References: <CAJzKNY7dt3s0ibfU9WggD99HAVgjGqpn-Jk7WLJLK1W=JT0ESQ@mail.gmail.com>
	<a229f8ca-1750-f2eb-fb52-66ed47def716@web.de>
Message-ID: <CACpVHfwub=LzvubJFakyH0x--M3R+pVZ5=i+vj27E7V4wA5bDw@mail.gmail.com>

+1

Help me make Great Strides towards a cure for Cystic Fibrosis
<http://fightcf.cff.org/goto/kylehall>
<https://mail.google.com/>
---
http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )

On Sun, Jan 28, 2018 at 6:31 AM, Katrin Fischer <katrin.fischer.83 at web.de>
wrote:

> +1
>
> On 23.01.2018 20:46, Jonathan Druart wrote:
>
> Hi devs,
>
> (Spoiler: I am not talking about a move from bugzilla to gitlab for the
> Koha git repo)
>
> Just a quick comment: gitlab has the ability to move projects with all the
> issues.
>
> From the export page of a project, they say:
> """
> The following items will be exported:
> Project and wiki repositories
> Project uploads
> Project configuration including web hooks and services
> Issues with comments, merge requests with diffs and comments, labels,
> milestones, snippets, and other project entities
> """
>
> So that will be easy to move (already discussed with Chris, will do in May)
> * koha-community-devs-users/kohadocs to koha-community/kohadocs
> * https://gitlab.com/koha-dashboard/koha-dashboard to
> koha-community/koha-dashboard
>
> And the ones from github too:
> * joubu/koha-misc4dev to koha-community/koha-misc4dev
> * Koha-Community/qa-test-tools to koha-community/qa-test-tools
>
> Then, maybe:
> koha-testing-docker
> koha-release-notes
> kohadevbox
> koha-howto
>
> The idea is to centralize our things in one place, ease the PRs and the
> ability to clone/fork keeping the visibility on what is the reference
> (account 'koha-community'). I would also like to generate a CI
> configuration for some of them.
> CI file for Koha: https://tree.taiga.io/project/joubu-koha-rm-1711/us/146
> (I am going to submit that on bugzilla soon)
> CI file for the manual: https://gitlab.com/koha-
> community-devs-users/kohadocs/blob/master/.gitlab-ci.yml
>
> Any pros/cons?
>
> Cheers,
> Jonathan
>
> (No troll please)
>
>
> _______________________________________________
> Koha-devel mailing listKoha-devel at lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180622/ff3c7c6b/attachment.html>

From tomascohen at gmail.com  Fri Jun 22 20:03:50 2018
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 22 Jun 2018 15:03:50 -0300
Subject: [Koha-devel] Centralize and move to gitlab
In-Reply-To: <CACpVHfwub=LzvubJFakyH0x--M3R+pVZ5=i+vj27E7V4wA5bDw@mail.gmail.com>
References: <CAJzKNY7dt3s0ibfU9WggD99HAVgjGqpn-Jk7WLJLK1W=JT0ESQ@mail.gmail.com>
	<a229f8ca-1750-f2eb-fb52-66ed47def716@web.de>
	<CACpVHfwub=LzvubJFakyH0x--M3R+pVZ5=i+vj27E7V4wA5bDw@mail.gmail.com>
Message-ID: <CABZfb=XcuQsJhXDmPykjU0NwT1kL6KHW+_Z8J6v-Yc9fhttPBQ@mail.gmail.com>

KohaDevBox has been marked as obsolete as you suggested!


El vie., 22 jun. 2018 a las 15:02, Kyle Hall (<kyle.m.hall at gmail.com>)
escribi?:

> +1
>
> Help me make Great Strides towards a cure for Cystic Fibrosis
> <http://fightcf.cff.org/goto/kylehall>
> <https://mail.google.com/>
> ---
> http://www.kylehall.info
> ByWater Solutions ( http://bywatersolutions.com )
> Meadville Public Library ( http://www.meadvillelibrary.org )
> Crawford County Federated Library System ( http://www.ccfls.org )
>
> On Sun, Jan 28, 2018 at 6:31 AM, Katrin Fischer <katrin.fischer.83 at web.de>
> wrote:
>
>> +1
>>
>> On 23.01.2018 20:46, Jonathan Druart wrote:
>>
>> Hi devs,
>>
>> (Spoiler: I am not talking about a move from bugzilla to gitlab for the
>> Koha git repo)
>>
>> Just a quick comment: gitlab has the ability to move projects with all
>> the issues.
>>
>> From the export page of a project, they say:
>> """
>> The following items will be exported:
>> Project and wiki repositories
>> Project uploads
>> Project configuration including web hooks and services
>> Issues with comments, merge requests with diffs and comments, labels,
>> milestones, snippets, and other project entities
>> """
>>
>> So that will be easy to move (already discussed with Chris, will do in
>> May)
>> * koha-community-devs-users/kohadocs to koha-community/kohadocs
>> * https://gitlab.com/koha-dashboard/koha-dashboard to
>> koha-community/koha-dashboard
>>
>> And the ones from github too:
>> * joubu/koha-misc4dev to koha-community/koha-misc4dev
>> * Koha-Community/qa-test-tools to koha-community/qa-test-tools
>>
>> Then, maybe:
>> koha-testing-docker
>> koha-release-notes
>> kohadevbox
>> koha-howto
>>
>> The idea is to centralize our things in one place, ease the PRs and the
>> ability to clone/fork keeping the visibility on what is the reference
>> (account 'koha-community'). I would also like to generate a CI
>> configuration for some of them.
>> CI file for Koha: https://tree.taiga.io/project/joubu-koha-rm-1711/us/146
>> (I am going to submit that on bugzilla soon)
>> CI file for the manual:
>> https://gitlab.com/koha-community-devs-users/kohadocs/blob/master/.gitlab-ci.yml
>>
>> Any pros/cons?
>>
>> Cheers,
>> Jonathan
>>
>> (No troll please)
>>
>>
>> _______________________________________________
>> Koha-devel mailing listKoha-devel at lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-- 
Tom?s Cohen Arazi
Theke Solutions (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180622/75a56c97/attachment-0001.html>

From barton at bywatersolutions.com  Fri Jun 22 22:52:11 2018
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Fri, 22 Jun 2018 16:52:11 -0400
Subject: [Koha-devel] Suggestion: create a deprecated() function in Koha.
Message-ID: <CAMSJbVt0g1oaSKnY4B8Pz63qFsJqD6Ay1ZhEYGJZtBpE65WG+w@mail.gmail.com>

It would be useful for Koha to have a 'Deprecated' function, which would
send a warning about the caller() function and the version of Koha where
the function will be deprecated, and what it will be replaced by... so
let's say that C4::Adequate::DoEET() is being replaced by
Koha::Awesome->sauce(). in Koha 18.11.

In versions of koha prior to 18.11, we add a call to

deprecated( "18.11", "Koha::Awesome->sauce()");

at the beginning of C4::Adequate::DoEET().

Then, when C4::Adequate::DoEET() is called, this would generate the
following message in the logs:

"C4::Adequate::DoEET is deprecated and will be removed in Koha 18.11. It
will be replaced by Koha::Awesome->sauce()."

This would allow plugin authors to know that they will need to patch their
plugins before they break on upgrade.

This is a bare-bones implementation of deprecated():

sub deprecated {
    my ( $version, $replacement ) = @_;
    my (
        $package, $filename, $line, $subroutine, $hasargs,
        $wantarray, $evaltext, $is_require, $hints, $bitmask, $hinthash
    ) = caller(1);
    warn(
        "${subroutine} is deprecated and will be removed"
         . " in Koha version $version."
         . defined( $replacement )
            ? " It will be replaced by ${replacement}."
            : ""
    );
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180622/cf5ca81a/attachment.html>

From mtompset at hotmail.com  Sat Jun 23 04:17:40 2018
From: mtompset at hotmail.com (Mark Tompsett)
Date: Sat, 23 Jun 2018 02:17:40 +0000
Subject: [Koha-devel] Centralize and move to gitlab
In-Reply-To: <CABZfb=XcuQsJhXDmPykjU0NwT1kL6KHW+_Z8J6v-Yc9fhttPBQ@mail.gmail.com>
References: <CAJzKNY7dt3s0ibfU9WggD99HAVgjGqpn-Jk7WLJLK1W=JT0ESQ@mail.gmail.com><a229f8ca-1750-f2eb-fb52-66ed47def716@web.de><CACpVHfwub=LzvubJFakyH0x--M3R+pVZ5=i+vj27E7V4wA5bDw@mail.gmail.com>
	<CABZfb=XcuQsJhXDmPykjU0NwT1kL6KHW+_Z8J6v-Yc9fhttPBQ@mail.gmail.com>
Message-ID: <CY1PR1101MB1148A6BDE77A56B3817433BBC6740@CY1PR1101MB1148.namprd11.prod.outlook.com>

Greetings,

Will gitify and git-bz be moved as well? Kohadevbox is still using the github of those.

GPML,
Mark Tompsett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180623/aba4d497/attachment.html>

From dcook at prosentient.com.au  Mon Jun 25 04:14:56 2018
From: dcook at prosentient.com.au (David Cook)
Date: Mon, 25 Jun 2018 12:14:56 +1000
Subject: [Koha-devel] Add "cc" and "bcc" fields to message_queue
Message-ID: <078a01d40c2a$4fea6c70$efbf4550$@prosentient.com.au>

Hi all,

 

What do people think about adding "cc" and "bcc" fields to the
message_queue?

 

We already have NoticeBCC, but in multi-branch environments, it can be good
for BCCs to go to particular branch email addresses rather than 1 global
email address. One use case is for the member_expiry.pl cronjob. It would be
nice for BCCs or CCs to go to the branch where the patron/member is
expiring. 

 

After looking through the code, it doesn't really seem like we have anything
to handle this at the moment. We have some CCs and BCCs peppered around but
all for emails that are sent on the fly. Nothing for queued messages. 

 

Thoughts?

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180625/a0b3c8d9/attachment.html>

From katrin.fischer.83 at web.de  Mon Jun 25 08:03:49 2018
From: katrin.fischer.83 at web.de (Katrin Fischer)
Date: Mon, 25 Jun 2018 08:03:49 +0200
Subject: [Koha-devel] Add "cc" and "bcc" fields to message_queue
In-Reply-To: <078a01d40c2a$4fea6c70$efbf4550$@prosentient.com.au>
References: <078a01d40c2a$4fea6c70$efbf4550$@prosentient.com.au>
Message-ID: <78caecbe-fb0d-a256-1a69-279ed997fb4c@web.de>

Hi David,

it's true there is no configuration setting at branch level at the 
moment, but |NoticeBcc is used for queued messages and ClaimsBccCopy for 
serial and acquisition alerts sent directly.|

|Hope that helps,|

|Katrin
|


On 25.06.2018 04:14, David Cook wrote:
>
> Hi all,
>
> What do people think about adding ?cc? and ?bcc? fields to the 
> message_queue?
>
> We already have NoticeBCC, but in multi-branch environments, it can be 
> good for BCCs to go to particular branch email addresses rather than 1 
> global email address. One use case is for the member_expiry.pl 
> cronjob. It would be nice for BCCs or CCs to go to the branch where 
> the patron/member is expiring.
>
> After looking through the code, it doesn?t really seem like we have 
> anything to handle this at the moment. We have some CCs and BCCs 
> peppered around but all for emails that are sent on the fly. Nothing 
> for queued messages.
>
> Thoughts?
>
> David Cook
>
> Systems Librarian
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
> Office: 02 9212 0899
>
> Direct: 02 8005 0595
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180625/9e9da0dd/attachment.html>

From arouss1980 at gmail.com  Mon Jun 25 09:35:18 2018
From: arouss1980 at gmail.com (Andreas Roussos)
Date: Mon, 25 Jun 2018 10:35:18 +0300
Subject: [Koha-devel] Staff/OPAC ISBD views and subfield visibility
In-Reply-To: <57e33989-85c0-e2f4-405d-79708503f2c6@web.de>
References: <CAK0RUrtUaS4hMCHHa1Jm7ZztnHUAMAv+Kg__Vd7sG6WoiuGPvw@mail.gmail.com>
	<30185c75-94e7-2707-cc35-b8f6ef205888@web.de>
	<CAK0RUrtp6SYswHZG38X5PvGgHst91JqedpthjJcXX_46_oDOSg@mail.gmail.com>
	<57e33989-85c0-e2f4-405d-79708503f2c6@web.de>
Message-ID: <CAK0RUrt5tp3pVhrm7+_kRRtjyxohy1ttZPHAmM1h6nop6c2tsg@mail.gmail.com>

Hi Katrin,

As far as our library is concerned we would not want the users to see in
marc view an internal numerical code, which could be puzzling and
confusing, especially if they are looking at personal name entries, who are
usually followed by a role code in unimarc, e.g. 070 for author.

Furthermore, why is the code looking for these values "if hidden" only in
the opac interface? Why is such requirement only for opac isbd ? why not
for intranet isbd also, if at all necessary?

Sorry for insisting, but we would like to know the usefulness and reasoning
behind this.

Regards,
Andreas

On 21 June 2018 at 09:11, Katrin Fischer <katrin.fischer.83 at web.de> wrote:

> Hi Andreas,
>
> makes sense for me. Why not mark them as visible in the OPAC?
>
> Katrin
>
> On 20.06.2018 09:51, Andreas Roussos wrote:
>
> Hi Katrin,
>
> Thank you for your reply.
>
> The issue we are facing is this: unless a subfield (e.g. UNIMARC 453$0,
> Bibliographic Record Identifier) is marked as visible in the OPAC, the
> links (URLs) using that subfield will be broken in the ISBD view.
> And this happens (according to the code snippets in my original message)
> only when GetISBDView is called with 'template' = 'opac', not 'intranet'
> (i.e. only in OPAC ISBD view, not in Staff ISBD view).
>
> I hope this makes more sense.
>
> Regards,
> Andreas
>
> On 18 June 2018 at 23:22, Katrin Fischer <katrin.fischer.83 at web.de> wrote:
>
>> Hi Andreas,
>>
>> I might be misunderstanding your question, but the OPAC visibility
>> setting should take effect on all pages and views in the OPAC now. It
>> didn't use to, which was considered a long standing bug and finally fixed.
>> Now it's possible to hide fields from OPAC that can still appear in staff
>> in a reliable way. The preconfigured visibility settings in the frameworks
>> might not always be ideal - if that's what you mean, we could work on
>> improving them.
>>
>> Hope that helps,
>>
>> Katrin
>>
>>
>> On 07.06.2018 09:21, Andreas Roussos wrote:
>>
>> Dear Developers,
>>
>> If you:
>>
>> 1) edit the ISBD and OPACISBD system preferences so that they contain the
>> following code:
>>
>> #453| - translated as: |<a href="/cgi-bin/koha/catalogue/
>> detail.pl?biblionumber={4530} <http://detail.pl?biblionumber=%7B4530%7D>">{453t}</a>
>> {(453d)}|
>> #454| - translation of: |<a href="/cgi-bin/koha/catalogue/
>> detail.pl?biblionumber={4540} <http://detail.pl?biblionumber=%7B4540%7D>">{454t}</a>
>> {(454d)}|
>>
>> 2) set the visibility of (UNIMARC) fields 453$0 and 454$0 to 'hidden' in
>> the OPAC
>>
>> ...then the generated links will work fine in the Staff client but will
>> be broken in the OPAC (i.e. the URL will not include the biblionumber
>> contained in subfield 0 of fields 453/454).
>>
>> I've tracked this down to ISBDdetail.pl and opac-ISBDdetail.pl calling
>> the GetISBDView subroutine, which (for some reason) excludes subfields that
>> are hidden in the OPAC:
>>
>> https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L773-L776
>> https://github.com/Koha-Community/Koha/blob/master/C4/Biblio.pm#L812-L815
>>
>> What is the reasoning behind this?
>> In other words, why is _OPAC_ subfield visibility taken into account when
>> displaying the OPAC ISBD view (whereas visibility in Staff is not
>> considered)?
>>
>> If anything, it is more likely to have subfield 0 hidden in OPAC, while
>> visible in Staff, so one would expect the opposite logic.
>>
>> Thanks in advance for your time.
>>
>> Kind regards,
>> Andreas Roussos
>>
>>
>> _______________________________________________
>> Koha-devel mailing listKoha-devel at lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180625/8818e9f7/attachment-0001.html>

From dcook at prosentient.com.au  Mon Jun 25 09:54:04 2018
From: dcook at prosentient.com.au (David Cook)
Date: Mon, 25 Jun 2018 17:54:04 +1000
Subject: [Koha-devel] Add "cc" and "bcc" fields to message_queue
In-Reply-To: <78caecbe-fb0d-a256-1a69-279ed997fb4c@web.de>
References: <078a01d40c2a$4fea6c70$efbf4550$@prosentient.com.au>
	<78caecbe-fb0d-a256-1a69-279ed997fb4c@web.de>
Message-ID: <003a01d40c59$b046f550$10d4dff0$@prosentient.com.au>

Hi Katrin,

 

Thanks for your message. I know about those ones already, but they don?t really help for the multi-branch instances, although it looks like NoticeBcc could actually contain a string of multiple emails, so in theory a person could put a few branch emails in there and then branches could weed out the emails they don?t need, but that seems suboptimal.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Katrin Fischer
Sent: Monday, 25 June 2018 4:04 PM
To: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Add "cc" and "bcc" fields to message_queue

 

Hi David,

it's true there is no configuration setting at branch level at the moment, but NoticeBcc is used for queued messages and ClaimsBccCopy for serial and acquisition alerts sent directly.

Hope that helps,

Katrin

 

On 25.06.2018 04:14, David Cook wrote:

Hi all,

 

What do people think about adding ?cc? and ?bcc? fields to the message_queue?

 

We already have NoticeBCC, but in multi-branch environments, it can be good for BCCs to go to particular branch email addresses rather than 1 global email address. One use case is for the member_expiry.pl cronjob. It would be nice for BCCs or CCs to go to the branch where the patron/member is expiring. 

 

After looking through the code, it doesn?t really seem like we have anything to handle this at the moment. We have some CCs and BCCs peppered around but all for emails that are sent on the fly. Nothing for queued messages. 

 

Thoughts?

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 






_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180625/896046d1/attachment.html>

From Katrin.Fischer.83 at web.de  Mon Jun 25 11:51:57 2018
From: Katrin.Fischer.83 at web.de (Katrin Fischer)
Date: Mon, 25 Jun 2018 11:51:57 +0200
Subject: [Koha-devel] Staff/OPAC ISBD views and subfield visibility
In-Reply-To: <CAK0RUrt5tp3pVhrm7+_kRRtjyxohy1ttZPHAmM1h6nop6c2tsg@mail.gmail.com>
References: <CAK0RUrtUaS4hMCHHa1Jm7ZztnHUAMAv+Kg__Vd7sG6WoiuGPvw@mail.gmail.com>
	<30185c75-94e7-2707-cc35-b8f6ef205888@web.de>
	<CAK0RUrtp6SYswHZG38X5PvGgHst91JqedpthjJcXX_46_oDOSg@mail.gmail.com>
	<57e33989-85c0-e2f4-405d-79708503f2c6@web.de>
	<CAK0RUrt5tp3pVhrm7+_kRRtjyxohy1ttZPHAmM1h6nop6c2tsg@mail.gmail.com>
Message-ID: <trinity-81e1f80e-3da8-467f-9e96-a4837a32e7d4-1529920317935@3c-app-webde-bs38>

An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180625/a8b9c4e3/attachment.html>

From martin.renvoize at ptfs-europe.com  Mon Jun 25 14:43:25 2018
From: martin.renvoize at ptfs-europe.com (Renvoize, Martin)
Date: Mon, 25 Jun 2018 13:43:25 +0100
Subject: [Koha-devel] Centralize and move to gitlab
In-Reply-To: <CY1PR1101MB1148A6BDE77A56B3817433BBC6740@CY1PR1101MB1148.namprd11.prod.outlook.com>
References: <CAJzKNY7dt3s0ibfU9WggD99HAVgjGqpn-Jk7WLJLK1W=JT0ESQ@mail.gmail.com>
	<a229f8ca-1750-f2eb-fb52-66ed47def716@web.de>
	<CACpVHfwub=LzvubJFakyH0x--M3R+pVZ5=i+vj27E7V4wA5bDw@mail.gmail.com>
	<CABZfb=XcuQsJhXDmPykjU0NwT1kL6KHW+_Z8J6v-Yc9fhttPBQ@mail.gmail.com>
	<CY1PR1101MB1148A6BDE77A56B3817433BBC6740@CY1PR1101MB1148.namprd11.prod.outlook.com>
Message-ID: <CAB7SL8C23V2zNOjFySZ+-XLA0mu-r_W-nobXqKCGf9czzVRSxA@mail.gmail.com>

Well spotted Mark, would be good to get those moved too :)

*Martin Renvoize*

Development Manager




*T:* +44 (0) 1483 378728

*F:* +44 (0) 800 756 6384

*E:* martin.renvoize at ptfs-europe.com

www.ptfs-europe.com



<https://www.ptfs-europe.com>



Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at info at ptfs-europe.com


On 23 June 2018 at 03:17, Mark Tompsett <mtompset at hotmail.com> wrote:

> Greetings,
>
> Will gitify and git-bz be moved as well? Kohadevbox is still using the
> github of those.
>
> GPML,
> Mark Tompsett
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180625/f033bf19/attachment.html>

From martin.renvoize at ptfs-europe.com  Mon Jun 25 15:10:58 2018
From: martin.renvoize at ptfs-europe.com (Renvoize, Martin)
Date: Mon, 25 Jun 2018 14:10:58 +0100
Subject: [Koha-devel] Koha 18.05.01 released
Message-ID: <CAB7SL8CrXf5UtaML5idA-_AZeTCzNqicGGx7dXMY_hZdjvTmhg@mail.gmail.com>

The Koha community is proud to announce the release of 18.05.01.

This is a maintenance release and contains many bugfixes and enhancements.

As always you can download the release now and the packages will follow
shortly:

  http://download.koha-community.org

This is my first release as the 18.05.XX release maintainer, thank you very
much to everyone involved in this release.

*Martin Renvoize*

Development Manager




*T:* +44 (0) 1483 378728

*F:* +44 (0) 800 756 6384

*E:* martin.renvoize at ptfs-europe.com

www.ptfs-europe.com



<https://www.ptfs-europe.com>



Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at info at ptfs-europe.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180625/8430b76d/attachment.html>

From jonathan.druart at bugs.koha-community.org  Mon Jun 25 15:49:41 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Mon, 25 Jun 2018 10:49:41 -0300
Subject: [Koha-devel] [Koha] Koha 18.05.01 released
In-Reply-To: <CAB7SL8CrXf5UtaML5idA-_AZeTCzNqicGGx7dXMY_hZdjvTmhg@mail.gmail.com>
References: <CAB7SL8CrXf5UtaML5idA-_AZeTCzNqicGGx7dXMY_hZdjvTmhg@mail.gmail.com>
Message-ID: <CAJzKNY6ajQc6OqyBscGvKTuH9riWvx4eA8fEKDH9krmM9rJm5Q@mail.gmail.com>

The link to the release notes:
https://koha-community.org/koha-18-05-01-release/

On Mon, 25 Jun 2018 at 10:10 Renvoize, Martin <
martin.renvoize at ptfs-europe.com> wrote:

> The Koha community is proud to announce the release of 18.05.01.
>
> This is a maintenance release and contains many bugfixes and enhancements.
>
> As always you can download the release now and the packages will follow
> shortly:
>
>   http://download.koha-community.org
>
> This is my first release as the 18.05.XX release maintainer, thank you very
> much to everyone involved in this release.
>
> *Martin Renvoize*
>
> Development Manager
>
>
>
>
> *T:* +44 (0) 1483 378728 <+44%201483%20378728>
>
> *F:* +44 (0) 800 756 6384 <+44%20800%20756%206384>
>
> *E:* martin.renvoize at ptfs-europe.com
>
> www.ptfs-europe.com
>
>
>
> <https://www.ptfs-europe.com>
>
>
>
> Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30
>
> The information contained in this email message may be privileged,
> confidential and protected from disclosure. If you are not the intended
> recipient, any dissemination, distribution or copying is strictly
> prohibited. If you think that you have received this email message in
> error, please email the sender at info at ptfs-europe.com
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180625/6aee6c0a/attachment.html>

From fridolin.somers at biblibre.com  Mon Jun 25 16:32:07 2018
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Mon, 25 Jun 2018 16:32:07 +0200
Subject: [Koha-devel] Koha 17.11.07 release
Message-ID: <216bc65a-52ff-96e4-021a-c5b5587ff76d@biblibre.com>

The Koha community is proud to announce the release of Koha 17.11.07.

This is a maintenance release.

The full release notes are available at 
https://koha-community.org/koha-17-11-07-release/

17.11.x is my baby now ;)

Regards,

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
BibLibre, France - software and system maintainer

From martin.renvoize at ptfs-europe.com  Mon Jun 25 17:26:11 2018
From: martin.renvoize at ptfs-europe.com (Renvoize, Martin)
Date: Mon, 25 Jun 2018 16:26:11 +0100
Subject: [Koha-devel] Suggestion: create a deprecated() function in Koha.
In-Reply-To: <CAMSJbVt0g1oaSKnY4B8Pz63qFsJqD6Ay1ZhEYGJZtBpE65WG+w@mail.gmail.com>
References: <CAMSJbVt0g1oaSKnY4B8Pz63qFsJqD6Ay1ZhEYGJZtBpE65WG+w@mail.gmail.com>
Message-ID: <CAB7SL8Avy6eANTvCXpyP25puHa7V696c555okvtRHm_a-n+P4g@mail.gmail.com>

I've seen this sort of thing in a few projects and it works reasonably
nicely.. though I'm not sure how it would work in Koha as we seem to
replace all calls to a function and remove the function at the same time.

If we did switch to this approach I'd suggest adding code to allow it to
report to HEA so we can see the general adoption at the core level before
nuking functions entirely.

Juries out from my end as to whether this is a good or bad idea as a whole
though I'm afraid.

Martin

*Martin Renvoize*

Development Manager




*T:* +44 (0) 1483 378728

*F:* +44 (0) 800 756 6384

*E:* martin.renvoize at ptfs-europe.com

www.ptfs-europe.com



<https://www.ptfs-europe.com>



Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at info at ptfs-europe.com


On 22 June 2018 at 21:52, Barton Chittenden <barton at bywatersolutions.com>
wrote:

> It would be useful for Koha to have a 'Deprecated' function, which would
> send a warning about the caller() function and the version of Koha where
> the function will be deprecated, and what it will be replaced by... so
> let's say that C4::Adequate::DoEET() is being replaced by
> Koha::Awesome->sauce(). in Koha 18.11.
>
> In versions of koha prior to 18.11, we add a call to
>
> deprecated( "18.11", "Koha::Awesome->sauce()");
>
> at the beginning of C4::Adequate::DoEET().
>
> Then, when C4::Adequate::DoEET() is called, this would generate the
> following message in the logs:
>
> "C4::Adequate::DoEET is deprecated and will be removed in Koha 18.11. It
> will be replaced by Koha::Awesome->sauce()."
>
> This would allow plugin authors to know that they will need to patch their
> plugins before they break on upgrade.
>
> This is a bare-bones implementation of deprecated():
>
> sub deprecated {
>     my ( $version, $replacement ) = @_;
>     my (
>         $package, $filename, $line, $subroutine, $hasargs,
>         $wantarray, $evaltext, $is_require, $hints, $bitmask, $hinthash
>     ) = caller(1);
>     warn(
>         "${subroutine} is deprecated and will be removed"
>          . " in Koha version $version."
>          . defined( $replacement )
>             ? " It will be replaced by ${replacement}."
>             : ""
>     );
> }
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180625/3353231a/attachment-0001.html>

From jonathan.druart at bugs.koha-community.org  Mon Jun 25 17:45:39 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Mon, 25 Jun 2018 12:45:39 -0300
Subject: [Koha-devel] Suggestion: create a deprecated() function in Koha.
In-Reply-To: <CAMSJbVt0g1oaSKnY4B8Pz63qFsJqD6Ay1ZhEYGJZtBpE65WG+w@mail.gmail.com>
References: <CAMSJbVt0g1oaSKnY4B8Pz63qFsJqD6Ay1ZhEYGJZtBpE65WG+w@mail.gmail.com>
Message-ID: <CAJzKNY56FXgARPYg5DRVQxYBwqrxtQAyME8+p1T_yuEG1WnvJQ@mail.gmail.com>

Hi Barton,

I usually follow the same pattern for the commit messages when I remove a
subroutine from C4.
We could list them (something like `git log|grep "Move (.*) to Koha::*"`)
for each release then provide a script to catch removed subroutine.
However it will not help to know in advance (version N-1) if the plugin
will still work.
I do not think it will help much to have the deprecated function, we change
the prototype of our subroutines very often, that will also break the
plugin. I should also add that when a sub is removed it's not only moved to
Koha, code from callers is adjusted and completely different. It cannot be
done in some cases I think.

The best still is to have a good test coverage for the plugin ;)

Cheers,
Jonathan


On Fri, 22 Jun 2018 at 17:52 Barton Chittenden <barton at bywatersolutions.com>
wrote:

> It would be useful for Koha to have a 'Deprecated' function, which would
> send a warning about the caller() function and the version of Koha where
> the function will be deprecated, and what it will be replaced by... so
> let's say that C4::Adequate::DoEET() is being replaced by
> Koha::Awesome->sauce(). in Koha 18.11.
>
> In versions of koha prior to 18.11, we add a call to
>
> deprecated( "18.11", "Koha::Awesome->sauce()");
>
> at the beginning of C4::Adequate::DoEET().
>
> Then, when C4::Adequate::DoEET() is called, this would generate the
> following message in the logs:
>
> "C4::Adequate::DoEET is deprecated and will be removed in Koha 18.11. It
> will be replaced by Koha::Awesome->sauce()."
>
> This would allow plugin authors to know that they will need to patch their
> plugins before they break on upgrade.
>
> This is a bare-bones implementation of deprecated():
>
> sub deprecated {
>     my ( $version, $replacement ) = @_;
>     my (
>         $package, $filename, $line, $subroutine, $hasargs,
>         $wantarray, $evaltext, $is_require, $hints, $bitmask, $hinthash
>     ) = caller(1);
>     warn(
>         "${subroutine} is deprecated and will be removed"
>          . " in Koha version $version."
>          . defined( $replacement )
>             ? " It will be replaced by ${replacement}."
>             : ""
>     );
> }
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180625/bbda1eb6/attachment.html>

From fridolin.somers at biblibre.com  Tue Jun 26 10:47:32 2018
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Tue, 26 Jun 2018 10:47:32 +0200
Subject: [Koha-devel] Koha 17.05.13 release
Message-ID: <dc2d3a4d-236f-f1d1-c123-b8c90ac45a84@biblibre.com>

The Koha community is proud to announce the release of Koha 17.05.13.

This is a maintenance release with only critical bugfixes.

The full release notes are available at 
https://koha-community.org/koha-17-05-13-release/

I see there is not a lot of translation changes.
I will stop managing 17.05.x after 17.05.16 in septembre.

Regards,

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
BibLibre, France - software and system maintainer

From paul.poulain at biblibre.com  Fri Jun 29 16:18:19 2018
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 29 Jun 2018 16:18:19 +0200
Subject: [Koha-devel] Do you want to see a Koha 18.05 running Elastic Search
 in production ?
Message-ID: <bd518484-f38a-a812-f89a-a2fec6b72e20@biblibre.com>

just go there : https://koha.bulac.fr kudos to BULAC for this move !

And thanks to them for the developments they've sponsored (and are on 
bugzilla)


PS: they made it by themselves, so no reason to congratulate BibLibre ;)

-- 
Paul Poulain, Associ?-g?rant / co-owner
BibLibre, Services en logiciels libres pour les biblioth?ques
BibLibre, Open Source software and services for libraries


From tomascohen at gmail.com  Fri Jun 29 17:42:20 2018
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 29 Jun 2018 12:42:20 -0300
Subject: [Koha-devel] Do you want to see a Koha 18.05 running Elastic
 Search in production ?
In-Reply-To: <bd518484-f38a-a812-f89a-a2fec6b72e20@biblibre.com>
References: <bd518484-f38a-a812-f89a-a2fec6b72e20@biblibre.com>
Message-ID: <CABZfb=UbnFgcpWzMH9rBWPoQdWw0igmja3Rbz1toO7wpFy14dg@mail.gmail.com>

Congraaaaats to Bulac!

El vie., 29 jun. 2018 a las 11:16, Paul Poulain (<paul.poulain at biblibre.com>)
escribi?:

> just go there : https://koha.bulac.fr kudos to BULAC for this move !
>
> And thanks to them for the developments they've sponsored (and are on
> bugzilla)
>
>
> PS: they made it by themselves, so no reason to congratulate BibLibre ;)
>
> --
> Paul Poulain, Associ?-g?rant / co-owner
> BibLibre, Services en logiciels libres pour les biblioth?ques
> BibLibre, Open Source software and services for libraries
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-- 
Tom?s Cohen Arazi
Theke Solutions (https://theke.io <http://theke.io/>)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180629/86941dc6/attachment.html>

From abesottedphoenix at yahoo.com  Fri Jun 29 20:35:08 2018
From: abesottedphoenix at yahoo.com (BWS Johnson)
Date: Fri, 29 Jun 2018 18:35:08 +0000 (UTC)
Subject: [Koha-devel] Do you want to see a Koha 18.05 running Elastic
 Search in production ?
In-Reply-To: <bd518484-f38a-a812-f89a-a2fec6b72e20@biblibre.com>
References: <bd518484-f38a-a812-f89a-a2fec6b72e20@biblibre.com>
Message-ID: <1572851469.411859.1530297308495@mail.yahoo.com>

Salvete!
>>
just go there : https://koha.bulac.fr kudos to BULAC for this move !

And thanks to them for the developments they've sponsored (and are on 
bugzilla)

PS: they made it by themselves, so no reason to congratulate BibLibre ;)
>>
?????? I saw the Korean in the upper left, and I just had to try it.

?????? I am impressed!

?????? A garbage search for

???
?????? came back with results right away. It seems like search is ranked relevantly so that the entire word stays put. At least the seems to be the case on the first page in the higher ranked results. For instance, Koha wasn't naughty and barfed up the 

?
syllable in another word. That is hugely good news. I don't read well enough to know precisely how accurately it's searching, but I definitely have seen a few catalogues where it isn't even close.
Thanks,Brooke
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180629/2d5fda6e/attachment.html>

From nicolas.legrand at bulac.fr  Fri Jun 29 21:16:15 2018
From: nicolas.legrand at bulac.fr (Nicolas Legrand)
Date: Fri, 29 Jun 2018 21:16:15 +0200
Subject: [Koha-devel] Do you want to see a Koha 18.05 running Elastic
 Search in production ?
In-Reply-To: <bd518484-f38a-a812-f89a-a2fec6b72e20@biblibre.com>
References: <bd518484-f38a-a812-f89a-a2fec6b72e20@biblibre.com>
Message-ID: <CAODBKZexrOfJ0sNVrzZtzQzyv2j3cZq+=BJ=ppjQhUAso4B_Hg@mail.gmail.com>

How bist, Koha community?

2018-06-29 16:18 GMT+02:00 Paul Poulain <paul.poulain at biblibre.com>:

> just go there : https://koha.bulac.fr kudos to BULAC for this move !
>
>
Thank you Paul !


> And thanks to them for the developments they've sponsored (and are on
> bugzilla)
>
>
> PS: they made it by themselves, so no reason to congratulate BibLibre ;)
>

Well the weighting parts made by Alex and the mapping made by Claire
clearly helped us :).

And of course the awesome work of Nick and the whole Koha community is
priceless.

It's still a bit patchy right now, but it's far better from what we had
with Zebra : we're finding our documents! The defaults work great for all
languages. We had a lot of problem with Chinese, Japanese, Korean, Farsi,
Ourdu... And now each language is easy to find as it should. It's the first
time we switch versions and we see so much big smiles on the faces of our
colleagues. Until now, they had exemples of better research tools, now we
have the better research tool :).

ta ta for now :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180629/a7c269a9/attachment.html>

From nicolas.legrand at bulac.fr  Fri Jun 29 21:16:38 2018
From: nicolas.legrand at bulac.fr (Nicolas Legrand)
Date: Fri, 29 Jun 2018 21:16:38 +0200
Subject: [Koha-devel] Do you want to see a Koha 18.05 running Elastic
 Search in production ?
In-Reply-To: <CABZfb=UbnFgcpWzMH9rBWPoQdWw0igmja3Rbz1toO7wpFy14dg@mail.gmail.com>
References: <bd518484-f38a-a812-f89a-a2fec6b72e20@biblibre.com>
	<CABZfb=UbnFgcpWzMH9rBWPoQdWw0igmja3Rbz1toO7wpFy14dg@mail.gmail.com>
Message-ID: <CAODBKZeNSXA8oKL5r393AyURYE66+SFOoeOoZbdBCjZqdq3zXg@mail.gmail.com>

thank you Tomas ^^

2018-06-29 17:42 GMT+02:00 Tomas Cohen Arazi <tomascohen at gmail.com>:

> Congraaaaats to Bulac!
>
> El vie., 29 jun. 2018 a las 11:16, Paul Poulain (<
> paul.poulain at biblibre.com>) escribi?:
>
>> just go there : https://koha.bulac.fr kudos to BULAC for this move !
>>
>> And thanks to them for the developments they've sponsored (and are on
>> bugzilla)
>>
>>
>> PS: they made it by themselves, so no reason to congratulate BibLibre ;)
>>
>> --
>> Paul Poulain, Associ?-g?rant / co-owner
>> BibLibre, Services en logiciels libres pour les biblioth?ques
>> BibLibre, Open Source software and services for libraries
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>
> --
> Tom?s Cohen Arazi
> Theke Solutions (https://theke.io <http://theke.io/>)
> ? +54 9351 3513384
> GPG: B2F3C15F
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 

*Nicolas Legrand*
Administration technique et d?veloppements du syst?me de gestion de la
biblioth?que

[image: Logo BULAC]

Biblioth?que universitaire
des langues et civilisations

65 rue des Grands Moulins
F-75013 PARIS
T +33 1 81 69 *18 22*
www.bulac.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180629/6970459b/attachment-0001.html>

From kohanews at gmail.com  Fri Jun 29 21:33:50 2018
From: kohanews at gmail.com (kohanews)
Date: Fri, 29 Jun 2018 12:33:50 -0700
Subject: [Koha-devel] Koha Community Newsletter: June 2018
Message-ID: <f13bf406-4c2e-6c3f-6db5-e1e1cc3d5e41@gmail.com>

The Koha Community Newsletter for June 2018 is here:
https://koha-community.org/koha-community-newsletter-june-2018/

Many thanks to the folks who submitted articles and news to this month's 
newsletter.

Please feel free to email me with any corrections or suggestions.

Thanks!

-- 
Chad Roseburg
Editor, Koha Community Newsletter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180629/bfbd1171/attachment.html>

From barton at bywatersolutions.com  Sat Jun 30 00:54:00 2018
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Fri, 29 Jun 2018 18:54:00 -0400
Subject: [Koha-devel] Do you want to see a Koha 18.05 running Elastic
 Search in production ?
In-Reply-To: <CAODBKZeNSXA8oKL5r393AyURYE66+SFOoeOoZbdBCjZqdq3zXg@mail.gmail.com>
References: <bd518484-f38a-a812-f89a-a2fec6b72e20@biblibre.com>
	<CABZfb=UbnFgcpWzMH9rBWPoQdWw0igmja3Rbz1toO7wpFy14dg@mail.gmail.com>
	<CAODBKZeNSXA8oKL5r393AyURYE66+SFOoeOoZbdBCjZqdq3zXg@mail.gmail.com>
Message-ID: <CAMSJbVs57oToYEf2dYJKMP9+1TnH7=rMpAFTqrLv5_=hxZP7wg@mail.gmail.com>

Congratulations!

I have to say, I got goosebumps when I saw

Results of search for 'juggling' with limit(s): 'suppress:0'

rather than

Results of search for 'kw,wrdl: juggling'

Cheers,

--Barton

On Fri, Jun 29, 2018 at 3:16 PM, Nicolas Legrand <nicolas.legrand at bulac.fr>
wrote:

> thank you Tomas ^^
>
> 2018-06-29 17:42 GMT+02:00 Tomas Cohen Arazi <tomascohen at gmail.com>:
>
>> Congraaaaats to Bulac!
>>
>> El vie., 29 jun. 2018 a las 11:16, Paul Poulain (<
>> paul.poulain at biblibre.com>) escribi?:
>>
>>> just go there : https://koha.bulac.fr kudos to BULAC for this move !
>>>
>>> And thanks to them for the developments they've sponsored (and are on
>>> bugzilla)
>>>
>>>
>>> PS: they made it by themselves, so no reason to congratulate BibLibre ;)
>>>
>>> --
>>> Paul Poulain, Associ?-g?rant / co-owner
>>> BibLibre, Services en logiciels libres pour les biblioth?ques
>>> BibLibre, Open Source software and services for libraries
>>>
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at lists.koha-community.org
>>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>> website : http://www.koha-community.org/
>>> git : http://git.koha-community.org/
>>> bugs : http://bugs.koha-community.org/
>>
>> --
>> Tom?s Cohen Arazi
>> Theke Solutions (https://theke.io <http://theke.io/>)
>> ? +54 9351 3513384
>> GPG: B2F3C15F
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>
>
>
> --
>
> *Nicolas Legrand*
> Administration technique et d?veloppements du syst?me de gestion de la
> biblioth?que
>
> [image: Logo BULAC]
>
> Biblioth?que universitaire
> des langues et civilisations
>
> 65 rue des Grands Moulins
> F-75013 PARIS
> T +33 1 81 69 *18 22*
> www.bulac.fr
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20180629/7f40d857/attachment.html>