From jonathan.druart at bugs.koha-community.org  Sun Sep  1 17:48:21 2019
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Sun, 1 Sep 2019 11:48:21 -0400
Subject: [Koha-devel] Duplicated holds notices
In-Reply-To: <CAA_eX3PurBR3J0OxhJopeLDdFgdx4bJ-yG4u0C+mV7hZNcCfMA@mail.gmail.com>
References: <CAA_eX3PurBR3J0OxhJopeLDdFgdx4bJ-yG4u0C+mV7hZNcCfMA@mail.gmail.com>
Message-ID: <CAJzKNY41uLTKUNGXg=Rdb8o9o7B8YB0zFRqjNE_5f0PbkY8Sbw@mail.gmail.com>

Hi Nick,

You are talking about HOLDPLACED, right?
What about the timestamps, are they identical? Do you see 2 queries in the
webserver logs?

Cheers,
Jonathan

Le mer. 21 août 2019 à 15:01, Nick Clemens <nick at bywatersolutions.com> a
écrit :

> Hi All,
>
> We have been getting several reports of duplicated holds notices on a few
> systems.
>
> We cannot find any issues in the code that would duplciate this, there are
> not duplicated transports or anything in the data we can find.
>
> We have noticed that some of the modals have a submit button, and then js
> to submit the form, however, Kyle attempted to add
> 'preventDoubleFormSubmit()' to the page and that has not helped
>
> $(document).ready(function() { if (window.location.href.indexOf("circ/
> returns.pl") > -1) { $('form').preventDoubleFormSubmit(); } });
>
> Has anyone else experienced this?
>
> -Nick
>
> --
> Nick Clemens
> ByWater Solutions
> bywatersolutions.com
> Phone: (888) 900-8944
> Pronouns: (he/him/his)
> Timezone: Eastern
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://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/20190901/a0a924f6/attachment.html>

From dcook at prosentient.com.au  Mon Sep  2 04:03:23 2019
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Mon, 2 Sep 2019 12:03:23 +1000
Subject: [Koha-devel] Removing data from hea.koha-community.org
Message-ID: <06de01d56132$9a376b80$cea64280$@prosentient.com.au>

Hi all,

 

Do we have any process for removing data from hea.koha-community.org? 

 

For instance, say that a library permanently closes, or just no longer wants
to be listed?

 

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/20190902/a7096415/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20190902/a7096415/attachment.sig>

From dcook at prosentient.com.au  Mon Sep  2 07:48:53 2019
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Mon, 2 Sep 2019 15:48:53 +1000
Subject: [Koha-devel] IndependentBranches == "softno" on SIP server
Message-ID: <070a01d56152$1a9bfa60$4fd3ef20$@prosentient.com.au>

Hi all,

 

I've been getting errors on a SIP server that indicate that
"IndependentBranches" is non-zero. However, both MySQL and Memcached have
said that "IndependentBranches" is zero. 

 

So I added some logging to the SIP server, and it's saying that the value of
"IndependentBranches" - at the time of the error - is "softno". 

 

So I looked through the Koha code and the only reference to "softno" I can
find is in regards to "CheckPrevCheckout".

 

I've checked environmental variables and every bit of code I can think of,
and I'm absolutely stumped by this one.

 

The most feasible answer to me is a caching problem. However, it happened
over the course of weeks, and it always had the same value, so that seems a
bit far-fetched too.

 

I suppose the next step is to add yet more logging, but I figured I'd reach
out to all of you to see if anyone has had a similar problem. 

 

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/20190902/dcd40a33/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20190902/dcd40a33/attachment.sig>

From dcook at prosentient.com.au  Mon Sep  2 09:55:23 2019
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Mon, 2 Sep 2019 17:55:23 +1000
Subject: [Koha-devel] IndependentBranches == "softno" on SIP server
Message-ID: <074501d56163$c6815940$53840bc0$@prosentient.com.au>

Oh. I've found something interesting!

lib/Koha/Patron.pm uses "checkPrevCheckout" instead of "CheckPrevCheckout",
which is why I wasn't finding it with my case-sensitive grep. 

 

In C4::Circulation::CanBookBeIssued, I think it is very likely that
C4::Context->preference("checkPrevCheckout") is called and then the next
call is C4::Context->preference("IndependentBranches"), and somehow. the
value from "checkPrevCheckout" is being used instead of the true value of
"IndepenentBranches". Yikes!

 

I don't know how it's happening, but it's happening. 

 

I notice that Plack runs Koha::Caches->flush_L1_caches() routinely. So does
bin/migration_tools/rebuild_zebra.pl when it's run in daemon_mode. I reckon
a short-term solution would be to add that cache flushing to the SIP server
as well. 

 

However, I'm still really curious how the wrong value is being returned by
C4::Context->preference("IndependentBranches").

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: dcook at prosentient.com.au <dcook at prosentient.com.au> 
Sent: Monday, 2 September 2019 3:49 PM
To: 'koha-devel' <koha-devel at lists.koha-community.org>
Subject: IndependentBranches == "softno" on SIP server

 

Hi all,

 

I've been getting errors on a SIP server that indicate that
"IndependentBranches" is non-zero. However, both MySQL and Memcached have
said that "IndependentBranches" is zero. 

 

So I added some logging to the SIP server, and it's saying that the value of
"IndependentBranches" - at the time of the error - is "softno". 

 

So I looked through the Koha code and the only reference to "softno" I can
find is in regards to "CheckPrevCheckout".

 

I've checked environmental variables and every bit of code I can think of,
and I'm absolutely stumped by this one.

 

The most feasible answer to me is a caching problem. However, it happened
over the course of weeks, and it always had the same value, so that seems a
bit far-fetched too.

 

I suppose the next step is to add yet more logging, but I figured I'd reach
out to all of you to see if anyone has had a similar problem. 

 

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/20190902/b1dae8bd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20190902/b1dae8bd/attachment-0001.sig>

From agustinmoyano at theke.io  Wed Sep  4 19:33:30 2019
From: agustinmoyano at theke.io (Agustin Moyano)
Date: Wed, 4 Sep 2019 14:33:30 -0300
Subject: [Koha-devel] Fwd: Developer tool anouncement
In-Reply-To: <CALdMRuH1RvYv84Mfwt=VdprHqe1T0dKd7Q=JPE-vf6Sm8jhcuA@mail.gmail.com>
References: <CALdMRuH1RvYv84Mfwt=VdprHqe1T0dKd7Q=JPE-vf6Sm8jhcuA@mail.gmail.com>
Message-ID: <CALdMRuHdVp-x6RTRgJ-i0pLi1kEgAab+n8A2PfAcjV5tYk2_jQ@mail.gmail.com>

Hi community, I'm proud to anounce this tool I've developed to tidy up
"WIP" commits

https://gitlab.com/thekesolutions/tools/git-rk

Really hope it helps

Ps: save the kittens! ;P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20190904/bd0fa92d/attachment.html>

From nick at bywatersolutions.com  Wed Sep  4 20:33:47 2019
From: nick at bywatersolutions.com (Nick Clemens)
Date: Wed, 4 Sep 2019 14:33:47 -0400
Subject: [Koha-devel] Duplicated holds notices
In-Reply-To: <CAJzKNY41uLTKUNGXg=Rdb8o9o7B8YB0zFRqjNE_5f0PbkY8Sbw@mail.gmail.com>
References: <CAA_eX3PurBR3J0OxhJopeLDdFgdx4bJ-yG4u0C+mV7hZNcCfMA@mail.gmail.com>
 <CAJzKNY41uLTKUNGXg=Rdb8o9o7B8YB0zFRqjNE_5f0PbkY8Sbw@mail.gmail.com>
Message-ID: <CAA_eX3O08hsLQXmaVXybof+LLEiLPd9_jKy3ZRvELaDX7XYOrg@mail.gmail.com>

Yes, we see two post requests, the timestamps are identical

On Sun, Sep 1, 2019 at 11:48 AM Jonathan Druart <
jonathan.druart at bugs.koha-community.org> wrote:

> Hi Nick,
>
> You are talking about HOLDPLACED, right?
> What about the timestamps, are they identical? Do you see 2 queries in the
> webserver logs?
>
> Cheers,
> Jonathan
>
> Le mer. 21 août 2019 à 15:01, Nick Clemens <nick at bywatersolutions.com> a
> écrit :
>
>> Hi All,
>>
>> We have been getting several reports of duplicated holds notices on a few
>> systems.
>>
>> We cannot find any issues in the code that would duplciate this, there
>> are not duplicated transports or anything in the data we can find.
>>
>> We have noticed that some of the modals have a submit button, and then js
>> to submit the form, however, Kyle attempted to add
>> 'preventDoubleFormSubmit()' to the page and that has not helped
>>
>> $(document).ready(function() { if (window.location.href.indexOf("circ/
>> returns.pl") > -1) { $('form').preventDoubleFormSubmit(); } });
>>
>> Has anyone else experienced this?
>>
>> -Nick
>>
>> --
>> Nick Clemens
>> ByWater Solutions
>> bywatersolutions.com
>> Phone: (888) 900-8944
>> Pronouns: (he/him/his)
>> Timezone: Eastern
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> https://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/
>>
>

-- 
Nick Clemens
ByWater Solutions
bywatersolutions.com
Phone: (888) 900-8944
Pronouns: (he/him/his)
Timezone: Eastern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20190904/161511b7/attachment.html>

From severine.queune at bulac.fr  Fri Sep 13 14:01:41 2019
From: severine.queune at bulac.fr (=?UTF-8?Q?S=C3=A9verine_Queune?=)
Date: Fri, 13 Sep 2019 14:01:41 +0200
Subject: [Koha-devel] BULAC library is looking for developpers !
Message-ID: <CAMHz3Nj=MPiTiA_KZ=bqCkvcFCBeUuKk7WBXVu0aHsz87zFrMw@mail.gmail.com>

Dear Koha community,

The BULAC library <http://www.bulac.fr> would like to sponsor new features
concerning suggestions
, detailed on the following tickets :

*Concerning suggestions creation :*


   -

   Bug 14963
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14963> -
   Ability to suggest purchase on existing catalogue record


   -

   Bug 14973
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14973> -
   Suggestions - Search and warn user about existing biblio when submitting a
   suggestion

*Concerning suggestions update :*


   -

   Bug 18743
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18743> -
   Filter suggestion lists correctly for IndependentBranches
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23594>
   - Bug 23590
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23590>
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23590>
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23590> -
   Allow to modify the manager of a suggestion
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18743>
   -

   Bug 23594
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23594> -
   Batch modification for itemtypes on suggestions page
   - Bug 23596
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23596> -
   Update/Delete suggestion reason when receiving the item

*Concerning suggestions workflow :*


   -

   Bug 23591
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23591> - Add
   a new "Suggestions details" tab on bibliographic record
   -

   Bug 23592
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23592> - Link
   between suggestion and bibliographic record on staff client
   -

   Bug 23593
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23593> - Link
   between suggestion and bibliographic record on OPAC
   -

   Bug 22784
   <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22784> -
   Archiving Purchase Suggestions


Tests will be handled by the BULAC team.

Feel free to write to sigb <koha at bulac.fr>@bulac.fr <sigb at bulac.fr> if you
need further information or to send your proposal for these developments.

Thank you !

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

*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/20190913/671eb562/attachment.html>

From kohanews at gmail.com  Sat Sep 14 02:43:22 2019
From: kohanews at gmail.com (kohanews)
Date: Fri, 13 Sep 2019 17:43:22 -0700
Subject: [Koha-devel] Call for News: September 2019 Newsletter
Message-ID: <cb3d554f-e079-a4af-cfcb-a0aaa61afa37@gmail.com>

I'm collecting news for the September 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 dcook at prosentient.com.au  Thu Sep 19 04:13:06 2019
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 19 Sep 2019 12:13:06 +1000
Subject: [Koha-devel] Run Koha::Caches->flush_L1_caches() on SIP Server
Message-ID: <00e701d56e8f$c6739560$535ac020$@prosentient.com.au>

Hi all,

 

Who are the SIP experts?

 

I've noticed that Koha::Caches->flush_L1_caches() never gets run on the SIP
Server, and this means that the SIP Server can get stuck with old cached
values that can never be changed without a restart. 

 

I've opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23640
to look into this, but I don't know the SIP Server well enough to know off
the top of my head which function best represents every request (or if we
want to only do it per connection, but I don't know how often connection
attempts are done with SIP). 

 

I can investigate this, but I figure it  makes more sense to leverage other
people's expertise first. 

 

(Note: If you couple this issue with
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13193, you can
theoretically have a SIP server persistently running with invalid system
preferences. Either we push #13193, or we update SIP Server to reconnect to
Memcached after a fork, so that it doesn't inherit the socket connection
from the master SIP process.)

 

Cheers,

 

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/20190919/4d9baa71/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20190919/4d9baa71/attachment.sig>

From alex.sassmannshausen at gmail.com  Mon Sep 23 09:01:16 2019
From: alex.sassmannshausen at gmail.com (Alex Sassmannshausen)
Date: Mon, 23 Sep 2019 09:01:16 +0200
Subject: [Koha-devel] Hackfest 2019, registration open !!!
In-Reply-To: <98a1ebc3-7b77-12c1-b9f7-156df24a1ccb@biblibre.com>
References: <66a25965-abad-6970-0ee4-4a0d33ac1afe@biblibre.com>
 <98a1ebc3-7b77-12c1-b9f7-156df24a1ccb@biblibre.com>
Message-ID: <87muevxzr7.fsf@gmail.com>

Hi Paul,

I used to work for PTFS-Europe, but work life has taken me in different
directions over the last few years.

I was thinking of popping by the hackfest next week — I no longer work
on Koha professionally, but it'd be lovely to catch up with the
community.

Are you happy for me to come to the space during the hackfest? I
wouldn't need lunch at all, and can free up my table if we're low on
space…

Would be great to see you all again,

Alex

Paul Poulain <paul.poulain at biblibre.com> writes:

> A reminder of the hackfest dates & registration open. Drop me an email if you plan to join us !
>
> Le 09/07/2019 à 10:27, Paul Poulain a écrit :
>
>  Hello,
>
>  Once again, BibLibre is happy to invite Koha users and developers for a week of fun, working on Koha for improving it's quality !
>
>  Dates : September 30th - October 4th. Anyone is welcomed any day: it's not required to come the whole week. But a minimum of 2 consecutive day is needed to be able to do something
>  useful
>
>  Location: 108 rue Breteuil, F-13006 Marseille
>
>  Who is invited : anyone willing to contribute to Koha, you don't need to be a developer to join us ! There is a lot of useful things a librarian can do much better than a developer, like testing,
>  documenting.
>
>  How to register : drop me an email
>
>  How much does it cost : nothing (you'll have to deal with your traveling fees though, and we organize the lunch, with a fee of 15-17€ per day)
>
>  Last but not least => come with your swimsuit, the sea is usually welcoming in September/early October :D
>
> -- 
> 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/


From fridolin.somers at biblibre.com  Tue Sep 24 09:57:27 2019
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Tue, 24 Sep 2019 09:57:27 +0200
Subject: [Koha-devel] Koha 19.05.04 release
In-Reply-To: <b3afcbd2-65c9-77ec-e0a7-118273652ec7@biblibre.com>
References: <71167a98-7034-ebd0-58fb-8df354418b37@biblibre.com>
 <cc293ed7-9afb-0ff5-6572-8eeba0fe303b@biblibre.com>
 <b3afcbd2-65c9-77ec-e0a7-118273652ec7@biblibre.com>
Message-ID: <2d8fac80-9fe2-2864-00b1-54b8ae487f7f@biblibre.com>

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

This is a maintenance release.

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

Debian packages will soon be available.

Next month we start preparing 20.05 cycle.

Regards,

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

From bargioni at pusc.it  Tue Sep 24 11:29:28 2019
From: bargioni at pusc.it (Stefano Bargioni)
Date: Tue, 24 Sep 2019 11:29:28 +0200
Subject: [Koha-devel] Koha and Wikidata
Message-ID: <0A6A21CA-B8F6-4E0F-94E9-E2896D089C0C@pusc.it>

Hi,
is there somebody with experience in MediaWiki::Bot or MediaWiki::API?
I'd like to evaluate the interaction with Wikidata from/to Koha, for authority records.
Thx. Stefano

From claire.hernandez at biblibre.com  Tue Sep 24 14:31:02 2019
From: claire.hernandez at biblibre.com (Claire Hernandez)
Date: Tue, 24 Sep 2019 14:31:02 +0200
Subject: [Koha-devel] Koha and Wikidata
In-Reply-To: <0A6A21CA-B8F6-4E0F-94E9-E2896D089C0C@pusc.it>
References: <0A6A21CA-B8F6-4E0F-94E9-E2896D089C0C@pusc.it>
Message-ID: <20190924123102.GA28739@claire-biblibre>

Hi Stefano,

Some months ago, I used RDF::Query::Client to query Wikidata with Sparql queries. I write a small external app to Koha that reply in json to queries that koha could do (or another app).

I don't know if it can help you.

Regards,
Claire.

Le 24/09/19 - 11:29, Stefano Bargioni a écrit :
> Hi,
> is there somebody with experience in MediaWiki::Bot or MediaWiki::API?
> I'd like to evaluate the interaction with Wikidata from/to Koha, for authority records.
> Thx. Stefano
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://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/

From bargioni at pusc.it  Wed Sep 25 16:28:04 2019
From: bargioni at pusc.it (bargioni at pusc.it)
Date: Wed, 25 Sep 2019 16:28:04 +0200
Subject: [Koha-devel] Koha and Wikidata
In-Reply-To: <20190924123102.GA28739@claire-biblibre>
References: <0A6A21CA-B8F6-4E0F-94E9-E2896D089C0C@pusc.it>
 <20190924123102.GA28739@claire-biblibre>
Message-ID: <4ED86D7F-D9EE-485F-8D0B-88DBB0FCA45D@pusc.it>

Merci, Claire. Very useful for queries. 
Now I'm looking for a way to add items, especially authors, if not present in Wikidata.
Python seems the choice, since it is well documented. Of course, Perl interaction with Koha is better.
So, I hope to understand if MediaWiki::API/Bot can create items.
Best regards. Stefano

> On 24 Sep 2019, at 14:31, Claire Hernandez <claire.hernandez at biblibre.com> wrote:
> 
> Hi Stefano,
> 
> Some months ago, I used RDF::Query::Client to query Wikidata with Sparql queries. I write a small external app to Koha that reply in json to queries that koha could do (or another app).
> 
> I don't know if it can help you.
> 
> Regards,
> Claire.
> 
> Le 24/09/19 - 11:29, Stefano Bargioni a écrit :
>> Hi,
>> is there somebody with experience in MediaWiki::Bot or MediaWiki::API?
>> I'd like to evaluate the interaction with Wikidata from/to Koha, for authority records.
>> Thx. Stefano
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> https://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/
> 


From fridolin.somers at biblibre.com  Fri Sep 27 16:27:10 2019
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Fri, 27 Sep 2019 16:27:10 +0200
Subject: [Koha-devel] kohastructure.sql : columns with COLLATE
Message-ID: <fec0f9aa-7ca9-8fd1-7f07-e2958d109f35@biblibre.com>

Hi

I'm working on DB structure compare.
I note that in installer/data/mysql/kohastructure.sql, a few columns 
define CHARACTER SET and/or COLLATE, with same values as table.

Is this usefull or should we remove it ?

$ grep  'COLLATE' installer/data/mysql/kohastructure.sql  | grep -v 
ENGIN | grep 'utf8mb4_unicode_ci'
   `category_name` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL 
DEFAULT '',
   `font` char(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT 
NULL DEFAULT 'TR',
   `text_justify` char(1) CHARACTER SET utf8mb4 COLLATE 
utf8mb4_unicode_ci NOT NULL DEFAULT 'L',
   `auto_renew_error` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT 
NULL, -- automatic renewal error
   `auto_renew_error` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT 
NULL, -- automatic renewal error
   `suppliers_report` MEDIUMTEXT COLLATE utf8mb4_unicode_ci, -- reports 
received from suppliers
       entity varchar(16) COLLATE utf8mb4_unicode_ci NOT NULL,
       code varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL,
       lang varchar(25) COLLATE utf8mb4_unicode_ci NOT NULL, -- could be 
a foreign key
       translation MEDIUMTEXT COLLATE utf8mb4_unicode_ci,
   `branchcode` varchar(10) CHARACTER SET utf8mb4 COLLATE 
utf8mb4_unicode_ci DEFAULT NULL,

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

From tomascohen at gmail.com  Fri Sep 27 18:41:54 2019
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 27 Sep 2019 13:41:54 -0300
Subject: [Koha-devel] A case against some uses of C4::Context->userenv
Message-ID: <CABZfb=UF295=-Y4iC3RmkMh4nj5=M9PfgrdWL5pnjk+jF2g1nA@mail.gmail.com>

Hi all, I've been looking at the 'Claims returned' work (awesome!) [1] and
I've noticed a pattern we should, in my opinion, start avoiding and
reverting.

It is quite common to find uses of C4::Context->userenv in the Koha::*
namespace, either as a plain requirement (if the borrowernumber is not set
we bail out) or just as a fallback. I think it is wrong to expect such
environment status in our logic. It complicates things in various ways. [2]

It is done this way because:
- We come from the CGI era, in which it made perfect sense
- Cookie auth is well established on the UI
- When migrating from C4:* into Koha:* it is easier to just keep the
current behavior and then evolve.

I propose we leave them out, and add as a parameter whatever we are
expecting to find in the userenv hashref. That way we could use this new
libs in the API (which is not cookie-only).

Looking forward to hear your opinions

[1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14697
[2] CLI scripts are using Koha::* libraries, and we then need to 'emulate'
that userenv or even add code to detect we don't have a userenv.

-- 
Tomás Cohen Arazi
Theke Solutions (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/20190927/6a4fad50/attachment.html>

From tomascohen at gmail.com  Fri Sep 27 19:05:55 2019
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 27 Sep 2019 14:05:55 -0300
Subject: [Koha-devel] kohastructure.sql : columns with COLLATE
In-Reply-To: <fec0f9aa-7ca9-8fd1-7f07-e2958d109f35@biblibre.com>
References: <fec0f9aa-7ca9-8fd1-7f07-e2958d109f35@biblibre.com>
Message-ID: <CABZfb=Vg4q2ONr+w3-aFcq0Wqtu870ufXpbNm2SRMfVrkZ2WnQ@mail.gmail.com>

I think it doesn't really make sense. There are cases in which the general
table collation is utf8mb4_unicode_ci and some columns need utf8mb4_binary.
I think those are the only meaningful ones.

El vie., 27 sept. 2019 a las 11:27, Fridolin SOMERS (<
fridolin.somers at biblibre.com>) escribió:

> Hi
>
> I'm working on DB structure compare.
> I note that in installer/data/mysql/kohastructure.sql, a few columns
> define CHARACTER SET and/or COLLATE, with same values as table.
>
> Is this usefull or should we remove it ?
>
> $ grep  'COLLATE' installer/data/mysql/kohastructure.sql  | grep -v
> ENGIN | grep 'utf8mb4_unicode_ci'
>    `category_name` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL
> DEFAULT '',
>    `font` char(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT
> NULL DEFAULT 'TR',
>    `text_justify` char(1) CHARACTER SET utf8mb4 COLLATE
> utf8mb4_unicode_ci NOT NULL DEFAULT 'L',
>    `auto_renew_error` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT
> NULL, -- automatic renewal error
>    `auto_renew_error` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT
> NULL, -- automatic renewal error
>    `suppliers_report` MEDIUMTEXT COLLATE utf8mb4_unicode_ci, -- reports
> received from suppliers
>        entity varchar(16) COLLATE utf8mb4_unicode_ci NOT NULL,
>        code varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL,
>        lang varchar(25) COLLATE utf8mb4_unicode_ci NOT NULL, -- could be
> a foreign key
>        translation MEDIUMTEXT COLLATE utf8mb4_unicode_ci,
>    `branchcode` varchar(10) CHARACTER SET utf8mb4 COLLATE
> utf8mb4_unicode_ci DEFAULT NULL,
>
> --
> Fridolin SOMERS <fridolin.somers at biblibre.com>
> BibLibre, France - software and system maintainer
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://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 (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/20190927/a60dbed0/attachment.html>

From martin.renvoize at ptfs-europe.com  Fri Sep 27 19:09:42 2019
From: martin.renvoize at ptfs-europe.com (Renvoize, Martin)
Date: Fri, 27 Sep 2019 18:09:42 +0100
Subject: [Koha-devel] kohastructure.sql : columns with COLLATE
In-Reply-To: <CABZfb=Vg4q2ONr+w3-aFcq0Wqtu870ufXpbNm2SRMfVrkZ2WnQ@mail.gmail.com>
References: <fec0f9aa-7ca9-8fd1-7f07-e2958d109f35@biblibre.com>
 <CABZfb=Vg4q2ONr+w3-aFcq0Wqtu870ufXpbNm2SRMfVrkZ2WnQ@mail.gmail.com>
Message-ID: <CAB7SL8DUR=bBTFx9LP8+X7Dtr+EqkX+-emkFse17Qp8B1JyA6g@mail.gmail.com>

I happened to spot the same only yesterday and wondered about doing such a
tidy up too..

I'd agree with Tomas, where the collate matches the table I'd drop it from
the column.. I didn't go ahead and do it yet as I didn't want to introduce
any pain for RMaints without discussing it first.


*Martin Renvoize*

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

Development Team Manager





*Phone:* +44 (0) 1483 378728

*Mobile:* +44 (0) 7725 985 636

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

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


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 Fri, 27 Sep 2019 at 18:06, Tomas Cohen Arazi <tomascohen at gmail.com>
wrote:

> I think it doesn't really make sense. There are cases in which the general
> table collation is utf8mb4_unicode_ci and some columns need utf8mb4_binary.
> I think those are the only meaningful ones.
>
> El vie., 27 sept. 2019 a las 11:27, Fridolin SOMERS (<
> fridolin.somers at biblibre.com>) escribió:
>
>> Hi
>>
>> I'm working on DB structure compare.
>> I note that in installer/data/mysql/kohastructure.sql, a few columns
>> define CHARACTER SET and/or COLLATE, with same values as table.
>>
>> Is this usefull or should we remove it ?
>>
>> $ grep  'COLLATE' installer/data/mysql/kohastructure.sql  | grep -v
>> ENGIN | grep 'utf8mb4_unicode_ci'
>>    `category_name` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL
>> DEFAULT '',
>>    `font` char(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT
>> NULL DEFAULT 'TR',
>>    `text_justify` char(1) CHARACTER SET utf8mb4 COLLATE
>> utf8mb4_unicode_ci NOT NULL DEFAULT 'L',
>>    `auto_renew_error` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT
>> NULL, -- automatic renewal error
>>    `auto_renew_error` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT
>> NULL, -- automatic renewal error
>>    `suppliers_report` MEDIUMTEXT COLLATE utf8mb4_unicode_ci, -- reports
>> received from suppliers
>>        entity varchar(16) COLLATE utf8mb4_unicode_ci NOT NULL,
>>        code varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL,
>>        lang varchar(25) COLLATE utf8mb4_unicode_ci NOT NULL, -- could be
>> a foreign key
>>        translation MEDIUMTEXT COLLATE utf8mb4_unicode_ci,
>>    `branchcode` varchar(10) CHARACTER SET utf8mb4 COLLATE
>> utf8mb4_unicode_ci DEFAULT NULL,
>>
>> --
>> Fridolin SOMERS <fridolin.somers at biblibre.com>
>> BibLibre, France - software and system maintainer
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> https://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 (http://theke.io)
> ✆ +54 9351 3513384
> GPG: B2F3C15F
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://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/20190927/e08eda7f/attachment-0001.html>

From martin.renvoize at ptfs-europe.com  Fri Sep 27 19:13:48 2019
From: martin.renvoize at ptfs-europe.com (Renvoize, Martin)
Date: Fri, 27 Sep 2019 18:13:48 +0100
Subject: [Koha-devel] A case against some uses of C4::Context->userenv
In-Reply-To: <CABZfb=UF295=-Y4iC3RmkMh4nj5=M9PfgrdWL5pnjk+jF2g1nA@mail.gmail.com>
References: <CABZfb=UF295=-Y4iC3RmkMh4nj5=M9PfgrdWL5pnjk+jF2g1nA@mail.gmail.com>
Message-ID: <CAB7SL8D+rjvW0HdCYj5pvJnnvVvkfTeBNW7+HGpiyJJrAWtOqQ@mail.gmail.com>

I generally agree here,  I'd rather explicitly pass things like this into
objects on instantiation and die if they're not present.. that way we catch
cases of missing environments early and as you state, userenv harks back
the CGI days and we should generally be moving forward and away from those
patterns in my opinion.


*Martin Renvoize*

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

Development Team Manager





*Phone:* +44 (0) 1483 378728

*Mobile:* +44 (0) 7725 985 636

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

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


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 Fri, 27 Sep 2019 at 17:42, Tomas Cohen Arazi <tomascohen at gmail.com>
wrote:

> Hi all, I've been looking at the 'Claims returned' work (awesome!) [1] and
> I've noticed a pattern we should, in my opinion, start avoiding and
> reverting.
>
> It is quite common to find uses of C4::Context->userenv in the Koha::*
> namespace, either as a plain requirement (if the borrowernumber is not set
> we bail out) or just as a fallback. I think it is wrong to expect such
> environment status in our logic. It complicates things in various ways. [2]
>
> It is done this way because:
> - We come from the CGI era, in which it made perfect sense
> - Cookie auth is well established on the UI
> - When migrating from C4:* into Koha:* it is easier to just keep the
> current behavior and then evolve.
>
> I propose we leave them out, and add as a parameter whatever we are
> expecting to find in the userenv hashref. That way we could use this new
> libs in the API (which is not cookie-only).
>
> Looking forward to hear your opinions
>
> [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14697
> [2] CLI scripts are using Koha::* libraries, and we then need to 'emulate'
> that userenv or even add code to detect we don't have a userenv.
>
> --
> Tomás Cohen Arazi
> Theke Solutions (http://theke.io)
> ✆ +54 9351 3513384
> GPG: B2F3C15F
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://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/20190927/e337c097/attachment.html>

From paul.a at navalmarinearchive.com  Sat Sep 28 01:50:16 2019
From: paul.a at navalmarinearchive.com (Paul A)
Date: Fri, 27 Sep 2019 19:50:16 -0400
Subject: [Koha-devel] kohastructure.sql : columns with COLLATE
In-Reply-To: <fec0f9aa-7ca9-8fd1-7f07-e2958d109f35@biblibre.com>
References: <fec0f9aa-7ca9-8fd1-7f07-e2958d109f35@biblibre.com>
Message-ID: <24951d50-338d-0471-cc49-76860299cff2@navalmarinearchive.com>

On 2019-09-27 10:27 a.m., Fridolin SOMERS wrote:
> Hi
> 
> I'm working on DB structure compare.
> I note that in installer/data/mysql/kohastructure.sql, a few columns 
> define CHARACTER SET and/or COLLATE, with same values as table.
> 
> Is this usefull or should we remove it ?

Might I assume that this is in a context of upgrade rather than new 
install? If not, the following is perhaps irrelevant.

In the "old days", (+/- 5 years ago, Debian 7, Ubuntu 14; MySQL 5.7 -- 
all "thereabouts"), my[sql].cnf in its various formats and paths used to 
include:
    # ensure charsets.
    character-set-server=utf8
    collation-server=utf8_general_ci

This has been dropped in more recent releases, corresponding to 
introduction dates of utf8mb4 (most importantly 3- to 4-bit encoding 
which can seriously impact some field lengths) -- core functionality is 
perhaps presumed.

Specificity may well be useful for 'international' and 'backwards 
compatibility' reasons -- both of which are important to Koha where 
admins may be very late in upgrading os/MySQL/Koha versions. The use of 
COLLATE with a specific CHARACTER SET should|could|might find (various 
find|sorting algorithms) existing, relevant data -- despite the fact 
that Koha appears to respect a system (Debian, Ubuntu) wide 'plain' utf8.

However, MySQL (8+) and InnoDB may not be totally aligned (I have no 
practical knowledge of MariaDB), and the char sets utf8, utf8mb4, 
utf8mb4_general_ci, utf8mb4_unicode_ci (maybe more) are an ongoing 
source of improvement and discussion.

Surely Koha should not remove this [not-neccessarily-redundant] back-stop.

Best -- Paul
> 
> $ grep  'COLLATE' installer/data/mysql/kohastructure.sql  | grep -v 
> ENGIN | grep 'utf8mb4_unicode_ci'
>    `category_name` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL 
> DEFAULT '',
>    `font` char(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT 
> NULL DEFAULT 'TR',
>    `text_justify` char(1) CHARACTER SET utf8mb4 COLLATE 
> utf8mb4_unicode_ci NOT NULL DEFAULT 'L',
>    `auto_renew_error` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT 
> NULL, -- automatic renewal error
>    `auto_renew_error` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT 
> NULL, -- automatic renewal error
>    `suppliers_report` MEDIUMTEXT COLLATE utf8mb4_unicode_ci, -- reports 
> received from suppliers
>        entity varchar(16) COLLATE utf8mb4_unicode_ci NOT NULL,
>        code varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL,
>        lang varchar(25) COLLATE utf8mb4_unicode_ci NOT NULL, -- could be 
> a foreign key
>        translation MEDIUMTEXT COLLATE utf8mb4_unicode_ci,
>    `branchcode` varchar(10) CHARACTER SET utf8mb4 COLLATE 
> utf8mb4_unicode_ci DEFAULT NULL,
> 


From M.de.Rooy at rijksmuseum.nl  Sat Sep 28 10:29:17 2019
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Sat, 28 Sep 2019 08:29:17 +0000
Subject: [Koha-devel] A case against some uses of C4::Context->userenv
In-Reply-To: <CAB7SL8D+rjvW0HdCYj5pvJnnvVvkfTeBNW7+HGpiyJJrAWtOqQ@mail.gmail.com>
References: <CABZfb=UF295=-Y4iC3RmkMh4nj5=M9PfgrdWL5pnjk+jF2g1nA@mail.gmail.com>,
 <CAB7SL8D+rjvW0HdCYj5pvJnnvVvkfTeBNW7+HGpiyJJrAWtOqQ@mail.gmail.com>
Message-ID: <AM6PR05MB5976FCF30D0AA553E8012EA2CE800@AM6PR05MB5976.eurprd05.prod.outlook.com>

Sounds good to me. But as you know, refactoring a large codebase is a tedious process.

________________________________

 
 

​Museumstraat 1
Postbus 74888
1070 DN Amsterdam
Rijksmuseum.nl
​
​Nu te zien:
​​12x Erwin Olaf
​Louise Bourgeois in de Rijksmuseumtuinen
​Operatie Nachtwacht
​
​T/m 18 jaar gratis
  
 Please think before you print
Van: Koha-devel <koha-devel-bounces at lists.koha-community.org> namens Renvoize, Martin <martin.renvoize at ptfs-europe.com>
Verzonden: vrijdag 27 september 2019 19:13
Aan: Tomas Cohen Arazi <tomascohen at gmail.com>
CC: koha-devel <koha-devel at lists.koha-community.org>
Onderwerp: Re: [Koha-devel] A case against some uses of C4::Context->userenv

I generally agree here,  I'd rather explicitly pass things like this into objects on instantiation and die if they're not present.. that way we catch cases of missing environments early and as you state, userenv harks back the CGI days and we should generally be moving forward and away from those patterns in my opinion.



Martin Renvoize

[https://www.ptfs-europe.com/wp-content/uploads/2018/10/ptfs-logo-full-email-sig.png]<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ptfs-europe.com&data=02%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C048e6e0d082f4f8a8ae608d7436e21f6%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637052012606694897&sdata=qo0dpMjlegzzDhLI4meNlpDyStDamMNZeqx2GeArI%2Fo%3D&reserved=0>

Development Team Manager





Phone: +44 (0) 1483 378728

Mobile: +44 (0) 7725 985 636

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

Fax: +44 (0) 800 756 6384


www.ptfs-europe.com<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ptfs-europe.com&data=02%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C048e6e0d082f4f8a8ae608d7436e21f6%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637052012606694897&sdata=qo0dpMjlegzzDhLI4meNlpDyStDamMNZeqx2GeArI%2Fo%3D&reserved=0>







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 Fri, 27 Sep 2019 at 17:42, Tomas Cohen Arazi <tomascohen at gmail.com<mailto:tomascohen at gmail.com>> wrote:
Hi all, I've been looking at the 'Claims returned' work (awesome!) [1] and I've noticed a pattern we should, in my opinion, start avoiding and reverting.

It is quite common to find uses of C4::Context->userenv in the Koha::* namespace, either as a plain requirement (if the borrowernumber is not set we bail out) or just as a fallback. I think it is wrong to expect such environment status in our logic. It complicates things in various ways. [2]

It is done this way because:
- We come from the CGI era, in which it made perfect sense
- Cookie auth is well established on the UI
- When migrating from C4:* into Koha:* it is easier to just keep the current behavior and then evolve.

I propose we leave them out, and add as a parameter whatever we are expecting to find in the userenv hashref. That way we could use this new libs in the API (which is not cookie-only).

Looking forward to hear your opinions

[1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14697<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.koha-community.org%2Fbugzilla3%2Fshow_bug.cgi%3Fid%3D14697&data=02%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C048e6e0d082f4f8a8ae608d7436e21f6%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637052012606704891&sdata=pEj0U2nGAHpCTqEQNur9R8XCRcxdggKALtPmohPjd2c%3D&reserved=0>
[2] CLI scripts are using Koha::* libraries, and we then need to 'emulate' that userenv or even add code to detect we don't have a userenv.

--
Tomás Cohen Arazi
Theke Solutions (http://theke.io<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftheke.io%2F&data=02%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C048e6e0d082f4f8a8ae608d7436e21f6%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637052012606704891&sdata=rJ7Wq1rK256YA6BTdSophwfAQOYL%2FEd2qrBSu4LdrjM%3D&reserved=0>)
✆ +54 9351 3513384
GPG: B2F3C15F
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org<mailto:Koha-devel at lists.koha-community.org>
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.koha-community.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fkoha-devel&data=02%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C048e6e0d082f4f8a8ae608d7436e21f6%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637052012606714888&sdata=MSCs0c6X61QWoRbeQQDmIgYfkt1wMhj2CVDIERhlJ%2BY%3D&reserved=0>
website : http://www.koha-community.org/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.koha-community.org%2F&data=02%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C048e6e0d082f4f8a8ae608d7436e21f6%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637052012606714888&sdata=Ysg8%2F7hSlFWQxBXKOEIaVPQehnFiW4tTzs%2FR2613YPY%3D&reserved=0>
git : http://git.koha-community.org/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.koha-community.org%2F&data=02%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C048e6e0d082f4f8a8ae608d7436e21f6%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637052012606724882&sdata=P%2Fr5B5nQI7tlAw2CyWeDR9Yq2KU%2Fmvd8UMmP7D5jbU4%3D&reserved=0>
bugs : http://bugs.koha-community.org/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbugs.koha-community.org%2F&data=02%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C048e6e0d082f4f8a8ae608d7436e21f6%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637052012606724882&sdata=hH4KAhh61qM6lGWmuqvQfhPhiAEoJIQBmVieS%2BrfSR8%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20190928/a185606e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image466886.png
Type: image/png
Size: 2974 bytes
Desc: image466886.png
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20190928/a185606e/attachment-0001.png>

From kohanews at gmail.com  Sun Sep 29 02:42:13 2019
From: kohanews at gmail.com (Koha Newsletter)
Date: Sat, 28 Sep 2019 17:42:13 -0700
Subject: [Koha-devel] Koha Newsletter: September 2019
Message-ID: <5B742103-4462-4477-A360-A5357C056F48@gmail.com>

The Koha Community Newsletter for September 2019 is here:
https://koha-community.org/koha-community-newsletter-september-2019/

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.

-- 
Chad Roseburg
Editor, Koha Community Newsletter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20190928/2f554d16/attachment.html>

From dcook at prosentient.com.au  Mon Sep 30 02:03:03 2019
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Mon, 30 Sep 2019 10:03:03 +1000
Subject: [Koha-devel] A case against some uses of C4::Context->userenv
In-Reply-To: <CAB7SL8D+rjvW0HdCYj5pvJnnvVvkfTeBNW7+HGpiyJJrAWtOqQ@mail.gmail.com>
References: <CABZfb=UF295=-Y4iC3RmkMh4nj5=M9PfgrdWL5pnjk+jF2g1nA@mail.gmail.com>
 <CAB7SL8D+rjvW0HdCYj5pvJnnvVvkfTeBNW7+HGpiyJJrAWtOqQ@mail.gmail.com>
Message-ID: <00cb01d57722$6dcc8110$49658330$@prosentient.com.au>

Totally agree too. Also makes unit testing a million times easier. 

 

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 <koha-devel-bounces at lists.koha-community.org> On Behalf Of Renvoize, Martin
Sent: Saturday, 28 September 2019 3:14 AM
To: Tomas Cohen Arazi <tomascohen at gmail.com>
Cc: koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] A case against some uses of C4::Context->userenv

 

I generally agree here,  I'd rather explicitly pass things like this into objects on instantiation and die if they're not present.. that way we catch cases of missing environments early and as you state, userenv harks back the CGI days and we should generally be moving forward and away from those patterns in my opinion.

 




	

 


Martin Renvoize

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


Development Team Manager


 


 


Phone: +44 (0) 1483 378728

Mobile: +44 (0) 7725 985 636


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

Fax: +44 (0) 800 756 6384

	
 <https://www.ptfs-europe.com> 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 Fri, 27 Sep 2019 at 17:42, Tomas Cohen Arazi <tomascohen at gmail.com <mailto:tomascohen at gmail.com> > wrote:

Hi all, I've been looking at the 'Claims returned' work (awesome!) [1] and I've noticed a pattern we should, in my opinion, start avoiding and reverting.

 

It is quite common to find uses of C4::Context->userenv in the Koha::* namespace, either as a plain requirement (if the borrowernumber is not set we bail out) or just as a fallback. I think it is wrong to expect such environment status in our logic. It complicates things in various ways. [2]

 

It is done this way because:

- We come from the CGI era, in which it made perfect sense

- Cookie auth is well established on the UI

- When migrating from C4:* into Koha:* it is easier to just keep the current behavior and then evolve.

 

I propose we leave them out, and add as a parameter whatever we are expecting to find in the userenv hashref. That way we could use this new libs in the API (which is not cookie-only).

 

Looking forward to hear your opinions 

 

[1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14697

[2] CLI scripts are using Koha::* libraries, and we then need to 'emulate' that userenv or even add code to detect we don't have a userenv.


 

-- 

Tomás Cohen Arazi

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

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
https://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/20190930/80ce3901/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20190930/80ce3901/attachment.sig>

From pasi.kallinen at koha-suomi.fi  Mon Sep 30 06:39:00 2019
From: pasi.kallinen at koha-suomi.fi (Pasi Kallinen)
Date: Mon, 30 Sep 2019 06:39:00 +0200 (CEST)
Subject: [Koha-devel] kohastructure.sql : columns with COLLATE
In-Reply-To: <CABZfb=Vg4q2ONr+w3-aFcq0Wqtu870ufXpbNm2SRMfVrkZ2WnQ@mail.gmail.com>
References: <fec0f9aa-7ca9-8fd1-7f07-e2958d109f35@biblibre.com>
 <CABZfb=Vg4q2ONr+w3-aFcq0Wqtu870ufXpbNm2SRMfVrkZ2WnQ@mail.gmail.com>
Message-ID: <Lq-SiZI--3-1@koha-suomi.fi>


Also see https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20269 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20269>

-- 
Pasi Kallinen
Koha-Suomi oy
+358 400 174 235



Sep 27, 2019, 20:05 by tomascohen at gmail.com:

> I think it doesn't really make sense. There are cases in which the general table collation is utf8mb4_unicode_ci and some columns need utf8mb4_binary. I think those are the only meaningful ones.
>
> El vie., 27 sept. 2019 a las 11:27, Fridolin SOMERS (<> fridolin.somers at biblibre.com <mailto:fridolin.somers at biblibre.com>> >) escribió:
>
>> Hi
>>  
>>  I'm working on DB structure compare.
>>  I note that in installer/data/mysql/kohastructure.sql, a few columns 
>>  define CHARACTER SET and/or COLLATE, with same values as table.
>>  
>>  Is this usefull or should we remove it ?
>>  
>>  $ grep  'COLLATE' installer/data/mysql/kohastructure.sql  | grep -v 
>>  ENGIN | grep 'utf8mb4_unicode_ci'
>>     `category_name` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL 
>>  DEFAULT '',
>>     `font` char(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT 
>>  NULL DEFAULT 'TR',
>>     `text_justify` char(1) CHARACTER SET utf8mb4 COLLATE 
>>  utf8mb4_unicode_ci NOT NULL DEFAULT 'L',
>>     `auto_renew_error` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT 
>>  NULL, -- automatic renewal error
>>     `auto_renew_error` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT 
>>  NULL, -- automatic renewal error
>>     `suppliers_report` MEDIUMTEXT COLLATE utf8mb4_unicode_ci, -- reports 
>>  received from suppliers
>>         entity varchar(16) COLLATE utf8mb4_unicode_ci NOT NULL,
>>         code varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL,
>>         lang varchar(25) COLLATE utf8mb4_unicode_ci NOT NULL, -- could be 
>>  a foreign key
>>         translation MEDIUMTEXT COLLATE utf8mb4_unicode_ci,
>>     `branchcode` varchar(10) CHARACTER SET utf8mb4 COLLATE 
>>  utf8mb4_unicode_ci DEFAULT NULL,
>>  
>>  -- 
>>  Fridolin SOMERS <>> fridolin.somers at biblibre.com <mailto:fridolin.somers at biblibre.com>>> >
>>  BibLibre, France - software and system maintainer
>>  _______________________________________________
>>  Koha-devel mailing list
>>  >> Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org>
>>  >> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel <https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel>
>>  website : >> http://www.koha-community.org/ <http://www.koha-community.org/>
>>  git : >> http://git.koha-community.org/ <http://git.koha-community.org/>
>>  bugs : >> http://bugs.koha-community.org/ <http://bugs.koha-community.org/>
>>
>
>
> -- 
> Tomás Cohen Arazi
> Theke Solutions (> http://theke.io <http://theke.io/>> )
> ✆ +54 9351 3513384
> GPG: B2F3C15F
>


From michael.hafen at washk12.org  Mon Sep 30 19:22:17 2019
From: michael.hafen at washk12.org (Michael Hafen)
Date: Mon, 30 Sep 2019 11:22:17 -0600
Subject: [Koha-devel] A case against some uses of C4::Context->userenv
In-Reply-To: <00cb01d57722$6dcc8110$49658330$@prosentient.com.au>
References: <CABZfb=UF295=-Y4iC3RmkMh4nj5=M9PfgrdWL5pnjk+jF2g1nA@mail.gmail.com>
 <CAB7SL8D+rjvW0HdCYj5pvJnnvVvkfTeBNW7+HGpiyJJrAWtOqQ@mail.gmail.com>
 <00cb01d57722$6dcc8110$49658330$@prosentient.com.au>
Message-ID: <CAAh7Ud=cCrdPU4pJMPnUZPLAthhOP3AF2Zq+gOcVDjXqJodbPg@mail.gmail.com>

What about the 'Search My Library First' and 'Independent Branches'
settings?  Those are dependent right now on reading the users branch from
userenv.  I'm not familiar enough with the code base to know where else
those settings would get the users branch; is it kept in a cookie?

On Sun, Sep 29, 2019 at 6:03 PM <dcook at prosentient.com.au> wrote:

> Totally agree too. Also makes unit testing a million times easier.
>
>
>
> 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 <koha-devel-bounces at lists.koha-community.org> *On
> Behalf Of *Renvoize, Martin
> *Sent:* Saturday, 28 September 2019 3:14 AM
> *To:* Tomas Cohen Arazi <tomascohen at gmail.com>
> *Cc:* koha-devel <koha-devel at lists.koha-community.org>
> *Subject:* Re: [Koha-devel] A case against some uses of
> C4::Context->userenv
>
>
>
> I generally agree here,  I'd rather explicitly pass things like this into
> objects on instantiation and die if they're not present.. that way we catch
> cases of missing environments early and as you state, userenv harks back
> the CGI days and we should generally be moving forward and away from those
> patterns in my opinion.
>
>
>
>
>
>
> *Martin Renvoize*
>
> <https://www.ptfs-europe.com/>
>
> Development Team Manager
>
>
>
>
>
> *Phone:* +44 (0) 1483 378728
>
> *Mobile:* +44 (0) 7725 985 636
>
> *Email:* martin.renvoize at ptfs-europe.com
>
> *Fax:* +44 (0) 800 756 6384
>
> 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 Fri, 27 Sep 2019 at 17:42, Tomas Cohen Arazi <tomascohen at gmail.com>
> wrote:
>
> Hi all, I've been looking at the 'Claims returned' work (awesome!) [1] and
> I've noticed a pattern we should, in my opinion, start avoiding and
> reverting.
>
>
>
> It is quite common to find uses of C4::Context->userenv in the Koha::*
> namespace, either as a plain requirement (if the borrowernumber is not set
> we bail out) or just as a fallback. I think it is wrong to expect such
> environment status in our logic. It complicates things in various ways. [2]
>
>
>
> It is done this way because:
>
> - We come from the CGI era, in which it made perfect sense
>
> - Cookie auth is well established on the UI
>
> - When migrating from C4:* into Koha:* it is easier to just keep the
> current behavior and then evolve.
>
>
>
> I propose we leave them out, and add as a parameter whatever we are
> expecting to find in the userenv hashref. That way we could use this new
> libs in the API (which is not cookie-only).
>
>
>
> Looking forward to hear your opinions
>
>
>
> [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14697
>
> [2] CLI scripts are using Koha::* libraries, and we then need to 'emulate'
> that userenv or even add code to detect we don't have a userenv.
>
>
>
> --
>
> Tomás Cohen Arazi
>
> Theke Solutions (http://theke.io)
> ✆ +54 9351 3513384
> GPG: B2F3C15F
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://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
> https://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/
>


-- 
Michael Hafen
Washington County School District Technology Department
Systems Analyst
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20190930/1e006185/attachment.html>