From kohanews at gmail.com Sat May 1 00:25:44 2021 From: kohanews at gmail.com (Koha Newsletter) Date: Sat, 1 May 2021 00:25:44 +0200 Subject: [Koha-devel] Koha Community Newsletter: April 2021 Message-ID: The Koha Community Newsletter for April 2021 is here: * https://koha-community.org/koha-community-newsletter-april-2021/ Many thanks to everyone who submitted articles and news to last month's newsletter! Please feel free to email me with any corrections or suggestions. -- Michael Kuhn Editor, Koha Community Newsletter -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Sat May 1 14:53:14 2021 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Sat, 1 May 2021 09:53:14 -0300 Subject: [Koha-devel] Why is config ($KOHA_CONF) stored in memcached ? In-Reply-To: <2c158374-dc30-2bc6-09fa-1ffd91aedd47@biblibre.com> References: <2c158374-dc30-2bc6-09fa-1ffd91aedd47@biblibre.com> Message-ID: I vote for fixing it so the file is only hit the first time. El vie, 30 abr 2021 a las 14:19, Julian Maurice (< julian.maurice at biblibre.com>) escribió: > Hi all, > > Maybe it's a dumb question, but I don't understand why the config is > stored in memcached as: > - memcached server address is in this config, so we need to read > $KOHA_CONF file first in order to connect to memcached server > - config is kept in memory forever ($C4::Context::context), so we > shouldn't need the cache once starman has started. > > If you add a warning in Koha::Config::read_from_file, you'll see that > the file is read 3 times per worker, even when the config already exist > in cache (it's read 4 times when the cache is empty). > It's read each time we call Koha::Cache->new (+ in C4::Context->new if > the cache is empty) > > Shouldn't we read the file only in C4::Context->new (without using > cache), and make Koha::Cache use C4::Context->config instead ? > > -- > Julian Maurice > BibLibre > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://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: From julian.maurice at biblibre.com Sun May 2 14:52:24 2021 From: julian.maurice at biblibre.com (Julian Maurice) Date: Sun, 2 May 2021 14:52:24 +0200 Subject: [Koha-devel] Why is config ($KOHA_CONF) stored in memcached ? In-Reply-To: References: <2c158374-dc30-2bc6-09fa-1ffd91aedd47@biblibre.com> Message-ID: <7c3c218b-e2d5-d03b-3095-ff297ec71e7d@biblibre.com> Patch is ready to be tested at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28276 ;) Le 01/05/2021 à 14:53, Tomas Cohen Arazi a écrit : > I vote for fixing it so the file is only hit the first time. > > El vie, 30 abr 2021 a las 14:19, Julian Maurice > (>) > escribió: > > Hi all, > > Maybe it's a dumb question, but I don't understand why the config is > stored in memcached as: > - memcached server address is in this config, so we need to read > $KOHA_CONF file first in order to connect to memcached server > - config is kept in memory forever ($C4::Context::context), so we > shouldn't need the cache once starman has started. > > If you add a warning in Koha::Config::read_from_file, you'll see that > the file is read 3 times per worker, even when the config already exist > in cache (it's read 4 times when the cache is empty). > It's read each time we call Koha::Cache->new (+ in C4::Context->new if > the cache is empty) > > Shouldn't we read the file only in C4::Context->new (without using > cache), and make Koha::Cache use C4::Context->config instead ? > > -- > Julian Maurice > BibLibre > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > > website : https://www.koha-community.org/ > > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > > > > > -- > Tomás Cohen Arazi > Theke Solutions (http://theke.io ) > ✆ +54 9351 3513384 > GPG: B2F3C15F -- Julian Maurice BibLibre From dcook at prosentient.com.au Mon May 3 01:28:45 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Mon, 3 May 2021 09:28:45 +1000 Subject: [Koha-devel] Why is config ($KOHA_CONF) stored in memcached ? In-Reply-To: References: <2c158374-dc30-2bc6-09fa-1ffd91aedd47@biblibre.com> Message-ID: <021501d73faa$e53fc1b0$afbf4510$@prosentient.com.au> Sounds good to me. I don’t recall how long the Koha conf has been stored in Memcached, but it would have benefited CGI Koha since every HTTP request would’ve done a disk read. But I think we’ve pretty much moved on from CGI now, so +1 to only reading koha-conf.xml once at startup. This change should also make it easier to make changes to Koha. It drives me a little bit crazy that I have to manually clear Memcached every time I make a change to koha-conf.xml… David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Tomas Cohen Arazi Sent: Saturday, 1 May 2021 10:53 PM To: Julian Maurice Cc: koha-devel Subject: Re: [Koha-devel] Why is config ($KOHA_CONF) stored in memcached ? I vote for fixing it so the file is only hit the first time. El vie, 30 abr 2021 a las 14:19, Julian Maurice ( >) escribió: Hi all, Maybe it's a dumb question, but I don't understand why the config is stored in memcached as: - memcached server address is in this config, so we need to read $KOHA_CONF file first in order to connect to memcached server - config is kept in memory forever ($C4::Context::context), so we shouldn't need the cache once starman has started. If you add a warning in Koha::Config::read_from_file, you'll see that the file is read 3 times per worker, even when the config already exist in cache (it's read 4 times when the cache is empty). It's read each time we call Koha::Cache->new (+ in C4::Context->new if the cache is empty) Shouldn't we read the file only in C4::Context->new (without using cache), and make Koha::Cache use C4::Context->config instead ? -- Julian Maurice BibLibre _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://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: From dcook at prosentient.com.au Mon May 3 07:00:37 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Mon, 3 May 2021 15:00:37 +1000 Subject: [Koha-devel] HTTP/HTTPS cheme in Base Path in API documentation Message-ID: <027901d73fd9$4218be90$c64a3bb0$@prosentient.com.au> Hi all, I just noticed on a HTTPS site that the Base URL at /api/v1/.html was listed as HTTP rather than HTTPS. Looking at Mojolicious::Plugin::OpenAPI, it seems that it's hard-coded to HTTP *if* a scheme isn't specified in the spec: https://github.com/jhthorsen/mojolicious-plugin-openapi/blob/master/lib/Mojo licious/Plugin/OpenAPI/SpecRenderer.pm#L406 Looking at https://swagger.io/docs/specification/2-0/api-host-and-base-path/, we could be setting "schemes" there. I'm not 100% sure what we should do here. Maybe nothing. But it just seem unfortunate to be showing a HTTP link on a HTTPS page especially for an API... David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From julian.maurice at biblibre.com Mon May 3 09:06:29 2021 From: julian.maurice at biblibre.com (Julian Maurice) Date: Mon, 3 May 2021 09:06:29 +0200 Subject: [Koha-devel] Why is config ($KOHA_CONF) stored in memcached ? In-Reply-To: <7c3c218b-e2d5-d03b-3095-ff297ec71e7d@biblibre.com> References: <2c158374-dc30-2bc6-09fa-1ffd91aedd47@biblibre.com> <7c3c218b-e2d5-d03b-3095-ff297ec71e7d@biblibre.com> Message-ID: If you're interested there is also bug 28278 that divides by 3 the time needed to parse $KOHA_CONF: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28278 Le 02/05/2021 à 14:52, Julian Maurice a écrit : > Patch is ready to be tested at > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28276 ;) > > Le 01/05/2021 à 14:53, Tomas Cohen Arazi a écrit : >> I vote for fixing it so the file is only hit the first time. >> >> El vie, 30 abr 2021 a las 14:19, Julian Maurice >> (>) >> escribió: >> >>     Hi all, >> >>     Maybe it's a dumb question, but I don't understand why the config is >>     stored in memcached as: >>     - memcached server address is in this config, so we need to read >>     $KOHA_CONF file first in order to connect to memcached server >>     - config is kept in memory forever ($C4::Context::context), so we >>     shouldn't need the cache once starman has started. >> >>     If you add a warning in Koha::Config::read_from_file, you'll see that >>     the file is read 3 times per worker, even when the config already >> exist >>     in cache (it's read 4 times when the cache is empty). >>     It's read each time we call Koha::Cache->new (+ in >> C4::Context->new if >>     the cache is empty) >> >>     Shouldn't we read the file only in C4::Context->new (without using >>     cache), and make Koha::Cache use C4::Context->config instead ? >> >>     --     Julian Maurice >>     BibLibre >>     _______________________________________________ >>     Koha-devel mailing list >>     Koha-devel at lists.koha-community.org >>     >>     https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> >> >>     website : https://www.koha-community.org/ >>     >>     git : https://git.koha-community.org/ >> >>     bugs : https://bugs.koha-community.org/ >>     >> >> >> >> -- >> Tomás Cohen Arazi >> Theke Solutions (http://theke.io ) >> ✆ +54 9351 3513384 >> GPG: B2F3C15F > -- Julian Maurice BibLibre From victor at tuxayo.net Mon May 3 17:45:16 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Mon, 3 May 2021 17:45:16 +0200 Subject: [Koha-devel] Elasticsearch vs OpenSearch In-Reply-To: References: <049201d73256$b25a7d50$170f77f0$@prosentient.com.au> Message-ID: <2ba45522-9de1-d469-9ee3-681f0ec8a487@tuxayo.net> Hi :) Found another legal analysis that contradicts the first one: https://writing.kemitchell.com/2021/01/20/Righteous-Expedient-Wrong.html Even if contradictory, that still helps to understand the situation. Divergence still means something about the eventual risks. Some thoughts after reading: "SaaS capture”, “Amazon problem”, “Google problem” are legitimate concerns. But this controversy shows how hard it is to address it. Even if the copyleft doesn't affect Koha. It seems clear that it affects management services (what is the extent of that?). So what about if a hosting management tool is under a copyleft license? IIUC it can't be released under the SSPL. So that would force to only use permissive licensed management tools. So it's not a legal blocker but that restrict possibilities. And actually leads to a loss of freedom on these tools because copyleft software help about that. Some non-Koha thoughts: 1. Does having the hosting management tools of Amazon or Google or Microsoft would really help not them having a quasi monopolistic share on the hosting of databases et other tools? (public interest PoV) Well actually it's to have them buy the version with the other license. 2. Do ElasticSearch actually lacks money to maintain the same level of work on the ES stack and give the investors a reasonable return of investment? (accounting that it was a risky one so the return should be more than the average) As for the second part, there is actually no limit on the ROI (imagine if loans worked like that, lol), especially with venture capital. So there can be doubt on the legitimacy of the additional need of revenue. Cheers, -- Victor Grousset/tuxayo From dcook at prosentient.com.au Tue May 4 05:35:23 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 4 May 2021 13:35:23 +1000 Subject: [Koha-devel] Why is config ($KOHA_CONF) stored in memcached ? In-Reply-To: References: <2c158374-dc30-2bc6-09fa-1ffd91aedd47@biblibre.com> <7c3c218b-e2d5-d03b-3095-ff297ec71e7d@biblibre.com> Message-ID: <042101d74096$843ef6f0$8cbce4d0$@prosentient.com.au> Oh I am very interested. I've been wanting to get rid of XML::Simple for many years, and this would be a huge step forward. I'll have to review this sometime... David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Koha-devel On Behalf Of Julian Maurice Sent: Monday, 3 May 2021 5:06 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Why is config ($KOHA_CONF) stored in memcached ? If you're interested there is also bug 28278 that divides by 3 the time needed to parse $KOHA_CONF: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28278 Le 02/05/2021 à 14:52, Julian Maurice a écrit : > Patch is ready to be tested at > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28276 ;) > > Le 01/05/2021 à 14:53, Tomas Cohen Arazi a écrit : >> I vote for fixing it so the file is only hit the first time. >> >> El vie, 30 abr 2021 a las 14:19, Julian Maurice >> (>) >> escribió: >> >> Hi all, >> >> Maybe it's a dumb question, but I don't understand why the config >> is >> stored in memcached as: >> - memcached server address is in this config, so we need to read >> $KOHA_CONF file first in order to connect to memcached server >> - config is kept in memory forever ($C4::Context::context), so we >> shouldn't need the cache once starman has started. >> >> If you add a warning in Koha::Config::read_from_file, you'll see >> that >> the file is read 3 times per worker, even when the config already >> exist >> in cache (it's read 4 times when the cache is empty). >> It's read each time we call Koha::Cache->new (+ in >> C4::Context->new if >> the cache is empty) >> >> Shouldn't we read the file only in C4::Context->new (without >> using >> cache), and make Koha::Cache use C4::Context->config instead ? >> >> -- Julian Maurice >> BibLibre >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> >> >> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> >> > > >> website : https://www.koha-community.org/ >> >> git : https://git.koha-community.org/ >> >> bugs : https://bugs.koha-community.org/ >> >> >> >> >> -- >> Tomás Cohen Arazi >> Theke Solutions (http://theke.io ) ✆ +54 9351 >> 3513384 >> GPG: B2F3C15F > -- Julian Maurice BibLibre _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ From dcook at prosentient.com.au Wed May 5 06:07:11 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 5 May 2021 14:07:11 +1000 Subject: [Koha-devel] Embedding JSON data in HTML Message-ID: <05a501d74164$1f87af80$5e970e80$@prosentient.com.au> Hi all, I was just reflecting on bugs like https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26942 and reviewing https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script when I saw the following method for embedding JSON in HTML: I thought that was neat. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Thu May 6 16:28:07 2021 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Thu, 6 May 2021 11:28:07 -0300 Subject: [Koha-devel] Embedding JSON data in HTML In-Reply-To: <05a501d74164$1f87af80$5e970e80$@prosentient.com.au> References: <05a501d74164$1f87af80$5e970e80$@prosentient.com.au> Message-ID: Nice finding, David. I've come across that in the context of Koha and Template::Toolkit, and did something similar, using a data- attribute. I used [% USE JSON.Escape %] to escape the data that comes from Perl. Here, I set the data structure to a data-pickup-locations attribute: https://gitlab.com/thekesolutions/Koha/-/commit/8b63154b866863aae6ac981b37c98864cd8875f4#f9b348ee995ab14b7c8a47e5ef2b7fe07838ec38_811_822 And then I use it: https://gitlab.com/thekesolutions/Koha/-/commit/8b63154b866863aae6ac981b37c98864cd8875f4#f9b348ee995ab14b7c8a47e5ef2b7fe07838ec38_1245_1274 Best regards El mié, 5 may 2021 a las 1:07, escribió: > Hi all, > > > > I was just reflecting on bugs like > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26942 and > reviewing https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script > when I saw the following method for embedding JSON in HTML: > > > > > > > > > > > > > > > > I thought that was neat. > > > > David Cook > > Software Engineer > > Prosentient Systems > > Suite 7.03 > > 6a Glen St > > Milsons Point NSW 2061 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://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: From fridolin.somers at biblibre.com Fri May 7 09:17:58 2021 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Fri, 7 May 2021 09:17:58 +0200 Subject: [Koha-devel] TT loop count VS size Message-ID: Hi community, I've been on a mindblowing search on a template error :D I was thinking that "loop.count" was wrong for testing if loop is not empty, the method is "loop.size". See doc http://template-toolkit.org/docs/manual/Directives.html#section_FOREACH Looks like we use both actually : > git grep 'IF.*\.count ' origin/master | wc -l 602 > git grep 'IF.*\.size ' origin/master | wc -l 1636 So using count seems to work because it starts with 1. But in my opinion it is a wrong call. We can see for example : Images ([% localimages.count || 0 | html %]) This is wrong no ? Should be create a coding guideline ? -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From jonathan.druart at bugs.koha-community.org Fri May 7 09:57:31 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Fri, 7 May 2021 09:57:31 +0200 Subject: [Koha-devel] TT loop count VS size In-Reply-To: References: Message-ID: You should grep "loop.count", not ".count" Most of the count you have with your regex is coming from koha_objects->count Le ven. 7 mai 2021 à 09:17, Fridolin SOMERS a écrit : > Hi community, > > I've been on a mindblowing search on a template error :D > > I was thinking that "loop.count" was wrong for testing if loop is not > empty, the method is "loop.size". > > See doc > http://template-toolkit.org/docs/manual/Directives.html#section_FOREACH > > Looks like we use both actually : > > git grep 'IF.*\.count ' origin/master | wc -l > 602 > > git grep 'IF.*\.size ' origin/master | wc -l > 1636 > > So using count seems to work because it starts with 1. > But in my opinion it is a wrong call. > > We can see for example : > Images ([% localimages.count || 0 | html %]) > This is wrong no ? > > Should be create a coding guideline ? > > -- > Fridolin SOMERS > Software and system maintainer 🦄 > BibLibre, France > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor at tuxayo.net Sat May 8 23:11:01 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Sat, 8 May 2021 23:11:01 +0200 Subject: [Koha-devel] Help needed to test an i-tiva bug (no prior knowledge required) Message-ID: <39e527d6-3a19-2581-7bf4-a5f94697f6fe@tuxayo.net> Hi :) Here is a bug that I tested and checked for QA. Now a test from someone else is needed. Here is the ticket: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27562 Here is the test plan: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27562#c4 Here are instructions to setup i-tiva: https://wiki.koha-community.org/wiki/External_Integration#i-tiva I'll gladly guide you via email or tchat (nickname: tuxayo) Cheers, -- Victor Grousset/tuxayo From dcook at prosentient.com.au Mon May 10 01:50:22 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Mon, 10 May 2021 09:50:22 +1000 Subject: [Koha-devel] TT loop count VS size In-Reply-To: References: Message-ID: <00a601d7452e$135c7ec0$3a157c40$@prosentient.com.au> I was going to say… I’d never even heard of the “count” call in TT. Looking at http://template-toolkit.org/docs/manual/VMethods.html, it’s not a method for a data structure. Looking at http://template-toolkit.org/docs/manual/Directives.html#section_FOREACH, it’s only a method of the “loop” variable. grep -R "loop\.count" * | wc -l 86 What’s the actual problem being observed? David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Jonathan Druart Sent: Friday, 7 May 2021 5:58 PM To: Fridolin SOMERS Cc: koha-devel Subject: Re: [Koha-devel] TT loop count VS size You should grep "loop.count", not ".count" Most of the count you have with your regex is coming from koha_objects->count Le ven. 7 mai 2021 à 09:17, Fridolin SOMERS > a écrit : Hi community, I've been on a mindblowing search on a template error :D I was thinking that "loop.count" was wrong for testing if loop is not empty, the method is "loop.size". See doc http://template-toolkit.org/docs/manual/Directives.html#section_FOREACH Looks like we use both actually : > git grep 'IF.*\.count ' origin/master | wc -l 602 > git grep 'IF.*\.size ' origin/master | wc -l 1636 So using count seems to work because it starts with 1. But in my opinion it is a wrong call. We can see for example : Images ([% localimages.count || 0 | html %]) This is wrong no ? Should be create a coding guideline ? -- Fridolin SOMERS > Software and system maintainer 🦄 BibLibre, France _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Mon May 10 03:14:06 2021 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Sun, 9 May 2021 22:14:06 -0300 Subject: [Koha-devel] TT loop count VS size In-Reply-To: <00a601d7452e$135c7ec0$3a157c40$@prosentient.com.au> References: <00a601d7452e$135c7ec0$3a157c40$@prosentient.com.au> Message-ID: That's because .count is a Koha::Objects method. El dom., 9 may. 2021 20:50, escribió: > I was going to say… I’d never even heard of the “count” call in TT. > Looking at http://template-toolkit.org/docs/manual/VMethods.html, it’s > not a method for a data structure. Looking at > http://template-toolkit.org/docs/manual/Directives.html#section_FOREACH, > it’s only a method of the “loop” variable. > > > > grep -R "loop\.count" * | wc -l > > 86 > > > > What’s the actual problem being observed? > > > > David Cook > > Software Engineer > > Prosentient Systems > > Suite 7.03 > > 6a Glen St > > Milsons Point NSW 2061 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > > *From:* Koha-devel *On > Behalf Of *Jonathan Druart > *Sent:* Friday, 7 May 2021 5:58 PM > *To:* Fridolin SOMERS > *Cc:* koha-devel > *Subject:* Re: [Koha-devel] TT loop count VS size > > > > You should grep "loop.count", not ".count" > > Most of the count you have with your regex is coming from > koha_objects->count > > > > Le ven. 7 mai 2021 à 09:17, Fridolin SOMERS > a écrit : > > Hi community, > > I've been on a mindblowing search on a template error :D > > I was thinking that "loop.count" was wrong for testing if loop is not > empty, the method is "loop.size". > > See doc > http://template-toolkit.org/docs/manual/Directives.html#section_FOREACH > > Looks like we use both actually : > > git grep 'IF.*\.count ' origin/master | wc -l > 602 > > git grep 'IF.*\.size ' origin/master | wc -l > 1636 > > So using count seems to work because it starts with 1. > But in my opinion it is a wrong call. > > We can see for example : > Images ([% localimages.count || 0 | html %]) > This is wrong no ? > > Should be create a coding guideline ? > > -- > Fridolin SOMERS > Software and system maintainer 🦄 > BibLibre, France > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://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 : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon May 10 04:20:12 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Mon, 10 May 2021 12:20:12 +1000 Subject: [Koha-devel] TT loop count VS size In-Reply-To: References: <00a601d7452e$135c7ec0$3a157c40$@prosentient.com.au> Message-ID: <00c401d74543$018ca980$04a5fc80$@prosentient.com.au> I know that .count is an object method, but I don’t understand the problem that Fridolin is having. I don’t see any problem at this point. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Tomas Cohen Arazi Sent: Monday, 10 May 2021 11:14 AM To: David Cook Cc: Jonathan Druart ; Fridolin SOMERS ; koha-devel Subject: Re: [Koha-devel] TT loop count VS size That's because .count is a Koha::Objects method. El dom., 9 may. 2021 20:50, > escribió: I was going to say… I’d never even heard of the “count” call in TT. Looking at http://template-toolkit.org/docs/manual/VMethods.html, it’s not a method for a data structure. Looking at http://template-toolkit.org/docs/manual/Directives.html#section_FOREACH, it’s only a method of the “loop” variable. grep -R "loop\.count" * | wc -l 86 What’s the actual problem being observed? David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel > On Behalf Of Jonathan Druart Sent: Friday, 7 May 2021 5:58 PM To: Fridolin SOMERS > Cc: koha-devel > Subject: Re: [Koha-devel] TT loop count VS size You should grep "loop.count", not ".count" Most of the count you have with your regex is coming from koha_objects->count Le ven. 7 mai 2021 à 09:17, Fridolin SOMERS > a écrit : Hi community, I've been on a mindblowing search on a template error :D I was thinking that "loop.count" was wrong for testing if loop is not empty, the method is "loop.size". See doc http://template-toolkit.org/docs/manual/Directives.html#section_FOREACH Looks like we use both actually : > git grep 'IF.*\.count ' origin/master | wc -l 602 > git grep 'IF.*\.size ' origin/master | wc -l 1636 So using count seems to work because it starts with 1. But in my opinion it is a wrong call. We can see for example : Images ([% localimages.count || 0 | html %]) This is wrong no ? Should be create a coding guideline ? -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://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 : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolin.somers at biblibre.com Mon May 10 10:02:02 2021 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Mon, 10 May 2021 10:02:02 +0200 Subject: [Koha-devel] TT loop count VS size In-Reply-To: <00c401d74543$018ca980$04a5fc80$@prosentient.com.au> References: <00a601d7452e$135c7ec0$3a157c40$@prosentient.com.au> <00c401d74543$018ca980$04a5fc80$@prosentient.com.au> Message-ID: <401f353d-e741-ad2e-3f26-15a17f6fa2cb@biblibre.com> Ahhh my bad. So VAR.size is when VAR is an array. VAR.count is allow when VAR is a Koha::Objects, in perl called with ->count. Forget my warning ;) Best regards, Le 10/05/2021 à 04:20, dcook at prosentient.com.au a écrit : > I know that .count is an object method, but I don’t understand the > problem that Fridolin is having. I don’t see any problem at this point. > > David Cook > > Software Engineer > > Prosentient Systems > > Suite 7.03 > > 6a Glen St > > Milsons Point NSW 2061 > > Australia > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > *From:*Tomas Cohen Arazi > *Sent:* Monday, 10 May 2021 11:14 AM > *To:* David Cook > *Cc:* Jonathan Druart ; > Fridolin SOMERS ; koha-devel > > *Subject:* Re: [Koha-devel] TT loop count VS size > > That's because .count is a Koha::Objects method. > > El dom., 9 may. 2021 20:50, > escribió: > > I was going to say… I’d never even heard of the “count” call in TT. > Looking at http://template-toolkit.org/docs/manual/VMethods.html > , it’s not a > method for a data structure. Looking at > http://template-toolkit.org/docs/manual/Directives.html#section_FOREACH > , > it’s only a method of the “loop” variable. > > grep -R "loop\.count" *   | wc -l > > 86 > > What’s the actual problem being observed? > > David Cook > > Software Engineer > > Prosentient Systems > > Suite 7.03 > > 6a Glen St > > Milsons Point NSW 2061 > > Australia > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > *From:*Koha-devel > *On Behalf Of > *Jonathan Druart > *Sent:* Friday, 7 May 2021 5:58 PM > *To:* Fridolin SOMERS > > *Cc:* koha-devel > > *Subject:* Re: [Koha-devel] TT loop count VS size > > You should grep "loop.count", not ".count" > > Most of the count you have with your regex is coming from > koha_objects->count > > Le ven. 7 mai 2021 à 09:17, Fridolin SOMERS > > > a écrit : > > Hi community, > > I've been on a mindblowing search on a template error :D > > I was thinking that "loop.count" was wrong for testing if loop > is not > empty, the method is "loop.size". > > See doc > http://template-toolkit.org/docs/manual/Directives.html#section_FOREACH > > > Looks like we use both actually : >   > git grep 'IF.*\.count ' origin/master | wc -l > 602 >   > git grep 'IF.*\.size ' origin/master | wc -l > 1636 > > So using count seems to work because it starts with 1. > But in my opinion it is a wrong call. > > We can see for example : >   Images ([% localimages.count || 0 | html > %]) > This is wrong no ? > > Should be create a coding guideline ? > > -- > Fridolin SOMERS > > Software and system maintainer 🦄 > BibLibre, France > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > > website : https://www.koha-community.org/ > > git : https://git.koha-community.org/ > > bugs : https://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 : https://www.koha-community.org/ > > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > > -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From jonathan.druart at bugs.koha-community.org Mon May 10 18:01:59 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Mon, 10 May 2021 18:01:59 +0200 Subject: [Koha-devel] API tests broken on master Message-ID: Hi, Some of the REST API tests are failing on master, if it's blocking for you you can revert bug 28272 from your local branch. Cheers, Jonathan From jonathan.druart at bugs.koha-community.org Tue May 11 12:30:46 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Tue, 11 May 2021 12:30:46 +0200 Subject: [Koha-devel] Build a roadmap for 21.11 Message-ID: Hi developers! Yes, I know, 21.05 is not there yet, but we can start to think on which different topics we want to work on during the next cycle! It has been a bit abandoned during the end of the 21.05 cycle, but new topics appeared. I have started to list them on a new document - https://annuel.framapad.org/p/koha_21.11_roadmap There are 2 parts: * at the top: the new ones and those I retrieved from 21.05 * at the bottom: the ones from 21.05, if you need ideas. Move them to the top if you want to continue/resurrect them Add your names to the different topics you are willing to work on, and add new topics! Please keep in mind that your time is limited, no need to add your names everywhere :) And remove your names from the topics you won't/cannot work anymore. I added a bit of styling to make the document more friendly and readable. Note that during this next cycle I will spend my time on RM duties (if elected!) and help topics from the roadmap. Cheers, Jonathan From tomascohen at gmail.com Tue May 11 15:48:08 2021 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 11 May 2021 10:48:08 -0300 Subject: [Koha-devel] Build a roadmap for 21.11 In-Reply-To: References: Message-ID: Nice job! El mar, 11 may 2021 a las 7:31, Jonathan Druart (< jonathan.druart at bugs.koha-community.org>) escribió: > Hi developers! > > Yes, I know, 21.05 is not there yet, but we can start to think on > which different topics we want to work on during the next cycle! > > It has been a bit abandoned during the end of the 21.05 cycle, but new > topics appeared. > > I have started to list them on a new document - > https://annuel.framapad.org/p/koha_21.11_roadmap > There are 2 parts: > * at the top: the new ones and those I retrieved from 21.05 > * at the bottom: the ones from 21.05, if you need ideas. Move them > to the top if you want to continue/resurrect them > > Add your names to the different topics you are willing to work on, and > add new topics! > > Please keep in mind that your time is limited, no need to add your > names everywhere :) > And remove your names from the topics you won't/cannot work anymore. > > I added a bit of styling to make the document more friendly and readable. > > Note that during this next cycle I will spend my time on RM duties (if > elected!) and help topics from the roadmap. > > Cheers, > Jonathan > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://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: From jonathan.druart at bugs.koha-community.org Tue May 11 16:27:54 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Tue, 11 May 2021 16:27:54 +0200 Subject: [Koha-devel] API tests broken on master In-Reply-To: References: Message-ID: I haven't followed up here but the tests have been fixed this "morning" Le lun. 10 mai 2021 à 18:01, Jonathan Druart a écrit : > > Hi, > > Some of the REST API tests are failing on master, if it's blocking for > you you can revert bug 28272 from your local branch. > > Cheers, > Jonathan From victor at tuxayo.net Tue May 11 23:13:37 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Tue, 11 May 2021 23:13:37 +0200 Subject: [Koha-devel] Help needed to test a bug, knowledge required: running automated tests Message-ID: Hi :) Here is a bug that I tested and checked for QA. Now a test from someone else is needed. Here is the ticket: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28200 Here is the test plan: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28200#c16 If you have any questions[1] I'll gladly guide you via email or chat (nickname: tuxayo) [1] including setting up a Koha environment from scratch. Cheers, -- Victor Grousset/tuxayo From dcook at prosentient.com.au Wed May 12 02:40:48 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 12 May 2021 10:40:48 +1000 Subject: [Koha-devel] Build a roadmap for 21.11 In-Reply-To: References: Message-ID: <02b401d746c7$73c36360$5b4a2a20$@prosentient.com.au> I've been struggling with energy/motivation for Koha outside of work hours, but I am still interested in working on "Replace CGI scripts with Mojolicious controllers" and to a lesser extent "Task Scheduler Needs Re-write". I'll put aside an hour tonight after work to try to get back into "Replace CGI scripts with Mojolicious controllers". Perhaps https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26791 was too ambitious for a first step. I'm thinking maybe I'll take a lot of the core code from that bug report, but instead build a controller to replace tools-home.pl. It's not a win in terms of improved functionality, but it would be a low-risk start into using Mojolicious controllers for the web app. The core things that need testing are the authentication, authorization, template rendering (especially non-English templates). I might even find that it's better to slowly refactor Koha's existing functions before it's feasible to use the pure Mojolicious controllers. Once AuthN, AuthZ, and template rendering are solid then there should be nothing else left to do but work on controllers/models. Anyway, I'll take a look tonight! David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Koha-devel On Behalf Of Jonathan Druart Sent: Tuesday, 11 May 2021 8:31 PM To: koha-devel Subject: [Koha-devel] Build a roadmap for 21.11 Hi developers! Yes, I know, 21.05 is not there yet, but we can start to think on which different topics we want to work on during the next cycle! It has been a bit abandoned during the end of the 21.05 cycle, but new topics appeared. I have started to list them on a new document - https://annuel.framapad.org/p/koha_21.11_roadmap There are 2 parts: * at the top: the new ones and those I retrieved from 21.05 * at the bottom: the ones from 21.05, if you need ideas. Move them to the top if you want to continue/resurrect them Add your names to the different topics you are willing to work on, and add new topics! Please keep in mind that your time is limited, no need to add your names everywhere :) And remove your names from the topics you won't/cannot work anymore. I added a bit of styling to make the document more friendly and readable. Note that during this next cycle I will spend my time on RM duties (if elected!) and help topics from the roadmap. Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ From domm at plix.at Wed May 12 10:58:52 2021 From: domm at plix.at (Thomas Klausner) Date: Wed, 12 May 2021 10:58:52 +0200 Subject: [Koha-devel] Build a roadmap for 21.11 In-Reply-To: <02b401d746c7$73c36360$5b4a2a20$@prosentient.com.au> References: <02b401d746c7$73c36360$5b4a2a20$@prosentient.com.au> Message-ID: Hi! On Wed, May 12, 2021 at 10:40:48AM +1000, dcook at prosentient.com.au wrote: > I've been struggling with energy/motivation for Koha outside of work hours, but I am still interested in working on "Replace CGI scripts with Mojolicious controllers" and to a lesser extent "Task Scheduler Needs Re-write". I still have a nearly finished patch to move StageMarcImport to BackgroundJobs lingering around. And I stil plan to finish it, hopefully soon (esp. as the project I'm working on will soon start to import a lot of data). Greetings, domm -- #!/usr/bin/perl https://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From dcook at prosentient.com.au Wed May 12 11:16:39 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 12 May 2021 19:16:39 +1000 Subject: [Koha-devel] master not handling errors correctly Message-ID: <02ea01d7470f$84241e00$8c6c5a00$@prosentient.com.au> Hi all, I was working on https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28325, when I noticed some really weird things going on with Koha's HTTP errors. Look at http://localhost:8081/mojo. While Koha will say it's a 404, it's actually sending back a 200 response. That's not good. (With Bug 28325 I'm having even weirder problems where mounting a new PSGI app within an existing one seems to trigger both a 200 and a 404 within Plack but only return a 200. I don't have the time/energy to deal with that though.) David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik at adminkuhn.ch Thu May 13 09:23:58 2021 From: mik at adminkuhn.ch (Michael Kuhn) Date: Thu, 13 May 2021 09:23:58 +0200 Subject: [Koha-devel] Call for news - Newsletter May 2021 Message-ID: <34307d01-655d-b4fb-6821-d2b8e8499cfc@adminkuhn.ch> Hi I'm collecting news for the May 2021 Koha Community Newsletter. Please send anything noteworthy to: kohanews (at) gmail (dot) com News criteria: * News items can be of any length. * Images are fine. * Anything and everything Koha. * Submit by the 26th of the month. 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 to be announced are fine, e. g. Kohacon. * For past events, one month back is the cut-off. 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! Michael Kuhn Editor, Koha Community Newsletter -- 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 fridolin.somers at biblibre.com Fri May 14 10:13:04 2021 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Fri, 14 May 2021 10:13:04 +0200 Subject: [Koha-devel] Time to translate: string freeze to prepare 20.11.06 release Message-ID: <0c678b1a-379c-bfce-b7f0-a7351c83cee4@biblibre.com> Hi, String freeze is into effect today 🥶 The 20.11.x maintenance branch is preparing for 20.11.06 release 📦 The release is scheduled for around the 25. This means it's the right time to head over to the translation platform: https://translate.koha-community.org/projects/ Note that nl-NL translation for 20.11 was very low, I've ask them to be reinitialized with merge of files from 19.11. Translation is now around 70%. Keep in mind that translation must be done with priority on higher version 🔥 Happy translating 🌎🌍🌏 -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From victor at tuxayo.net Fri May 14 17:12:23 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Fri, 14 May 2021 17:12:23 +0200 Subject: [Koha-devel] Time to translate: string freeze to prepare Koha 19.11.18 has begun Message-ID: <77ed5613-11a1-ee51-0a54-b0018911070c@tuxayo.net> Hi, saluton, hola, bonjour, String freeze is into effect as of now for the 19.11.x maintenance branch. The release is scheduled for around the 24th/25th. **If you missed it the upcoming 21.05 release is translatable now.** This means it's the right time to head over to the translation platform: https://translate.koha-community.org/projects/ Reminder: if you add or change a translation in version 19.11, then you must also copy it to 20.05, 20.11 and 21.05. Otherwise your work will be lost for future versions. (We've had a recent significant case of that!) Happy translating, -- Victor Grousset/tuxayo From david.nind at gmail.com Fri May 14 23:17:26 2021 From: david.nind at gmail.com (David Nind) Date: Sat, 15 May 2021 09:17:26 +1200 Subject: [Koha-devel] z3950 responding - accessing when using koha-testing-docker Message-ID: Does anyone know how to get the Z3950Responder "working" using koha-testing-docker? The service is running and seems to be configured correctly (using koha-z3950-responder package commands) but I can't access/query using 127.0.0.1:2100 - I get *unable to connect* in my browser. Example query from the bug I am trying to test - *Bug 23887* - Add support for client-specified sort order in Z3950Responder: http://127.0.01:2100/biblios?version=1.2&operation=searchRetrieve&query=misth%20sortby%20title/ascending%20author&maximumRecords=10&recordSchema=marcxml Other steps taken: changed search engine to Elasticsearch and reindexed. Any help would be appreciated! David Nind | david.nind at gmail.com PO Box 12367, Thorndon, Wellington, New Zealand 6144 m. +64 21 0537 847 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Mon May 17 23:05:10 2021 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 17 May 2021 18:05:10 -0300 Subject: [Koha-devel] PUT /holds/:hold_id Message-ID: Hi all, I wanted to gather some opinions about the mentioned route. We've made sure all routes have the additionalProperties: false setting, and some routes, like this one, don't have it. In the task to add it we noticed: 1. Theroute doesn't work as expected: the documented attributes don't match the coding guidelines (i.e. terminology hasn't been adjusted on the spec) but it did in the code, it just works because we don't set additionalProperties: false. TL;DR no one following the spec can use it. 2. The route seems to be wrong regarding how our RESTful implementation works in the rest of the routes: PUT should get a Koha::Hold object for updating it. Instead, it only 'accepts': 'priority', 'pickup_library_id' and 'suspended_until'. If we wanted to allow to selectively change those attributes, we should do a PATCH instead. 3. We already have individual routes for changing those things on the hold: PUT /holds/:hold_id/pickup_location PUT /holds/:hold_id/priority POST /holds/:hold_id/suspension The route itself doesn't work now. And any change will break things for people 'using' it. And tests pass only because the spec is loose. The options are: - 'Fix' the route so the attributes match the code, i.e. change the spec as bug 20006 intended to do. - Leave it as-is (probably documenting it should not be used). - Remove the route until we really need to implement that PUT for something. - Make it a PATCH route, in which we could add new attributes without breaking anyone's dev (besides the verb change, that should be advertised) - Fully implement a PUT, making it mandatory to send all the attributes (this would be an important breaking change). I would vote removing it, or making it a PATCH route. But I still don't see the use case in the UI, for the latter. Most places in Koha do atomic updates for priority, pickup location or hold suspension for which we clearly have routes already. Looking forward to your comments. -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue May 18 05:31:03 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 18 May 2021 13:31:03 +1000 Subject: [Koha-devel] PUT /holds/:hold_id In-Reply-To: References: Message-ID: <01bf01d74b96$3adabbb0$b0903310$@prosentient.com.au> I’m not sure that I have much to contribute. One comment I would have is… what is the threshold for creating a V2 of the REST API? And maybe a breaking change for the API is OK for a major version change in Koha but just not a minor version change? (That said, I’ve encountered breaking changes in PostgreSQL on minor version updates. They’re annoying, but they are a fact of life I suppose.) David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Tomas Cohen Arazi Sent: Tuesday, 18 May 2021 7:05 AM To: koha-devel Subject: [Koha-devel] PUT /holds/:hold_id Hi all, I wanted to gather some opinions about the mentioned route. We've made sure all routes have the additionalProperties: false setting, and some routes, like this one, don't have it. In the task to add it we noticed: 1. Theroute doesn't work as expected: the documented attributes don't match the coding guidelines (i.e. terminology hasn't been adjusted on the spec) but it did in the code, it just works because we don't set additionalProperties: false. TL;DR no one following the spec can use it. 2. The route seems to be wrong regarding how our RESTful implementation works in the rest of the routes: PUT should get a Koha::Hold object for updating it. Instead, it only 'accepts': 'priority', 'pickup_library_id' and 'suspended_until'. If we wanted to allow to selectively change those attributes, we should do a PATCH instead. 3. We already have individual routes for changing those things on the hold: PUT /holds/:hold_id/pickup_location PUT /holds/:hold_id/priority POST /holds/:hold_id/suspension The route itself doesn't work now. And any change will break things for people 'using' it. And tests pass only because the spec is loose. The options are: - 'Fix' the route so the attributes match the code, i.e. change the spec as bug 20006 intended to do. - Leave it as-is (probably documenting it should not be used). - Remove the route until we really need to implement that PUT for something. - Make it a PATCH route, in which we could add new attributes without breaking anyone's dev (besides the verb change, that should be advertised) - Fully implement a PUT, making it mandatory to send all the attributes (this would be an important breaking change). I would vote removing it, or making it a PATCH route. But I still don't see the use case in the UI, for the latter. Most places in Koha do atomic updates for priority, pickup location or hold suspension for which we clearly have routes already. Looking forward to your comments. -- Tomás Cohen Arazi Theke Solutions (http://theke.io ) ✆ +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthur.suzuki at biblibre.com Tue May 18 11:58:54 2021 From: arthur.suzuki at biblibre.com (Arthur) Date: Tue, 18 May 2021 11:58:54 +0200 Subject: [Koha-devel] PUT /holds/:hold_id In-Reply-To: <01bf01d74b96$3adabbb0$b0903310$@prosentient.com.au> References: <01bf01d74b96$3adabbb0$b0903310$@prosentient.com.au> Message-ID: Hi Thomas, David, I vote for making it a PATCH route and either document the PUT method as "do-not-use" or making it a real "PUT". In my opinion making the api a v2 is going to make things confusing for consumers as there are already several web-services available for Koha (ILS-DI, OAI-PMH, SRU, Rest...). For each API version, consumer app must develop a new connector and a mechanism to select which connector is appropriate to use, this is going to be quite confusing + added complexity for api consumers. Unnecessary complexity in my opinion. Arthur Suzuki, BibLibre Support Developper On 18/05/2021 05:31, dcook at prosentient.com.au wrote: > > I’m not sure that I have much to contribute. > >   > > One comment I would have is… what is the threshold for creating a V2 > of the REST API? > >   > > And maybe a breaking change for the API is OK for a major version > change in Koha but just not a minor version change? (That said, I’ve > encountered breaking changes in PostgreSQL on minor version updates. > They’re annoying, but they are a fact of life I suppose.) > >   > > David Cook > > Software Engineer > > Prosentient Systems > > Suite 7.03 > > 6a Glen St > > Milsons Point NSW 2061 > > Australia > >   > > Office: 02 9212 0899 > > Online: 02 8005 0595 > >   > > *From:*Koha-devel *On > Behalf Of *Tomas Cohen Arazi > *Sent:* Tuesday, 18 May 2021 7:05 AM > *To:* koha-devel > *Subject:* [Koha-devel] PUT /holds/:hold_id > >   > > Hi all, I wanted to gather some opinions about the mentioned route. > >   > > We've made sure all routes have the additionalProperties: false > setting, and some routes, like this one, don't have it. In the task to > add it we noticed: > > 1. Theroute doesn't work as expected: the documented attributes don't > match the coding guidelines (i.e. terminology hasn't been adjusted on > the spec) but it did in the code, it just works because we don't set > additionalProperties: false. TL;DR no one following the spec can use it. > 2. The route seems to be wrong regarding how our RESTful > implementation works in the rest of the routes: PUT should get a > Koha::Hold object for updating it. Instead, it only 'accepts': > 'priority', 'pickup_library_id' and 'suspended_until'. If we wanted to > allow to selectively change those attributes, we should do a PATCH > instead. > 3. We already have individual routes for changing those things on the > hold: > PUT /holds/:hold_id/pickup_location > PUT /holds/:hold_id/priority > POST /holds/:hold_id/suspension > > The route itself doesn't work now. And any change will break things > for people 'using' it. And tests pass only because the spec is loose. > The options are: > > - 'Fix' the route so the attributes match the code, i.e. change the > spec as bug 20006 intended to do. > > - Leave it as-is (probably documenting it should not be used). > > - Remove the route until we really need to implement that PUT for > something. > > - Make it a PATCH route, in which we could add new attributes without > breaking anyone's dev (besides the verb change, that should be advertised) > > - Fully implement a PUT, making it mandatory to send all the > attributes (this would be an important breaking change). > >   > > I would vote removing it, or making it a PATCH route. But I still > don't see the use case in the UI, for the latter. Most places in Koha > do atomic updates for priority, pickup location or hold suspension for > which we clearly have routes already. > >   > > Looking forward to your comments. > >   > > -- > > 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 : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ere.maijala at helsinki.fi Wed May 19 08:06:38 2021 From: ere.maijala at helsinki.fi (Ere Maijala) Date: Wed, 19 May 2021 09:06:38 +0300 Subject: [Koha-devel] PUT /holds/:hold_id In-Reply-To: References: <01bf01d74b96$3adabbb0$b0903310$@prosentient.com.au> Message-ID: Hi, Looks like bug 28369 is moving in the right direction. Whatever is eventually done, it's important to not just remove or change existing API functionality in the current API version. An API version should remain back-compatible. Functionality can be deprecated, but it should not be removed between Koha versions. I think Innovative has found an acceptable balance with their Sierra REST api versioning and deprecation policy. I'm not sure of all the details, but basicly they've added a new version whenever there's a backwards-incompatible change and kept the older API versions available for a few versions. Then the oldest one gets deprecated, and in the next major version or so it is removed. They also indicate which one is the recommended API version to target. A further note about the holds API endpoints: I can see the reasoning behind the different endpoints for suspension, priority etc. but from an API user's endpoint it's really convoluted to use. I'd really like a PATCH method that would allow one to update priority, suspension and it's end date and pickup location in a single request. --Ere Arthur kirjoitti 18.5.2021 klo 12.58: > Hi Thomas, David, > > I vote for making it a PATCH route and either document the PUT method as > "do-not-use" or making it a real "PUT". > > In my opinion making the api a v2 is going to make things confusing for > consumers as there are already several web-services available for Koha > (ILS-DI, OAI-PMH, SRU, Rest...). > > For each API version, consumer app must develop a new connector and a > mechanism to select which connector is appropriate to use, this is going > to be quite confusing + added complexity for api consumers. > > Unnecessary complexity in my opinion. > > Arthur Suzuki, > > BibLibre Support Developper > > On 18/05/2021 05:31, dcook at prosentient.com.au wrote: >> >> I’m not sure that I have much to contribute. >> >> One comment I would have is… what is the threshold for creating a V2 >> of the REST API? >> >> And maybe a breaking change for the API is OK for a major version >> change in Koha but just not a minor version change? (That said, I’ve >> encountered breaking changes in PostgreSQL on minor version updates. >> They’re annoying, but they are a fact of life I suppose.) >> >> David Cook >> >> Software Engineer >> >> Prosentient Systems >> >> Suite 7.03 >> >> 6a Glen St >> >> Milsons Point NSW 2061 >> >> Australia >> >> Office: 02 9212 0899 >> >> Online: 02 8005 0595 >> >> *From:*Koha-devel *On >> Behalf Of *Tomas Cohen Arazi >> *Sent:* Tuesday, 18 May 2021 7:05 AM >> *To:* koha-devel >> *Subject:* [Koha-devel] PUT /holds/:hold_id >> >> Hi all, I wanted to gather some opinions about the mentioned route. >> >> We've made sure all routes have the additionalProperties: false >> setting, and some routes, like this one, don't have it. In the task to >> add it we noticed: >> >> 1. Theroute doesn't work as expected: the documented attributes don't >> match the coding guidelines (i.e. terminology hasn't been adjusted on >> the spec) but it did in the code, it just works because we don't set >> additionalProperties: false. TL;DR no one following the spec can use it. >> 2. The route seems to be wrong regarding how our RESTful >> implementation works in the rest of the routes: PUT should get a >> Koha::Hold object for updating it. Instead, it only 'accepts': >> 'priority', 'pickup_library_id' and 'suspended_until'. If we wanted to >> allow to selectively change those attributes, we should do a PATCH >> instead. >> 3. We already have individual routes for changing those things on the >> hold: >> PUT /holds/:hold_id/pickup_location >> PUT /holds/:hold_id/priority >> POST /holds/:hold_id/suspension >> >> The route itself doesn't work now. And any change will break things >> for people 'using' it. And tests pass only because the spec is loose. >> The options are: >> >> - 'Fix' the route so the attributes match the code, i.e. change the >> spec as bug 20006 intended to do. >> >> - Leave it as-is (probably documenting it should not be used). >> >> - Remove the route until we really need to implement that PUT for >> something. >> >> - Make it a PATCH route, in which we could add new attributes without >> breaking anyone's dev (besides the verb change, that should be advertised) >> >> - Fully implement a PUT, making it mandatory to send all the >> attributes (this would be an important breaking change). >> >> I would vote removing it, or making it a PATCH route. But I still >> don't see the use case in the UI, for the latter. Most places in Koha >> do atomic updates for priority, pickup location or hold suspension for >> which we clearly have routes already. >> >> Looking forward to your comments. >> >> -- >> >> 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 :https://www.koha-community.org/ >> git :https://git.koha-community.org/ >> bugs :https://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 : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -- Ere Maijala Kansalliskirjasto / The National Library of Finland From dcook at prosentient.com.au Wed May 19 09:28:36 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 19 May 2021 17:28:36 +1000 Subject: [Koha-devel] Koha logging out staff users Message-ID: <02bd01d74c80$94cb3830$be61a890$@prosentient.com.au> Hi all, Does anyone have an issue where staff users are being logged out of Koha? The session timeout threshold is 1d, and AutoLocation and SessionRestrictionByIP are both disabled. I can't think of any reason why they're getting logged out. I also cannot reproduce the problem on my own workstation. So just curious if people have heard of this happening. I've heard it from 2 libraries now. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at libriotech.no Wed May 19 10:44:07 2021 From: magnus at libriotech.no (Magnus Enger) Date: Wed, 19 May 2021 10:44:07 +0200 Subject: [Koha-devel] Koha logging out staff users In-Reply-To: <02bd01d74c80$94cb3830$be61a890$@prosentient.com.au> References: <02bd01d74c80$94cb3830$be61a890$@prosentient.com.au> Message-ID: Den 19.05.2021 09:28, skrev dcook at prosentient.com.au: > Hi all, > > > > Does anyone have an issue where staff users are being logged out of Koha? What is the setting for SessionStorage? Is everyone logged out at the same time, or is it more random? Best regards, Magnus Libriotech AS From dcook at prosentient.com.au Thu May 20 01:12:48 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Thu, 20 May 2021 09:12:48 +1000 Subject: [Koha-devel] Koha logging out staff users In-Reply-To: References: <02bd01d74c80$94cb3830$be61a890$@prosentient.com.au> Message-ID: <035701d74d04$7c0354c0$7409fe40$@prosentient.com.au> SessionStorage is MySQL. It's random, and after review it seems like it's just happening for one library. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Koha-devel On Behalf Of Magnus Enger Sent: Wednesday, 19 May 2021 6:44 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Koha logging out staff users Den 19.05.2021 09:28, skrev dcook at prosentient.com.au: > Hi all, > > > > Does anyone have an issue where staff users are being logged out of Koha? What is the setting for SessionStorage? Is everyone logged out at the same time, or is it more random? Best regards, Magnus Libriotech AS _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ From jonathan.druart at bugs.koha-community.org Mon May 24 09:53:16 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Mon, 24 May 2021 09:53:16 +0200 Subject: [Koha-devel] Build a roadmap for 21.11 In-Reply-To: References: Message-ID: Hi Koha developers, There are still many workgroups waiting for love on the 21.11 roadmap. One week left before we prioritize the different topics depending on their number of members. If you are willing to help the other people of the community during the next six months, let us know! https://annuel.framapad.org/p/koha_21.11_roadmap It would be great to see more names, and even new names, on this document. Let me know if you have any questions. Cheers, Jonathan Le mar. 11 mai 2021 à 12:30, Jonathan Druart a écrit : > > Hi developers! > > Yes, I know, 21.05 is not there yet, but we can start to think on > which different topics we want to work on during the next cycle! > > It has been a bit abandoned during the end of the 21.05 cycle, but new > topics appeared. > > I have started to list them on a new document - > https://annuel.framapad.org/p/koha_21.11_roadmap > There are 2 parts: > * at the top: the new ones and those I retrieved from 21.05 > * at the bottom: the ones from 21.05, if you need ideas. Move them > to the top if you want to continue/resurrect them > > Add your names to the different topics you are willing to work on, and > add new topics! > > Please keep in mind that your time is limited, no need to add your > names everywhere :) > And remove your names from the topics you won't/cannot work anymore. > > I added a bit of styling to make the document more friendly and readable. > > Note that during this next cycle I will spend my time on RM duties (if > elected!) and help topics from the roadmap. > > Cheers, > Jonathan From fridolin.somers at biblibre.com Tue May 25 16:25:18 2021 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Tue, 25 May 2021 16:25:18 +0200 Subject: [Koha-devel] Release of Koha 20.11.06 Message-ID: <6b3ad47c-f965-0bd8-bedc-82b68ae46e14@biblibre.com> Hello everyone 🤗 The Koha community is proud to announce the release of Koha 20.11.06. It is a maintenance release with 3 security fixes. The full release notes are available here: https://koha-community.org/koha-20-11-06-released/ Debian packages should be available in a few days. PS : 🌼 This is last release of 21.05 cycle. I'll continue maintaining 20.11.x that will switch to 'oldstable'. In 20.11.1889 was born Mr. Hubble https://en.wikipedia.org/wiki/Edwin_Hubble So 20.11 is going to infinity ... and beyond 🚀 Best regards 🤓 -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From andrew at bywatersolutions.com Tue May 25 17:29:38 2021 From: andrew at bywatersolutions.com (Andrew Fuerste-Henry) Date: Tue, 25 May 2021 10:29:38 -0500 Subject: [Koha-devel] Release of Koha 20.05.12 Message-ID: Hi all! The Koha community is pleased to announce the release of Koha 20.05.12! The full release notes can be found here: https://koha-community.org/koha-20-05-12-released/ Thanks! Andrew -- Andrew Fuerste-Henry Educator (he/him/his) ByWater Solutions bywatersolutions.com Phone:(888)900-8944 <(888)%20900-8944> What is Koha? -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor at tuxayo.net Tue May 25 17:45:20 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Tue, 25 May 2021 17:45:20 +0200 Subject: [Koha-devel] Deadlock issues when running the tests in parallel, and maybe not only in the tests? Message-ID: Hi :) IIUC this is where the CI calls "prove" to run the tests https://gitlab.com/koha-community/koha-testing-docker/-/blob/master/files/run.sh#L213 And this is the place where KOHA_PROVE_CPUS is set. https://gitlab.com/koha-community/koha-testing-docker/-/blob/master/files/run.sh#L155 It's not set in ".env" file so it should use "nproc" and this calls "prove" with more than one thread. Is that really the case? I tried locally use to "prove -j 4" and I'm getting deadlocks with the database after a few minutes. And do these deadlock in tests mean that Koha can hit them while running in production? I expect the tests to fail due to messing up with each other data but a deadlock is something else. Cheers, -- Victor Grousset/tuxayo From joonas.kylmala at helsinki.fi Tue May 25 17:54:36 2021 From: joonas.kylmala at helsinki.fi (=?UTF-8?Q?Joonas_Kylm=c3=a4l=c3=a4?=) Date: Tue, 25 May 2021 18:54:36 +0300 Subject: [Koha-devel] Deadlock issues when running the tests in parallel, and maybe not only in the tests? In-Reply-To: References: Message-ID: Hey Victor, can you please check whether the $ENV{KOHA_TESTING} variable is set correctly in your CI setup, and if it is not, does it fix the issue? Please see the code in C4::Circulation::SendCirculationAlert(), it is the only place where we do manual db locking as far as I know. It is something we should fix by re-architecturing the message_queue database table for digest messages. However, I'm interested in knowing if the deadlocks now happen because of this and whether it is unit test specific issue because at least based on the comments in SendCirculationAlert() it appears to be so. Regards, Joonas On 25/05/2021 18:45, Victor Grousset/tuxayo wrote: > Hi :) > > IIUC this is where the CI calls "prove" to run the tests > https://gitlab.com/koha-community/koha-testing-docker/-/blob/master/files/run.sh#L213 > > > And this is the place where KOHA_PROVE_CPUS is set. > https://gitlab.com/koha-community/koha-testing-docker/-/blob/master/files/run.sh#L155 > > It's not set in ".env" file so it should use "nproc" and this calls > "prove" with more than one thread. > > Is that really the case? I tried locally use to "prove -j 4" and I'm > getting deadlocks with the database after a few minutes. > > And do these deadlock in tests mean that Koha can hit them while running > in production? > > I expect the tests to fail due to messing up with each other data but a > deadlock is something else. > > > Cheers, > -- Joonas Kylmälä Tietojärjestelmäasiantuntija Kansalliskirjasto Kirjastoverkkopalvelut PL 15 (Unioninkatu 36) 00014 Helsingin yliopisto From joonas.kylmala at helsinki.fi Tue May 25 18:00:50 2021 From: joonas.kylmala at helsinki.fi (=?UTF-8?Q?Joonas_Kylm=c3=a4l=c3=a4?=) Date: Tue, 25 May 2021 19:00:50 +0300 Subject: [Koha-devel] Deadlock issues when running the tests in parallel, and maybe not only in the tests? In-Reply-To: References: Message-ID: Hmm, based on the line https://gitlab.com/koha-community/koha-testing-docker/-/blob/master/files/run.sh#L204 I would think the ENV variable is actually set so maybe it is not this. Any more info on the tables it locks on? Regards, Joonas On 25/05/2021 18:54, Joonas Kylmälä wrote: > Hey Victor, > > can you please check whether the $ENV{KOHA_TESTING} variable is set > correctly in your CI setup, and if it is not, does it fix the issue? > Please see the code in C4::Circulation::SendCirculationAlert(), it is > the only place where we do manual db locking as far as I know. It is > something we should fix by re-architecturing the message_queue database > table for digest messages. However, I'm interested in knowing if the > deadlocks now happen because of this and whether it is unit test > specific issue because at least based on the comments in > SendCirculationAlert() it appears to be so. > > Regards, > Joonas > > On 25/05/2021 18:45, Victor Grousset/tuxayo wrote: >> Hi :) >> >> IIUC this is where the CI calls "prove" to run the tests >> https://gitlab.com/koha-community/koha-testing-docker/-/blob/master/files/run.sh#L213 >> >> >> And this is the place where KOHA_PROVE_CPUS is set. >> https://gitlab.com/koha-community/koha-testing-docker/-/blob/master/files/run.sh#L155 >> >> It's not set in ".env" file so it should use "nproc" and this calls >> "prove" with more than one thread. >> >> Is that really the case? I tried locally use to "prove -j 4" and I'm >> getting deadlocks with the database after a few minutes. >> >> And do these deadlock in tests mean that Koha can hit them while running >> in production? >> >> I expect the tests to fail due to messing up with each other data but a >> deadlock is something else. >> >> >> Cheers, >> > -- Joonas Kylmälä Tietojärjestelmäasiantuntija Kansalliskirjasto Kirjastoverkkopalvelut PL 15 (Unioninkatu 36) 00014 Helsingin yliopisto From victor at tuxayo.net Tue May 25 18:05:52 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Tue, 25 May 2021 18:05:52 +0200 Subject: [Koha-devel] Deadlock issues when running the tests in parallel, and maybe not only in the tests? In-Reply-To: References: Message-ID: Hi :) On 21-05-25 18:00, Joonas Kylmälä wrote: > Hmm, based on the line > https://gitlab.com/koha-community/koha-testing-docker/-/blob/master/files/run.sh#L204 > I would think the ENV variable is actually set so maybe it is not this. > Any more info on the tables it locks on? I did yet processed your previous message but here quickly the error messages. Important info, it has been ran on 19.11.x t/db_dependent/Charset.t ................................................ ok ===( 4190;485 797/? 0/? 17/47 2/15 )============================DBD::mysql::db do failed: Deadlock found when trying to get lock; try restarting transaction [for Statement "DELETE FROM issues"] at t/db_dependent/Circulation/Branch.t line 49. ===( 4191;486 797/? 0/? 17/47 3/15 )============================DBD::mysql::db do failed: Deadlock found when trying to get lock; try restarting transaction [for Statement "DELETE FROM items"] at t/db_dependent/Circulation.t line 1174. # No tests run! # Failed test 'No tests run for subtest "AllowRenewalIfOtherItemsAvailable tests"' # at t/db_dependent/Circulation.t line 1269. DBD::mysql::db do failed: Deadlock found when trying to get lock; try restarting transaction [for Statement "DELETE FROM items"] at t/db_dependent/Circulation.t line 1174. # Looks like your test exited with 255 just after 18. t/db_dependent/Circulation.t ............................................ Dubious, test returned 255 (wstat 65280, 0xff00) -- Victor Grousset/tuxayo From victor at tuxayo.net Tue May 25 19:38:54 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Tue, 25 May 2021 19:38:54 +0200 Subject: [Koha-devel] =?utf-8?b?S29oYSAxOS4xMS4xOCByZWxlYXNlZCwg4pqgIHNl?= =?utf-8?q?curity_release?= Message-ID: <31619e35-8d38-f444-6669-f247b9936236@tuxayo.net> Hello! The Koha Community is happy to announce the release of Koha 19.11.18 The full release notes can be found at: https://koha-community.org/koha-19-11-18-released/ Debian packages should be available shortly. Thanks to everyone involved :) Cheers, -- Victor Grousset/tuxayo From dcook at prosentient.com.au Wed May 26 02:10:32 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 26 May 2021 10:10:32 +1000 Subject: [Koha-devel] Thoughts on reloading Koha plugins Message-ID: <010101d751c3$8b780450$a2680cf0$@prosentient.com.au> Hi all, It seems to me that installing Koha plugins is easy enough. Each Starman process will load the plugin into memory because it hasn't seen it before. However, if you're updating/upgrading a plugin, each Starman process has already loaded it, so it won't know that it needs to reload it. I think most of us work around this at the moment either by restarting Plack or just letting the Starman workers die and be replaced by new ones that use the updated code. But that doesn't seem optimal for an environment that allows user plugins. That said, https://advent.plackperl.org/2009/12/day-4-reloading-applications.html and https://metacpan.org/pod/Module::Reload have a few points on how reloading code in a persistent process is a good way to get bugs. I recall Kyle saying Wordpress was his inspiration for the plugins. I'm curious how Wordpress handles plugin upgrades. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Wed May 26 02:37:50 2021 From: mtj at kohaaloha.com (Mason James) Date: Wed, 26 May 2021 12:37:50 +1200 Subject: [Koha-devel] Deadlock issues when running the tests in parallel, and maybe not only in the tests? In-Reply-To: References: Message-ID: <39abe900-eaa7-1725-53a0-122dbbd9a768@kohaaloha.com> On 26/05/21 3:45 am, Victor Grousset/tuxayo wrote: > Hi :) > > IIUC this is where the CI calls "prove" to run the tests > https://gitlab.com/koha-community/koha-testing-docker/-/blob/master/files/run.sh#L213 > > And this is the place where KOHA_PROVE_CPUS is set. > https://gitlab.com/koha-community/koha-testing-docker/-/blob/master/files/run.sh#L155 > It's not set in ".env" file so it should use "nproc" and this calls "prove" with more than one thread. > > Is that really the case? I tried locally use to "prove -j 4" and I'm getting deadlocks with the database after a few minutes. hi Victor it is known behaviour with the test suite, i think its caused by the tests mocking database tables in parallel - which is something that would not happen during normal/production usage you can see that all the database tests are forced to run sequentially...    prove -j ${KOHA_PROVE_CPUS} --rules='seq=t/db_dependent/**.t' https://gitlab.com/koha-community/koha-testing-docker/-/blob/master/files/run.sh#L213 From arthur.suzuki at biblibre.com Wed May 26 06:09:37 2021 From: arthur.suzuki at biblibre.com (Arthur) Date: Wed, 26 May 2021 06:09:37 +0200 Subject: [Koha-devel] Thoughts on reloading Koha plugins In-Reply-To: <010101d751c3$8b780450$a2680cf0$@prosentient.com.au> References: <010101d751c3$8b780450$a2680cf0$@prosentient.com.au> Message-ID: <1f869d95-b162-2fb1-8296-ce70d512395a@biblibre.com> Hi David, From what I recall about wordpress, it doesn't use any code-caching system. (wordpress hosters could use FastCGI though). It's reloaded at each calls. Arthur On 26/05/2021 02:10, dcook at prosentient.com.au wrote: > > Hi all, > >   > > It seems to me that installing Koha plugins is easy enough. Each > Starman process will load the plugin into memory because it hasn’t > seen it before. > >   > > However, if you’re updating/upgrading a plugin, each Starman process > has already loaded it, so it won’t know that it needs to reload it. I > think most of us work around this at the moment either by restarting > Plack or just letting the Starman workers die and be replaced by new > ones that use the updated code. But that doesn’t seem optimal for an > environment that allows user plugins… > >   > > That said, > https://advent.plackperl.org/2009/12/day-4-reloading-applications.html > > and https://metacpan.org/pod/Module::Reload > have a few points on how > reloading code in a persistent process is a good way to get bugs. > >   > > I recall Kyle saying Wordpress was his inspiration for the plugins. > I’m curious how Wordpress handles plugin upgrades. > >   > > David Cook > > Software Engineer > > Prosentient Systems > > Suite 7.03 > > 6a Glen St > > Milsons Point NSW 2061 > > Australia > >   > > Office: 02 9212 0899 > > Online: 02 8005 0595 > >   > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Wed May 26 06:13:57 2021 From: mtj at kohaaloha.com (Mason James) Date: Wed, 26 May 2021 16:13:57 +1200 Subject: [Koha-devel] [Koha] Release of Koha 20.11.06 In-Reply-To: <6b3ad47c-f965-0bd8-bedc-82b68ae46e14@biblibre.com> References: <6b3ad47c-f965-0bd8-bedc-82b68ae46e14@biblibre.com> Message-ID: On 26/05/21 2:25 am, Fridolin SOMERS wrote: > Hello everyone 🤗 > > The Koha community is proud to announce the release of Koha 20.11.06. > > It is a maintenance release with 3 security fixes. > > The full release notes are available here: > https://koha-community.org/koha-20-11-06-released/ > > Debian packages should be available in a few days. > Kia ora community, the Debian packages are uploaded cheers, Mason From dcook at prosentient.com.au Wed May 26 07:16:58 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 26 May 2021 15:16:58 +1000 Subject: [Koha-devel] Thoughts on reloading Koha plugins In-Reply-To: <1f869d95-b162-2fb1-8296-ce70d512395a@biblibre.com> References: <010101d751c3$8b780450$a2680cf0$@prosentient.com.au> <1f869d95-b162-2fb1-8296-ce70d512395a@biblibre.com> Message-ID: <015c01d751ee$59d18a90$0d749fb0$@prosentient.com.au> Hmm interesting. I see instructions on setting up Wordpress with FastCGI but no comments about any impact that would have on plugins. Maybe they just don't worry about it the same way most Koha folk don't worry about it hehe. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Arthur Sent: Wednesday, 26 May 2021 2:10 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Thoughts on reloading Koha plugins Hi David, >From what I recall about wordpress, it doesn't use any code-caching system. (wordpress hosters could use FastCGI though). It's reloaded at each calls. Arthur On 26/05/2021 02:10, dcook at prosentient.com.au wrote: Hi all, It seems to me that installing Koha plugins is easy enough. Each Starman process will load the plugin into memory because it hasn't seen it before. However, if you're updating/upgrading a plugin, each Starman process has already loaded it, so it won't know that it needs to reload it. I think most of us work around this at the moment either by restarting Plack or just letting the Starman workers die and be replaced by new ones that use the updated code. But that doesn't seem optimal for an environment that allows user plugins. That said, https://advent.plackperl.org/2009/12/day-4-reloading-applications.html and https://metacpan.org/pod/Module::Reload have a few points on how reloading code in a persistent process is a good way to get bugs. I recall Kyle saying Wordpress was his inspiration for the plugins. I'm curious how Wordpress handles plugin upgrades. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmc at equinoxoli.org Wed May 26 19:59:21 2021 From: gmc at equinoxoli.org (Galen Charlton) Date: Wed, 26 May 2021 13:59:21 -0400 Subject: [Koha-devel] Thoughts on reloading Koha plugins In-Reply-To: <015c01d751ee$59d18a90$0d749fb0$@prosentient.com.au> References: <010101d751c3$8b780450$a2680cf0$@prosentient.com.au> <1f869d95-b162-2fb1-8296-ce70d512395a@biblibre.com> <015c01d751ee$59d18a90$0d749fb0$@prosentient.com.au> Message-ID: Hi, On Wed, May 26, 2021 at 1:17 AM wrote: > Hmm interesting. I see instructions on setting up Wordpress with FastCGI > but no comments about any impact that would have on plugins. Maybe they > just don’t worry about it the same way most Koha folk don’t worry about it > hehe. > As I recall, Zend Opcache has various settings to control if and when it will recompile the PHP scripts in caches. Depending on what settings you choose, in a FastCGI environment it can periodically check to see if a script has been updated and update the cache if need be - or, if you choose, never revalidate the cache, in which case you'd need to reload or restart php-fpm after changing code. Also, WordPress has code that tries to clear opcache. [1, 2] [1] https://developer.wordpress.org/reference/functions/wp_opcache_invalidate/ [2] https://core.trac.wordpress.org/ticket/36455 Regards, Galen -- Galen Charlton Implementation and IT Manager Equinox Open Library Initiative gmc at equinoxOLI.org https://www.equinoxOLI.org phone: 877-OPEN-ILS (673-6457) direct: 770-709-5581 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu May 27 02:00:56 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Thu, 27 May 2021 10:00:56 +1000 Subject: [Koha-devel] Thoughts on reloading Koha plugins In-Reply-To: References: <010101d751c3$8b780450$a2680cf0$@prosentient.com.au> <1f869d95-b162-2fb1-8296-ce70d512395a@biblibre.com> <015c01d751ee$59d18a90$0d749fb0$@prosentient.com.au> Message-ID: <01de01d7528b$5e3d5ad0$1ab81070$@prosentient.com.au> That’s interesting, Galen. If I recall correctly, loading libraries in PHP doesn’t load them into PHP per se but rather inserts the code into the PHP script itself. I suppose in that way maybe you could cache and invalidate individual scripts and not have to worry about “unloading modules”. I don’t think we have any equivalent in Perl though, unfortunately. With Plack, we have Plack::App::CGIBin, which caches CGI scripts by turning them into packages, but everything is living in that Starman worker process. I have to go into a meeting but more thinking to do here… David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Galen Charlton Sent: Thursday, 27 May 2021 3:59 AM To: David Cook Cc: Arthur ; koha-devel Subject: Re: [Koha-devel] Thoughts on reloading Koha plugins Hi, On Wed, May 26, 2021 at 1:17 AM > wrote: Hmm interesting. I see instructions on setting up Wordpress with FastCGI but no comments about any impact that would have on plugins. Maybe they just don’t worry about it the same way most Koha folk don’t worry about it hehe. As I recall, Zend Opcache has various settings to control if and when it will recompile the PHP scripts in caches. Depending on what settings you choose, in a FastCGI environment it can periodically check to see if a script has been updated and update the cache if need be - or, if you choose, never revalidate the cache, in which case you'd need to reload or restart php-fpm after changing code. Also, WordPress has code that tries to clear opcache. [1, 2] [1] https://developer.wordpress.org/reference/functions/wp_opcache_invalidate/ [2] https://core.trac.wordpress.org/ticket/36455 Regards, Galen -- Galen Charlton Implementation and IT Manager Equinox Open Library Initiative gmc at equinoxOLI.org https://www.equinoxOLI.org phone: 877-OPEN-ILS (673-6457) direct: 770-709-5581 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu May 27 05:50:15 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Thu, 27 May 2021 13:50:15 +1000 Subject: [Koha-devel] Looking for feedback on approach to Bug 28457 cleanup_database.pl Message-ID: <020e01d752ab$67530be0$35f923a0$@prosentient.com.au> Hi all, I was wondering if someone could give me some feedback on "Bug 28457 - cleanup_database.pl self-registration options are not configurable" (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28457) I like the patch I wrote there, but I wanted to see what other people thought before running it locally. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor at tuxayo.net Sat May 29 22:21:10 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Sat, 29 May 2021 22:21:10 +0200 Subject: [Koha-devel] Deadlock issues when running the tests in parallel, and maybe not only in the tests? In-Reply-To: <39abe900-eaa7-1725-53a0-122dbbd9a768@kohaaloha.com> References: <39abe900-eaa7-1725-53a0-122dbbd9a768@kohaaloha.com> Message-ID: <9939ff85-48b2-01b4-e012-aec635110a24@tuxayo.net> Thanks folks for the replies. So I was running manually the test suite, and used -j from the CI but didn't used --rules so that's why it was failing. -- Victor Grousset/tuxayo From kohanews at gmail.com Sun May 30 17:52:08 2021 From: kohanews at gmail.com (Koha Newsletter) Date: Sun, 30 May 2021 17:52:08 +0200 Subject: [Koha-devel] Koha Community Newsletter: May 2021 Message-ID: The Koha Community Newsletter for May 2021 is here: * https://koha-community.org/koha-community-newsletter-may-2021/ Many thanks to everyone who submitted articles and news to last month's newsletter! Please feel free to email me with any corrections or suggestions. -- Michael Kuhn Editor, Koha Community Newsletter -------------- next part -------------- An HTML attachment was scrubbed... URL: