From kohanews at gmail.com Tue Sep 1 03:08:30 2020 From: kohanews at gmail.com (Koha Newsletter) Date: Mon, 31 Aug 2020 18:08:30 -0700 Subject: [Koha-devel] Koha Community Newsletter: August 2020 Message-ID: The Koha Community Newsletter for August 2020 is here: https://koha-community.org/koha-community-newsletter-august-2020/ 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 From dcook at prosentient.com.au Thu Sep 3 02:53:36 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Thu, 3 Sep 2020 10:53:36 +1000 Subject: [Koha-devel] Is Indexdata's Zebra a dead project? Message-ID: <007001d6818c$a7d09e80$f771db80$@prosentient.com.au> Hi all, I just noticed that Indexdata doesn't provide Zebra packages past Debian Stretch: http://ftp.indexdata.dk/pub/zebra/debian/. The latest Ubuntu package is for 18.04 (Bionic): http://ftp.indexdata.dk/pub/zebra/ubuntu/ In fact, Zebra hasn't been updated since August 2018 according to the changelog: https://software.indexdata.com/zebra/doc/NEWS. In Debian, it looks like Debian 11 Bullseye will have the latest Zebra (2.1.4), so there is that at least. I guess people using Debian 10 Buster will either need to use the buggy Zebra (2.0.59) in Debian or maybe use the Stretch packages from Indexdata. But then from Bullseye onwards there will be the latest Zebra until Debian drops the package I guess. All the more reason to move more to Elasticsearch? David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu Sep 3 09:18:27 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Thu, 3 Sep 2020 17:18:27 +1000 Subject: [Koha-devel] Strange Plack-related bug Message-ID: <00bf01d681c2$6afa37b0$40eea710$@prosentient.com.au> Hi all, I was running Koha Plack on OpenSuse (using CPANed libraries), and I noticed that creating a new authority would take me to /cgi-bin/koha/authorities/detail.pl?authid=1, which then spat out an error in my logs of "Subroutine build_tabs redefined at /path/to/koha/intranet/cgi-bin/authorities/detail.pl line 56." After that, it became impossible to create a new authority via /cgi-bin/koha/authorities/authorities.pl. Seemingly because the build_tabs subroutine had been redefined to be incompatible with authorities.tt. I noticed that this only affected my OpenSuse Koha. It didn't affect Debian or Ubuntu. That makes me think that it's due to an issue with the Plack libraries being used. On Ubuntu I was using 1.0047, on Debian I was using 1.0042, and on OpenSuse I was using 1.0039. My guess is that it's an issue with the older library, but I really don't know. Wondering if anyone else has encountered this particular issue. Same Koha code running on each OS, but yeah. the OpenSuse was having issues that the Debian/Ubuntu didn't. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Thu Sep 3 14:27:36 2020 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Thu, 3 Sep 2020 09:27:36 -0300 Subject: [Koha-devel] Is Indexdata's Zebra a dead project? In-Reply-To: <007001d6818c$a7d09e80$f771db80$@prosentient.com.au> References: <007001d6818c$a7d09e80$f771db80$@prosentient.com.au> Message-ID: Latest commit is from April 8th. I belive it is in maintenance mode only. We deprecated it, though. So focus is on ES integration. El mié., 2 sept. 2020 a las 21:54, escribió: > Hi all, > > > > I just noticed that Indexdata doesn’t provide Zebra packages past Debian > Stretch: http://ftp.indexdata.dk/pub/zebra/debian/. The latest Ubuntu > package is for 18.04 (Bionic): http://ftp.indexdata.dk/pub/zebra/ubuntu/ > > > > In fact, Zebra hasn’t been updated since August 2018 according to the > changelog: https://software.indexdata.com/zebra/doc/NEWS. > > > > In Debian, it looks like Debian 11 Bullseye will have the latest Zebra > (2.1.4), so there is that at least. > > > > I guess people using Debian 10 Buster will either need to use the buggy > Zebra (2.0.59) in Debian or maybe use the Stretch packages from Indexdata. > But then from Bullseye onwards there will be the latest Zebra until Debian > drops the package I guess. > > > > All the more reason to move more to Elasticsearch? > > > > David Cook > > Software Engineer > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > 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 : 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: From katrin.fischer.83 at web.de Thu Sep 3 19:01:53 2020 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Thu, 3 Sep 2020 19:01:53 +0200 Subject: [Koha-devel] Is Indexdata's Zebra a dead project? In-Reply-To: References: <007001d6818c$a7d09e80$f771db80$@prosentient.com.au> Message-ID: <050ace5f-206e-94ea-91fc-accfadbafd67@web.de> Hi Tomas, I don't think that's correct - there was never an official decision on deprecating Zebra. On 03.09.20 14:27, Tomas Cohen Arazi wrote: > Latest commit is from April 8th. I belive it is in maintenance mode only. > We deprecated it, though. So focus is on ES integration. > > El mié., 2 sept. 2020 a las 21:54, > escribió: > > Hi all, > > I just noticed that Indexdata doesn’t provide Zebra packages past > Debian Stretch: http://ftp.indexdata.dk/pub/zebra/debian/. The > latest Ubuntu package is for 18.04 (Bionic): > http://ftp.indexdata.dk/pub/zebra/ubuntu/ > > In fact, Zebra hasn’t been updated since August 2018 according to > the changelog: https://software.indexdata.com/zebra/doc/NEWS. > > In Debian, it looks like Debian 11 Bullseye will have the latest > Zebra (2.1.4), so there is that at least. > > I guess people using Debian 10 Buster will either need to use the > buggy Zebra (2.0.59) in Debian or maybe use the Stretch packages > from Indexdata. But then from Bullseye onwards there will be the > latest Zebra until Debian drops the package I guess. > > All the more reason to move more to Elasticsearch? > > David Cook > > Software Engineer > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > 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 : 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: From martin.renvoize at ptfs-europe.com Thu Sep 3 21:32:39 2020 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Thu, 3 Sep 2020 20:32:39 +0100 Subject: [Koha-devel] Is Indexdata's Zebra a dead project? In-Reply-To: <050ace5f-206e-94ea-91fc-accfadbafd67@web.de> References: <007001d6818c$a7d09e80$f771db80$@prosentient.com.au> <050ace5f-206e-94ea-91fc-accfadbafd67@web.de> Message-ID: I would say it's time to start thinking about alternatives/further encourage the adoption of elastic search and clean up the search code in general. I still have a, perhaps misguided, fondness for zebra. I'm not sure Koha has always used it to its strengths and it certainly has its own issues.. but it is significantly lighter weight to run and has a place as a genuine alternative to the rather heavy elasticsearch.. I'd love to see a lightweight option replace zebra as an option one day but I don't think it's a priority quit yet..might be worth some experimenting though given its dwindling support higher up the river. Just my two pennies, Martin On Thu, 3 Sep 2020, 6:01 pm Katrin Fischer, wrote: > Hi Tomas, I don't think that's correct - there was never an official > decision on deprecating Zebra. > On 03.09.20 14:27, Tomas Cohen Arazi wrote: > > Latest commit is from April 8th. I belive it is in maintenance mode only. > We deprecated it, though. So focus is on ES integration. > > El mié., 2 sept. 2020 a las 21:54, escribió: > >> Hi all, >> >> >> >> I just noticed that Indexdata doesn’t provide Zebra packages past Debian >> Stretch: http://ftp.indexdata.dk/pub/zebra/debian/. The latest Ubuntu >> package is for 18.04 (Bionic): http://ftp.indexdata.dk/pub/zebra/ubuntu/ >> >> >> >> In fact, Zebra hasn’t been updated since August 2018 according to the >> changelog: https://software.indexdata.com/zebra/doc/NEWS. >> >> >> >> In Debian, it looks like Debian 11 Bullseye will have the latest Zebra >> (2.1.4), so there is that at least. >> >> >> >> I guess people using Debian 10 Buster will either need to use the buggy >> Zebra (2.0.59) in Debian or maybe use the Stretch packages from Indexdata. >> But then from Bullseye onwards there will be the latest Zebra until Debian >> drops the package I guess. >> >> >> >> All the more reason to move more to Elasticsearch? >> >> >> >> David Cook >> >> Software Engineer >> >> Prosentient Systems >> >> 72/330 Wattle St >> >> Ultimo, NSW 2007 >> >> 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 : 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 listKoha-devel at lists.koha-community.orghttps://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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisc at catalyst.net.nz Thu Sep 3 21:47:04 2020 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Fri, 04 Sep 2020 07:47:04 +1200 Subject: [Koha-devel] Is Indexdata's Zebra a dead project? In-Reply-To: References: <007001d6818c$a7d09e80$f771db80$@prosentient.com.au> <050ace5f-206e-94ea-91fc-accfadbafd67@web.de> Message-ID: <11B7A093-2655-4AF8-9CA6-59D0397DF372@catalyst.net.nz> Hi all I agree, we do need to work on a lightweight alternative, and until we have one support zebra. The vast majority of Koha libraries will not have the budget to be able to run an elastic search cluster. So while elastic search is definitely great and we should continue to improve our usage of it. The beauty of Koha is we don't leave people behind. Just my 2 cents Chris On 4 September 2020 7:32:39 am NZST, "Renvoize, Martin" wrote: >I would say it's time to start thinking about alternatives/further >encourage the adoption of elastic search and clean up the search code >in >general. > >I still have a, perhaps misguided, fondness for zebra. I'm not sure >Koha >has always used it to its strengths and it certainly has its own >issues.. >but it is significantly lighter weight to run and has a place as a >genuine >alternative to the rather heavy elasticsearch.. I'd love to see a >lightweight option replace zebra as an option one day but I don't think >it's a priority quit yet..might be worth some experimenting though >given >its dwindling support higher up the river. > >Just my two pennies, > >Martin > > > > >On Thu, 3 Sep 2020, 6:01 pm Katrin Fischer, >wrote: > >> Hi Tomas, I don't think that's correct - there was never an official >> decision on deprecating Zebra. >> On 03.09.20 14:27, Tomas Cohen Arazi wrote: >> >> Latest commit is from April 8th. I belive it is in maintenance mode >only. >> We deprecated it, though. So focus is on ES integration. >> >> El mié., 2 sept. 2020 a las 21:54, >escribió: >> >>> Hi all, >>> >>> >>> >>> I just noticed that Indexdata doesn’t provide Zebra packages past >Debian >>> Stretch: http://ftp.indexdata.dk/pub/zebra/debian/. The latest >Ubuntu >>> package is for 18.04 (Bionic): >http://ftp.indexdata.dk/pub/zebra/ubuntu/ >>> >>> >>> >>> In fact, Zebra hasn’t been updated since August 2018 according to >the >>> changelog: https://software.indexdata.com/zebra/doc/NEWS. >>> >>> >>> >>> In Debian, it looks like Debian 11 Bullseye will have the latest >Zebra >>> (2.1.4), so there is that at least. >>> >>> >>> >>> I guess people using Debian 10 Buster will either need to use the >buggy >>> Zebra (2.0.59) in Debian or maybe use the Stretch packages from >Indexdata. >>> But then from Bullseye onwards there will be the latest Zebra until >Debian >>> drops the package I guess. >>> >>> >>> >>> All the more reason to move more to Elasticsearch? >>> >>> >>> >>> David Cook >>> >>> Software Engineer >>> >>> Prosentient Systems >>> >>> 72/330 Wattle St >>> >>> Ultimo, NSW 2007 >>> >>> 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 : 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 >listKoha-devel at lists.koha-community.orghttps://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/ >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer.83 at web.de Thu Sep 3 21:56:51 2020 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Thu, 3 Sep 2020 21:56:51 +0200 Subject: [Koha-devel] Is Indexdata's Zebra a dead project? In-Reply-To: <11B7A093-2655-4AF8-9CA6-59D0397DF372@catalyst.net.nz> References: <007001d6818c$a7d09e80$f771db80$@prosentient.com.au> <050ace5f-206e-94ea-91fc-accfadbafd67@web.de> <11B7A093-2655-4AF8-9CA6-59D0397DF372@catalyst.net.nz> Message-ID: <90e44d05-e007-16e5-ae01-fbb8a9f3bf5d@web.de> Hi all, Martin and Chris said it much better than me - thx for chiming in. Katrin On 03.09.20 21:47, Chris Cormack wrote: > Hi all > > I agree, we do need to work on a lightweight alternative, and until we > have one support zebra. > The vast majority of Koha libraries will not have the budget to be > able to run an elastic search cluster. > So while elastic search is definitely great and we should continue to > improve our usage of it. The beauty of Koha is we don't leave people > behind. > > Just my 2 cents > > Chris > > > > On 4 September 2020 7:32:39 am NZST, "Renvoize, Martin" > wrote: > > I would say it's time to start thinking about alternatives/further > encourage the adoption of elastic search and clean up the search > code in general. > > I still have a, perhaps misguided, fondness for zebra. I'm not > sure Koha has always used it to its strengths and it certainly has > its own issues.. but it is significantly lighter weight to run and > has a place as a genuine alternative to the rather heavy > elasticsearch.. I'd love to see a lightweight option replace zebra > as an option one day but I don't think it's a priority quit > yet..might be worth some experimenting though given its dwindling > support higher up the river. > > Just my two pennies, > > Martin > > > > > On Thu, 3 Sep 2020, 6:01 pm Katrin Fischer, > > wrote: > > Hi Tomas, I don't think that's correct - there was never an > official decision on deprecating Zebra. > > On 03.09.20 14:27, Tomas Cohen Arazi wrote: >> Latest commit is from April 8th. I belive it is in >> maintenance mode only. >> We deprecated it, though. So focus is on ES integration. >> >> El mié., 2 sept. 2020 a las 21:54, > > escribió: >> >> Hi all, >> >> I just noticed that Indexdata doesn’t provide Zebra >> packages past Debian Stretch: >> http://ftp.indexdata.dk/pub/zebra/debian/. The latest >> Ubuntu package is for 18.04 (Bionic): >> http://ftp.indexdata.dk/pub/zebra/ubuntu/ >> >> In fact, Zebra hasn’t been updated since August 2018 >> according to the changelog: >> https://software.indexdata.com/zebra/doc/NEWS. >> >> In Debian, it looks like Debian 11 Bullseye will have the >> latest Zebra (2.1.4), so there is that at least. >> >> I guess people using Debian 10 Buster will either need to >> use the buggy Zebra (2.0.59) in Debian or maybe use the >> Stretch packages from Indexdata. But then from Bullseye >> onwards there will be the latest Zebra until Debian drops >> the package I guess. >> >> All the more reason to move more to Elasticsearch? >> >> David Cook >> >> Software Engineer >> >> Prosentient Systems >> >> 72/330 Wattle St >> >> Ultimo, NSW 2007 >> >> 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 : 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/ > _______________________________________________ > 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/ > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > 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: From dcook at prosentient.com.au Fri Sep 4 02:28:52 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Fri, 4 Sep 2020 10:28:52 +1000 Subject: [Koha-devel] Is Indexdata's Zebra a dead project? In-Reply-To: References: <007001d6818c$a7d09e80$f771db80$@prosentient.com.au> Message-ID: <019801d68252$5d8ed820$18ac8860$@prosentient.com.au> Oh that’s interesting! I see references to Debian Buster in the commit log (https://github.com/indexdata/idzebra/commits/master). I might shoot off an email about getting some updated packages/releases. Can we really call Zebra usage deprecated if it’s still the default stable option for new installations? On the surface, Elasticsearch still seems experimental. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Tomas Cohen Arazi Sent: Thursday, 3 September 2020 10:28 PM To: David Cook Cc: koha-devel Subject: Re: [Koha-devel] Is Indexdata's Zebra a dead project? Latest commit is from April 8th. I belive it is in maintenance mode only. We deprecated it, though. So focus is on ES integration. El mié., 2 sept. 2020 a las 21:54, > escribió: Hi all, I just noticed that Indexdata doesn’t provide Zebra packages past Debian Stretch: http://ftp.indexdata.dk/pub/zebra/debian/. The latest Ubuntu package is for 18.04 (Bionic): http://ftp.indexdata.dk/pub/zebra/ubuntu/ In fact, Zebra hasn’t been updated since August 2018 according to the changelog: https://software.indexdata.com/zebra/doc/NEWS. In Debian, it looks like Debian 11 Bullseye will have the latest Zebra (2.1.4), so there is that at least. I guess people using Debian 10 Buster will either need to use the buggy Zebra (2.0.59) in Debian or maybe use the Stretch packages from Indexdata. But then from Bullseye onwards there will be the latest Zebra until Debian drops the package I guess. All the more reason to move more to Elasticsearch? David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 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 : 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: From tomascohen at gmail.com Fri Sep 4 02:37:41 2020 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Thu, 3 Sep 2020 21:37:41 -0300 Subject: [Koha-devel] Is Indexdata's Zebra a dead project? In-Reply-To: <050ace5f-206e-94ea-91fc-accfadbafd67@web.de> References: <007001d6818c$a7d09e80$f771db80$@prosentient.com.au> <050ace5f-206e-94ea-91fc-accfadbafd67@web.de> Message-ID: I answered this because on some bug (which one I don't remember) I was told we shouldn't 'add features' to Zebra code. But I need to dig a bit to remember. It might have been a communication issue, but we haven't been adding features to Zebra code On Thu, Sep 3, 2020, 14:02 Katrin Fischer wrote: > Hi Tomas, I don't think that's correct - there was never an official > decision on deprecating Zebra. > On 03.09.20 14:27, Tomas Cohen Arazi wrote: > > Latest commit is from April 8th. I belive it is in maintenance mode only. > We deprecated it, though. So focus is on ES integration. > > El mié., 2 sept. 2020 a las 21:54, escribió: > >> Hi all, >> >> >> >> I just noticed that Indexdata doesn’t provide Zebra packages past Debian >> Stretch: http://ftp.indexdata.dk/pub/zebra/debian/. The latest Ubuntu >> package is for 18.04 (Bionic): http://ftp.indexdata.dk/pub/zebra/ubuntu/ >> >> >> >> In fact, Zebra hasn’t been updated since August 2018 according to the >> changelog: https://software.indexdata.com/zebra/doc/NEWS. >> >> >> >> In Debian, it looks like Debian 11 Bullseye will have the latest Zebra >> (2.1.4), so there is that at least. >> >> >> >> I guess people using Debian 10 Buster will either need to use the buggy >> Zebra (2.0.59) in Debian or maybe use the Stretch packages from Indexdata. >> But then from Bullseye onwards there will be the latest Zebra until Debian >> drops the package I guess. >> >> >> >> All the more reason to move more to Elasticsearch? >> >> >> >> David Cook >> >> Software Engineer >> >> Prosentient Systems >> >> 72/330 Wattle St >> >> Ultimo, NSW 2007 >> >> 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 : 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 listKoha-devel at lists.koha-community.orghttps://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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Fri Sep 4 04:37:45 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Fri, 4 Sep 2020 12:37:45 +1000 Subject: [Koha-devel] Apache directive TimeOut works differently when using mod_cgi (CGI) vs mod_proxy_http (Plack) Message-ID: <01ab01d68264$5ee84870$1cb8d950$@prosentient.com.au> Hi all, While troubleshooting Apache TimeOut for Plack vs CGI (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26128), I discovered that Apache seems to respect TimeOut when measuring a timeout proxying requests to Plack. However, it actually *doubles* the time when running CGI scripts on its own. I've looked through the Apache httpd and apr source code, and it's not obvious to me at a glance why this happens, but I think it's important for us to realize this, because it means the solution presented by "Make processes that rely on background jobs run in CGI mode" https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15218 might not always be necessary. Based on my investigation, it seems the reason some scripts work in CGI but not in Plack is simply because of the different way timeouts occur. If we just raise the ProxyTimeout to twice the value of TimeOut (ie change it to 600 to be 2*TimeOut), then we'll be getting the same behaviour. Of course, the real solution in these cases is still to use asynchronous processing via "Add a task queue" (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417). In any case, I thought it was important to share my findings, because it means we might actually be able to reduce our dependency on CGI now even before Bug 22417 is pushed. Thank you, David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Fri Sep 4 05:47:07 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Fri, 4 Sep 2020 13:47:07 +1000 Subject: [Koha-devel] Apache directive TimeOut works differently when using mod_cgi (CGI) vs mod_proxy_http (Plack) In-Reply-To: <01ab01d68264$5ee84870$1cb8d950$@prosentient.com.au> References: <01ab01d68264$5ee84870$1cb8d950$@prosentient.com.au> Message-ID: <01bf01d6826e$100d9f70$3028de50$@prosentient.com.au> Note I've opened an ASF Bugzilla bug report about this mod_cgi TimeOut handling: https://bz.apache.org/bugzilla/show_bug.cgi?id=64709 David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of dcook at prosentient.com.au Sent: Friday, 4 September 2020 12:38 PM To: 'koha-devel' Cc: 'Kyle Hall' ; 'Tomas Cohen Arazi' Subject: [Koha-devel] Apache directive TimeOut works differently when using mod_cgi (CGI) vs mod_proxy_http (Plack) Hi all, While troubleshooting Apache TimeOut for Plack vs CGI (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26128), I discovered that Apache seems to respect TimeOut when measuring a timeout proxying requests to Plack. However, it actually *doubles* the time when running CGI scripts on its own. I've looked through the Apache httpd and apr source code, and it's not obvious to me at a glance why this happens, but I think it's important for us to realize this, because it means the solution presented by "Make processes that rely on background jobs run in CGI mode" https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15218 might not always be necessary. Based on my investigation, it seems the reason some scripts work in CGI but not in Plack is simply because of the different way timeouts occur. If we just raise the ProxyTimeout to twice the value of TimeOut (ie change it to 600 to be 2*TimeOut), then we'll be getting the same behaviour. Of course, the real solution in these cases is still to use asynchronous processing via "Add a task queue" (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417). In any case, I thought it was important to share my findings, because it means we might actually be able to reduce our dependency on CGI now even before Bug 22417 is pushed. Thank you, David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Fri Sep 4 06:18:29 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Fri, 4 Sep 2020 14:18:29 +1000 Subject: [Koha-devel] Is Indexdata's Zebra a dead project? In-Reply-To: References: <007001d6818c$a7d09e80$f771db80$@prosentient.com.au> <050ace5f-206e-94ea-91fc-accfadbafd67@web.de> Message-ID: <01cd01d68272$716b7a40$54426ec0$@prosentient.com.au> That does sound familiar, although I wonder what sort of features were in mind… David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Tomas Cohen Arazi Sent: Friday, 4 September 2020 10:38 AM To: Katrin Fischer Cc: koha-devel Subject: Re: [Koha-devel] Is Indexdata's Zebra a dead project? I answered this because on some bug (which one I don't remember) I was told we shouldn't 'add features' to Zebra code. But I need to dig a bit to remember. It might have been a communication issue, but we haven't been adding features to Zebra code On Thu, Sep 3, 2020, 14:02 Katrin Fischer > wrote: Hi Tomas, I don't think that's correct - there was never an official decision on deprecating Zebra. On 03.09.20 14:27, Tomas Cohen Arazi wrote: Latest commit is from April 8th. I belive it is in maintenance mode only. We deprecated it, though. So focus is on ES integration. El mié., 2 sept. 2020 a las 21:54, > escribió: Hi all, I just noticed that Indexdata doesn’t provide Zebra packages past Debian Stretch: http://ftp.indexdata.dk/pub/zebra/debian/. The latest Ubuntu package is for 18.04 (Bionic): http://ftp.indexdata.dk/pub/zebra/ubuntu/ In fact, Zebra hasn’t been updated since August 2018 according to the changelog: https://software.indexdata.com/zebra/doc/NEWS. In Debian, it looks like Debian 11 Bullseye will have the latest Zebra (2.1.4), so there is that at least. I guess people using Debian 10 Buster will either need to use the buggy Zebra (2.0.59) in Debian or maybe use the Stretch packages from Indexdata. But then from Bullseye onwards there will be the latest Zebra until Debian drops the package I guess. All the more reason to move more to Elasticsearch? David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 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 : 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/ _______________________________________________ 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: From dcook at prosentient.com.au Fri Sep 4 06:20:24 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Fri, 4 Sep 2020 14:20:24 +1000 Subject: [Koha-devel] Is Indexdata's Zebra a dead project? In-Reply-To: References: <007001d6818c$a7d09e80$f771db80$@prosentient.com.au> <050ace5f-206e-94ea-91fc-accfadbafd67@web.de> Message-ID: <01d201d68272$b65b7ce0$231276a0$@prosentient.com.au> I know what you mean, and I totally agree about Koha not using Zebra to its strengths. That said, Zebra does have some annoying limitations, although I have thought how some of those could be worked around by wrapping Zebra with another program (or even writing features and upstreaming them. I’d just need to brush up on my C skills). David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Renvoize, Martin Sent: Friday, 4 September 2020 5:33 AM To: Koha Devel Subject: Re: [Koha-devel] Is Indexdata's Zebra a dead project? I would say it's time to start thinking about alternatives/further encourage the adoption of elastic search and clean up the search code in general. I still have a, perhaps misguided, fondness for zebra. I'm not sure Koha has always used it to its strengths and it certainly has its own issues.. but it is significantly lighter weight to run and has a place as a genuine alternative to the rather heavy elasticsearch.. I'd love to see a lightweight option replace zebra as an option one day but I don't think it's a priority quit yet..might be worth some experimenting though given its dwindling support higher up the river. Just my two pennies, Martin On Thu, 3 Sep 2020, 6:01 pm Katrin Fischer, > wrote: Hi Tomas, I don't think that's correct - there was never an official decision on deprecating Zebra. On 03.09.20 14:27, Tomas Cohen Arazi wrote: Latest commit is from April 8th. I belive it is in maintenance mode only. We deprecated it, though. So focus is on ES integration. El mié., 2 sept. 2020 a las 21:54, > escribió: Hi all, I just noticed that Indexdata doesn’t provide Zebra packages past Debian Stretch: http://ftp.indexdata.dk/pub/zebra/debian/. The latest Ubuntu package is for 18.04 (Bionic): http://ftp.indexdata.dk/pub/zebra/ubuntu/ In fact, Zebra hasn’t been updated since August 2018 according to the changelog: https://software.indexdata.com/zebra/doc/NEWS. In Debian, it looks like Debian 11 Bullseye will have the latest Zebra (2.1.4), so there is that at least. I guess people using Debian 10 Buster will either need to use the buggy Zebra (2.0.59) in Debian or maybe use the Stretch packages from Indexdata. But then from Bullseye onwards there will be the latest Zebra until Debian drops the package I guess. All the more reason to move more to Elasticsearch? David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 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 : 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/ _______________________________________________ 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: From dcook at prosentient.com.au Fri Sep 4 08:26:14 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Fri, 4 Sep 2020 16:26:14 +1000 Subject: [Koha-devel] Using Template::Toolkit WRAPPER in Koha plugins Message-ID: <01ef01d68284$4a59ee70$df0dcb50$@prosentient.com.au> Hi all, I just wanted to share how I've used Template::Toolkit WRAPPER in a Koha plugin. All the details are available at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26381, but basically it boils down to creating 1 wrapper template, and then invoking that using the WRAPPER directive in individual Koha plugin templates like report-step1.tt. It reduces the boiler plate required for each plugin template whether that wrapper template is provided by the Koha plugin or by Koha (both approaches have pros and cons). For a long time, I've wanted to use WRAPPER with Koha more broadly, but Koha plugins provide a great opportunity for using them with no refactoring of existing code. Anyway, I hope that others find this useful. I'm going to have a bit of fun with it. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Sep 7 04:09:07 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Mon, 7 Sep 2020 12:09:07 +1000 Subject: [Koha-devel] Add ProxyTimeout to Plack Koha due to mod_cgi bug Message-ID: <026001d684bb$de1865e0$9a4931a0$@prosentient.com.au> Hi all, Last week, I discovered a bug in Apache httpd's mod_cgi. Basically, it means that mod_cgi does not timeout until 2x the duration of TimeOut, while mod_proxy_http (used by Plack) times out after 1x the duration of TimeOut. You can see the details at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26400. The Apache community worked very quickly, and together we've resolved the bug, but I don't think Apache backport fixes. That said, there's been an open bug report in Debian for 5 years (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780123). I'll send an email in telling them that this has been fixed upstream. I wouldn't count on a backport though. In any case, the real importance here is that we harmonize people's expectations. With Bug 15218, we started using CGI mode for certain long-running processes. It might be that this isn't 100% necessary in all cases, if we just increase the ProxyTimeout to match the effective TimeOut time of CGI processes. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joonas.kylmala at helsinki.fi Mon Sep 7 11:54:56 2020 From: joonas.kylmala at helsinki.fi (=?UTF-8?Q?Joonas_Kylm=c3=a4l=c3=a4?=) Date: Mon, 7 Sep 2020 12:54:56 +0300 Subject: [Koha-devel] Request for sign-off: component part records feature (Bug 11175) Message-ID: Hi, there has been this long-standing feature pending from 2013 for Koha for listing component part records in the host record biblio details page. I have rescued the original patches by submitting follow-ups but now I haven't got any sign-offs for 2 months. I think the issue is that this needs developers to do the sign-off since the zebra index needs to be re-indexed to test this. So if you are a developer of a library that uses component part records I would like to ask you take a look at this bug 11175 [1] and sign-off if you just can! Thanks already beforehand! :) [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 -- Joonas Kylmälä Tietojärjestelmäasiantuntija Kansalliskirjasto Kirjastoverkkopalvelut PL 15 (Unioninkatu 36) 00014 Helsingin yliopisto From ola.andersson at ltu.se Mon Sep 7 16:40:56 2020 From: ola.andersson at ltu.se (Ola Andersson) Date: Mon, 7 Sep 2020 14:40:56 +0000 Subject: [Koha-devel] Review on Koha Order Module/plugin API Message-ID: Dear Koha Developers, Here in Sweden we have started a task group in the Swedish Koha User Group to build a Order module/plugin to Koha that allow automatic influx of order data directly from a book vendor into Koha. The API draft is described here: https://docs.google.com/document/d/13EIWxTlN3Wo-8OtJuwu5serQu-dl-zdpK1qY5BNs0dk/edit#heading=h.jtxo4681sgpr We have had it posted for review in the Swedish user group - but we are thinking it would be valuable to get the larger Koha community to give feedback before we hire contractors to build the module/plugin. Please share thoughts on the API and how to best implement it in Koha from a developer/QA perspective. All comments are appreciated and anyone looking at the Google docs above can send comments/suggestions into the document. When the API is becoming more stable and comments have been looked at we could move it into the Koha wiki site. Please leave comments before 21 September 2020. /Swedish Koha User Group - the book vendor module/plugin task group -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthur.suzuki at biblibre.com Mon Sep 7 17:13:47 2020 From: arthur.suzuki at biblibre.com (Arthur Suzuki) Date: Mon, 7 Sep 2020 17:13:47 +0200 Subject: [Koha-devel] Review on Koha Order Module/plugin API In-Reply-To: References: Message-ID: <08af7c7d-484a-9fd8-9763-48b0f04b2a2b@biblibre.com> Hello Ola, I have no idea of what the final purpose is but I kind of understood from your document you want to achieve automatic input of biblio data from vendors directly. https://wiki.koha-community.org/wiki/Biblios_endpoint_RFC The route to get biblio data from koha is implemented in 19.11 but the one to push to koha is still missing (can't find out which bz it is). I'd be really interested into seeing some community route implementing order operations through the api. There is already one existing to interact with Koha vendor data, if of any help: https://wiki.koha-community.org/wiki/Acquisitions_vendors_endpoint_RFC -> implemented One of my concern, the one implementing purchase suggestions operation is also still a big work in progress: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17314 Maybe nice to file a bug in bugzilla like "Route to create, list, update, delete an order basket" or something of the like so that anyone can followup? If you do so, please add me to the CC's :) Kind regards, Arthur On 07/09/2020 16:40, Ola Andersson wrote: > > Dear Koha Developers, > >   > > Here in Sweden we have started a task group in the Swedish Koha User > Group to build a Order module/plugin to Koha that allow automatic > influx of order data directly from a book vendor into Koha. > >   > > The APIdraft is described here: > https://docs.google.com/document/d/13EIWxTlN3Wo-8OtJuwu5serQu-dl-zdpK1qY5BNs0dk/edit#heading=h.jtxo4681sgpr > >   > > We have had it posted for review in the Swedish user group – but we > are thinking it would be valuable to get the larger Koha community to > give feedback before we hire contractors to build the module/plugin. > >   > > Pleaseshare thoughts on the API and how to best implement it in Koha > from a developer/QA perspective. All comments are appreciated and > anyone looking at the Google docs above can send comments/suggestions > into the document. > >   > > When the API is becoming more stable and comments have been looked at > we could move it into the Koha wiki site. > >   > > Please leave comments before 21 September 2020. > >   > > /Swedish Koha User Group – the book vendor module/plugin task group > > > _______________________________________________ > 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: From dcook at prosentient.com.au Tue Sep 8 03:27:17 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 8 Sep 2020 11:27:17 +1000 Subject: [Koha-devel] Request for sign-off: component part records feature (Bug 11175) In-Reply-To: References: Message-ID: <030e01d6857f$306d7970$91486c50$@prosentient.com.au> Hi Joonas, I've taken another look at the report (my last look was in 2014), but I don't think that this is the right approach. It also doesn't take into account Elasticsearch. I might be wrong, but I don't imagine that this would pass QA or be pushed to master. I'm actually tempted to mark it as "In Discussion" to be honest. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Koha-devel On Behalf Of Joonas Kylmälä Sent: Monday, 7 September 2020 7:55 PM To: koha-devel Subject: [Koha-devel] Request for sign-off: component part records feature (Bug 11175) Hi, there has been this long-standing feature pending from 2013 for Koha for listing component part records in the host record biblio details page. I have rescued the original patches by submitting follow-ups but now I haven't got any sign-offs for 2 months. I think the issue is that this needs developers to do the sign-off since the zebra index needs to be re-indexed to test this. So if you are a developer of a library that uses component part records I would like to ask you take a look at this bug 11175 [1] and sign-off if you just can! Thanks already beforehand! :) [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 -- Joonas Kylmälä Tietojärjestelmäasiantuntija Kansalliskirjasto Kirjastoverkkopalvelut PL 15 (Unioninkatu 36) 00014 Helsingin yliopisto _______________________________________________ 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 dcook at prosentient.com.au Tue Sep 8 03:43:47 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 8 Sep 2020 11:43:47 +1000 Subject: [Koha-devel] Review on Koha Order Module/plugin API In-Reply-To: References: Message-ID: <030f01d68581$7e81a7b0$7b84f710$@prosentient.com.au> Hi Ola, I've only skimmed the document, but I really dislike the proposal. It's not really describing an API. It's describing a non-standard workaround. I've seen integrations like this before, but I wouldn't recommend them, especially not for a new development. I'd suggest that the Koha plugin provides an API where the Vendor Service can send the JSON in the body of a background POST request using AJAX. Once that POST request is complete, they could then offer a link to navigate to Koha. That link would be to the Koha plugin and include an identifier returned by the earlier AJAX POST request. In Koha, the user logs in and sees the Vendor Service order as shown by the Koha plugin, and then you can action that order from there however you like. Easy. You would need to provide authentication credentials to the Vendor Service, but that's a reasonable thing to do when consuming an API. I hope that helps. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Ola Andersson Sent: Tuesday, 8 September 2020 12:41 AM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] Review on Koha Order Module/plugin API Importance: High Dear Koha Developers, Here in Sweden we have started a task group in the Swedish Koha User Group to build a Order module/plugin to Koha that allow automatic influx of order data directly from a book vendor into Koha. The API draft is described here: https://docs.google.com/document/d/13EIWxTlN3Wo-8OtJuwu5serQu-dl-zdpK1qY5BNs 0dk/edit#heading=h.jtxo4681sgpr We have had it posted for review in the Swedish user group - but we are thinking it would be valuable to get the larger Koha community to give feedback before we hire contractors to build the module/plugin. Please share thoughts on the API and how to best implement it in Koha from a developer/QA perspective. All comments are appreciated and anyone looking at the Google docs above can send comments/suggestions into the document. When the API is becoming more stable and comments have been looked at we could move it into the Koha wiki site. Please leave comments before 21 September 2020. /Swedish Koha User Group - the book vendor module/plugin task group -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Tue Sep 8 08:07:11 2020 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 8 Sep 2020 18:07:11 +1200 Subject: [Koha-devel] Review on Koha Order Module/plugin API In-Reply-To: <08af7c7d-484a-9fd8-9763-48b0f04b2a2b@biblibre.com> References: <08af7c7d-484a-9fd8-9763-48b0f04b2a2b@biblibre.com> Message-ID: Kia ora Ola (and the Swedish Koha users group) First of all I'd like to say its great to see you are wanting to help improve Koha. I haven't had a chance to read the full proposal, but it's great to see anyone wanting to contribute. Ill try to have a proper read and leave some feedback. Ngā mihi mahana Chris On Tue, 8 Sep 2020, 3:13 am Arthur Suzuki, wrote: > Hello Ola, > > I have no idea of what the final purpose is but I kind of understood from > your document you want to achieve automatic input of biblio data from > vendors directly. > > https://wiki.koha-community.org/wiki/Biblios_endpoint_RFC > > The route to get biblio data from koha is implemented in 19.11 but the one > to push to koha is still missing (can't find out which bz it is). > > I'd be really interested into seeing some community route implementing > order operations through the api. > > There is already one existing to interact with Koha vendor data, if of any > help: > > https://wiki.koha-community.org/wiki/Acquisitions_vendors_endpoint_RFC -> > implemented > > One of my concern, the one implementing purchase suggestions operation is > also still a big work in progress: > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17314 > > Maybe nice to file a bug in bugzilla like "Route to create, list, update, > delete an order basket" or something of the like so that anyone can > followup? If you do so, please add me to the CC's :) > > Kind regards, > > Arthur > On 07/09/2020 16:40, Ola Andersson wrote: > > Dear Koha Developers, > > > > Here in Sweden we have started a task group in the Swedish Koha User > Group to build a Order module/plugin to Koha that allow automatic influx of > order data directly from a book vendor into Koha. > > > > The API draft is described here: > https://docs.google.com/document/d/13EIWxTlN3Wo-8OtJuwu5serQu-dl-zdpK1qY5BNs0dk/edit#heading=h.jtxo4681sgpr > > > > We have had it posted for review in the Swedish user group – but we are > thinking it would be valuable to get the larger Koha community to give > feedback before we hire contractors to build the module/plugin. > > > > Please share thoughts on the API and how to best implement it in Koha > from a developer/QA perspective. All comments are appreciated and anyone > looking at the Google docs above can send comments/suggestions into the > document. > > > > When the API is becoming more stable and comments have been looked at we > could move it into the Koha wiki site. > > > > Please leave comments before 21 September 2020. > > > > /Swedish Koha User Group – the book vendor module/plugin task group > > _______________________________________________ > Koha-devel mailing listKoha-devel at lists.koha-community.orghttps://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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joonas.kylmala at helsinki.fi Tue Sep 8 09:09:50 2020 From: joonas.kylmala at helsinki.fi (=?UTF-8?Q?Joonas_Kylm=c3=a4l=c3=a4?=) Date: Tue, 8 Sep 2020 10:09:50 +0300 Subject: [Koha-devel] Request for sign-off: component part records feature (Bug 11175) In-Reply-To: <030e01d6857f$306d7970$91486c50$@prosentient.com.au> References: <030e01d6857f$306d7970$91486c50$@prosentient.com.au> Message-ID: <5e484637-2dfa-f776-1866-00afd9115e69@helsinki.fi> Hi, thanks for taking a look! There is already some discussion in the bug report about Elasticsearch and about the backend implementation but that is from 2018 and earlier so I'm not sure it is up to date and is that's why you have concerns about the approach? Please let us know in the bug report comments, and feel free to mark "In discussion" if needed. Also please see comment 59 for why I decided to rescue this and whether it is okay in your opinion. Joonas On 08/09/2020 04:27, dcook at prosentient.com.au wrote: > Hi Joonas, > > I've taken another look at the report (my last look was in 2014), but I don't think that this is the right approach. It also doesn't take into account Elasticsearch. > > I might be wrong, but I don't imagine that this would pass QA or be pushed to master. I'm actually tempted to mark it as "In Discussion" to be honest. > > David Cook > Software Engineer > Prosentient Systems > 72/330 Wattle St > Ultimo, NSW 2007 > Australia > > Office: 02 9212 0899 > Online: 02 8005 0595 -- Joonas Kylmälä Tietojärjestelmäasiantuntija Kansalliskirjasto Kirjastoverkkopalvelut PL 15 (Unioninkatu 36) 00014 Helsingin yliopisto From dcook at prosentient.com.au Tue Sep 8 09:15:24 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 8 Sep 2020 17:15:24 +1000 Subject: [Koha-devel] Request for sign-off: component part records feature (Bug 11175) In-Reply-To: <5e484637-2dfa-f776-1866-00afd9115e69@helsinki.fi> References: <030e01d6857f$306d7970$91486c50$@prosentient.com.au> <5e484637-2dfa-f776-1866-00afd9115e69@helsinki.fi> Message-ID: <039001d685af$d249a0e0$76dce2a0$@prosentient.com.au> Hi Joonas, I've just taken a look at comment 59 but I'm not sure why you decided to rescue it based on that comment. I'm happy to leave some feedback on the bug report. I'll do that quickly now. Cheers, David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Joonas Kylmälä Sent: Tuesday, 8 September 2020 5:10 PM To: dcook at prosentient.com.au Cc: 'koha-devel' Subject: Re: [Koha-devel] Request for sign-off: component part records feature (Bug 11175) Hi, thanks for taking a look! There is already some discussion in the bug report about Elasticsearch and about the backend implementation but that is from 2018 and earlier so I'm not sure it is up to date and is that's why you have concerns about the approach? Please let us know in the bug report comments, and feel free to mark "In discussion" if needed. Also please see comment 59 for why I decided to rescue this and whether it is okay in your opinion. Joonas On 08/09/2020 04:27, dcook at prosentient.com.au wrote: > Hi Joonas, > > I've taken another look at the report (my last look was in 2014), but I don't think that this is the right approach. It also doesn't take into account Elasticsearch. > > I might be wrong, but I don't imagine that this would pass QA or be pushed to master. I'm actually tempted to mark it as "In Discussion" to be honest. > > David Cook > Software Engineer > Prosentient Systems > 72/330 Wattle St > Ultimo, NSW 2007 > Australia > > Office: 02 9212 0899 > Online: 02 8005 0595 -- Joonas Kylmälä Tietojärjestelmäasiantuntija Kansalliskirjasto Kirjastoverkkopalvelut PL 15 (Unioninkatu 36) 00014 Helsingin yliopisto From joonas.kylmala at helsinki.fi Tue Sep 8 09:19:47 2020 From: joonas.kylmala at helsinki.fi (=?UTF-8?Q?Joonas_Kylm=c3=a4l=c3=a4?=) Date: Tue, 8 Sep 2020 10:19:47 +0300 Subject: [Koha-devel] Request for sign-off: component part records feature (Bug 11175) In-Reply-To: <039001d685af$d249a0e0$76dce2a0$@prosentient.com.au> References: <030e01d6857f$306d7970$91486c50$@prosentient.com.au> <5e484637-2dfa-f776-1866-00afd9115e69@helsinki.fi> <039001d685af$d249a0e0$76dce2a0$@prosentient.com.au> Message-ID: <2ba05db8-481f-a983-7069-de0d990846ef@helsinki.fi> Hi, On 08/09/2020 10:15, dcook at prosentient.com.au wrote: > I've just taken a look at comment 59 but I'm not sure why you decided to rescue it based on that comment. I did it so that the GUI code does not need to be rewritten because it takes time. > I'm happy to leave some feedback on the bug report. I'll do that quickly now. Thanks! -- Joonas Kylmälä Tietojärjestelmäasiantuntija Kansalliskirjasto Kirjastoverkkopalvelut PL 15 (Unioninkatu 36) 00014 Helsingin yliopisto From dcook at prosentient.com.au Tue Sep 8 09:30:03 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 8 Sep 2020 17:30:03 +1000 Subject: [Koha-devel] Request for sign-off: component part records feature (Bug 11175) In-Reply-To: <2ba05db8-481f-a983-7069-de0d990846ef@helsinki.fi> References: <030e01d6857f$306d7970$91486c50$@prosentient.com.au> <5e484637-2dfa-f776-1866-00afd9115e69@helsinki.fi> <039001d685af$d249a0e0$76dce2a0$@prosentient.com.au> <2ba05db8-481f-a983-7069-de0d990846ef@helsinki.fi> Message-ID: <039301d685b1$de0e40f0$9a2ac2d0$@prosentient.com.au> Hi Joonas, I've left a comment. After re-reading the code, I think I can see your perspective. I don't love the patches, but I'm not going to stand in their way either. I can always just leave the system preference turned off. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Joonas Kylmälä Sent: Tuesday, 8 September 2020 5:20 PM To: dcook at prosentient.com.au Cc: 'koha-devel' Subject: Re: [Koha-devel] Request for sign-off: component part records feature (Bug 11175) Hi, On 08/09/2020 10:15, dcook at prosentient.com.au wrote: > I've just taken a look at comment 59 but I'm not sure why you decided to rescue it based on that comment. I did it so that the GUI code does not need to be rewritten because it takes time. > I'm happy to leave some feedback on the bug report. I'll do that quickly now. Thanks! -- Joonas Kylmälä Tietojärjestelmäasiantuntija Kansalliskirjasto Kirjastoverkkopalvelut PL 15 (Unioninkatu 36) 00014 Helsingin yliopisto From jonathan.druart at bugs.koha-community.org Tue Sep 8 11:25:55 2020 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Tue, 8 Sep 2020 11:25:55 +0200 Subject: [Koha-devel] Cleaning git project list Message-ID: Hello everybody, As you may know I am migrating the git server to a new fresh one. Do you know any good reasons to keep one of the following git projects: mm/jcamins.git MM repo for authorities Jared Camins-Esakov 6 years ago mm/chrisc.git MM repo for testing Chris Cormack 6 years agolog | tree koha-archive.git Old Koha topic branches Koha Project 7 years ago wip/koha-equinox.git Equinox work in progress Galen Charlton 7 years ago koha-small.git main Koha release repository Koha Project 8 years ago wip/koha-catalyst.git Catalyst work in progress Chris Cormack 8 years ago wip/koha-chris_n.git Personal work in progress Chris Nighswonger 8 years ago wip/koha-biblibre.git BibLibre work in progress Henri-Damien Laurent 9 years ago wip/koha-fbc.git Foundations Bible College... Chris Nighswonger 9 years ago wip/koha-ptfs.git PTFS work in progress J. David Bavousett 10 years ago http://git.koha-community.org/gitweb/?p=koha-archive.git;a=summary They all seem very old and no longer used. Moreover they don't seem to contain useful history information. If you have any doubts please let me know and I will keep them (or some)! Cheers, Jonathan From chris at bigballofwax.co.nz Tue Sep 8 11:33:47 2020 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 8 Sep 2020 21:33:47 +1200 Subject: [Koha-devel] Cleaning git project list In-Reply-To: References: Message-ID: Please keep the archive one. Chris On Tue, 8 Sep 2020, 9:26 pm Jonathan Druart, < jonathan.druart at bugs.koha-community.org> wrote: > Hello everybody, > > As you may know I am migrating the git server to a new fresh one. > > Do you know any good reasons to keep one of the following git projects: > > mm/jcamins.git MM repo for authorities Jared Camins-Esakov > 6 years ago > mm/chrisc.git MM repo for testing Chris Cormack 6 years > agolog | tree > koha-archive.git Old Koha topic branches Koha Project 7 years > ago > wip/koha-equinox.git Equinox work in progress Galen Charlton > 7 years ago > koha-small.git main Koha release repository Koha Project 8 > years ago > wip/koha-catalyst.git Catalyst work in progress Chris Cormack > 8 years ago > wip/koha-chris_n.git Personal work in progress Chris > Nighswonger 8 years ago > wip/koha-biblibre.git BibLibre work in progress Henri-Damien > Laurent 9 years ago > wip/koha-fbc.git Foundations Bible College... Chris > Nighswonger 9 years ago > wip/koha-ptfs.git PTFS work in progress J. David Bavousett > 10 years ago > > http://git.koha-community.org/gitweb/?p=koha-archive.git;a=summary > > They all seem very old and no longer used. Moreover they don't seem to > contain useful history information. > > If you have any doubts please let me know and I will keep them (or some)! > > 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 : 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: From martin.renvoize at ptfs-europe.com Tue Sep 8 12:09:27 2020 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Tue, 8 Sep 2020 11:09:27 +0100 Subject: [Koha-devel] Review on Koha Order Module/plugin API In-Reply-To: References: <08af7c7d-484a-9fd8-9763-48b0f04b2a2b@biblibre.com> Message-ID: Hi Ola, Firstly, it's great to see the Swedish users group getting involved and asking for feedback. Everyone works better when we all work together. I'm still digesting the proposal as it stands, but I don't see any issues with anything that expands the API capabitiies of Koha.. As Arthur suggested, it would be great to see enhancements exposing some more of the acquisitions functionality via the existing REST developments. I'm not entirely sure I understand the suggested flow however; but it does sounds sami-familiar as a flow from my work with EDI. Have you considered what already exists in Koha? Do Swedish vendors support EDI at all and could this perhaps be an option..? I'm sure there's an ORDER message flow that allows for vendor first interactions where you create a basket of items at the vendor, then Koha grabs that basket to allow the Koha end processing and pushed it back to the vendor for the next step etc. I'll keep an eye on this discussion and contribute what I can, many thanks for the inclusion. *Martin Renvoize* Development Team Manager Community Release Manager (19.11, 20.05) *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 Tue, 8 Sep 2020 at 07:07, Chris Cormack wrote: > Kia ora Ola (and the Swedish Koha users group) > > First of all I'd like to say its great to see you are wanting to help > improve Koha. > I haven't had a chance to read the full proposal, but it's great to see > anyone wanting to contribute. > > Ill try to have a proper read and leave some feedback. > > Ngā mihi mahana > Chris > > On Tue, 8 Sep 2020, 3:13 am Arthur Suzuki, > wrote: > >> Hello Ola, >> >> I have no idea of what the final purpose is but I kind of understood from >> your document you want to achieve automatic input of biblio data from >> vendors directly. >> >> https://wiki.koha-community.org/wiki/Biblios_endpoint_RFC >> >> The route to get biblio data from koha is implemented in 19.11 but the >> one to push to koha is still missing (can't find out which bz it is). >> >> I'd be really interested into seeing some community route implementing >> order operations through the api. >> >> There is already one existing to interact with Koha vendor data, if of >> any help: >> >> https://wiki.koha-community.org/wiki/Acquisitions_vendors_endpoint_RFC >> -> implemented >> >> One of my concern, the one implementing purchase suggestions operation is >> also still a big work in progress: >> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17314 >> >> Maybe nice to file a bug in bugzilla like "Route to create, list, update, >> delete an order basket" or something of the like so that anyone can >> followup? If you do so, please add me to the CC's :) >> >> Kind regards, >> >> Arthur >> On 07/09/2020 16:40, Ola Andersson wrote: >> >> Dear Koha Developers, >> >> >> >> Here in Sweden we have started a task group in the Swedish Koha User >> Group to build a Order module/plugin to Koha that allow automatic influx of >> order data directly from a book vendor into Koha. >> >> >> >> The API draft is described here: >> https://docs.google.com/document/d/13EIWxTlN3Wo-8OtJuwu5serQu-dl-zdpK1qY5BNs0dk/edit#heading=h.jtxo4681sgpr >> >> >> >> We have had it posted for review in the Swedish user group – but we are >> thinking it would be valuable to get the larger Koha community to give >> feedback before we hire contractors to build the module/plugin. >> >> >> >> Please share thoughts on the API and how to best implement it in Koha >> from a developer/QA perspective. All comments are appreciated and anyone >> looking at the Google docs above can send comments/suggestions into the >> document. >> >> >> >> When the API is becoming more stable and comments have been looked at we >> could move it into the Koha wiki site. >> >> >> >> Please leave comments before 21 September 2020. >> >> >> >> /Swedish Koha User Group – the book vendor module/plugin task group >> >> _______________________________________________ >> Koha-devel mailing listKoha-devel at lists.koha-community.orghttps://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/ >> > _______________________________________________ > 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: From martin.renvoize at ptfs-europe.com Tue Sep 8 12:43:55 2020 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Tue, 8 Sep 2020 11:43:55 +0100 Subject: [Koha-devel] Request for sign-off: component part records feature (Bug 11175) In-Reply-To: <039301d685b1$de0e40f0$9a2ac2d0$@prosentient.com.au> References: <030e01d6857f$306d7970$91486c50$@prosentient.com.au> <5e484637-2dfa-f776-1866-00afd9115e69@helsinki.fi> <039001d685af$d249a0e0$76dce2a0$@prosentient.com.au> <2ba05db8-481f-a983-7069-de0d990846ef@helsinki.fi> <039301d685b1$de0e40f0$9a2ac2d0$@prosentient.com.au> Message-ID: Replied on the bug.. looks pretty good to me; It was another one that had just dropped off my radar, thanks for raising it. *Martin Renvoize* Development Team Manager Community Release Manager (19.11, 20.05) *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 Tue, 8 Sep 2020 at 08:30, wrote: > Hi Joonas, > > I've left a comment. After re-reading the code, I think I can see your > perspective. > > I don't love the patches, but I'm not going to stand in their way either. > I can always just leave the system preference turned off. > > David Cook > Software Engineer > Prosentient Systems > 72/330 Wattle St > Ultimo, NSW 2007 > Australia > > Office: 02 9212 0899 > Online: 02 8005 0595 > > -----Original Message----- > From: Joonas Kylmälä > Sent: Tuesday, 8 September 2020 5:20 PM > To: dcook at prosentient.com.au > Cc: 'koha-devel' > Subject: Re: [Koha-devel] Request for sign-off: component part records > feature (Bug 11175) > > Hi, > > On 08/09/2020 10:15, dcook at prosentient.com.au wrote: > > I've just taken a look at comment 59 but I'm not sure why you decided to > rescue it based on that comment. > > I did it so that the GUI code does not need to be rewritten because it > takes time. > > > > I'm happy to leave some feedback on the bug report. I'll do that quickly > now. > > Thanks! > > -- > Joonas Kylmälä > Tietojärjestelmäasiantuntija > > Kansalliskirjasto > Kirjastoverkkopalvelut > PL 15 (Unioninkatu 36) > 00014 Helsingin yliopisto > > > _______________________________________________ > 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: From martin.renvoize at ptfs-europe.com Tue Sep 8 12:46:53 2020 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Tue, 8 Sep 2020 11:46:53 +0100 Subject: [Koha-devel] Using Template::Toolkit WRAPPER in Koha plugins In-Reply-To: <01ef01d68284$4a59ee70$df0dcb50$@prosentient.com.au> References: <01ef01d68284$4a59ee70$df0dcb50$@prosentient.com.au> Message-ID: Looks like a nice approach to me, thanks for the example. *Martin Renvoize* Development Team Manager Community Release Manager (19.11, 20.05) *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, 4 Sep 2020 at 07:26, wrote: > Hi all, > > > > I just wanted to share how I’ve used Template::Toolkit WRAPPER in a Koha > plugin. > > > > All the details are available at > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26381, but > basically it boils down to creating 1 wrapper template, and then invoking > that using the WRAPPER directive in individual Koha plugin templates like > report-step1.tt. > > > > It reduces the boiler plate required for each plugin template whether that > wrapper template is provided by the Koha plugin or by Koha (both approaches > have pros and cons). > > > > For a long time, I’ve wanted to use WRAPPER with Koha more broadly, but > Koha plugins provide a great opportunity for using them with no refactoring > of existing code. > > > > Anyway, I hope that others find this useful. I’m going to have a bit of > fun with it. > > > > David Cook > > Software Engineer > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > 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 : 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: From dcook at prosentient.com.au Tue Sep 8 15:27:13 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 8 Sep 2020 23:27:13 +1000 Subject: [Koha-devel] Review on Koha Order Module/plugin API In-Reply-To: <030f01d68581$7e81a7b0$7b84f710$@prosentient.com.au> References: <030f01d68581$7e81a7b0$7b84f710$@prosentient.com.au> Message-ID: <03ea01d685e3$c3446c40$49cd44c0$@prosentient.com.au> Hi again Ola, Apologies if my previous email came across as rude or aggressive. That certainly wasn't my intention. I can be overly enthusiastic about technology and overly focus on details. I am very excited by the work you have in mind. I think that it's great that the Swedish Koha User Group has created a task group for creating a Order module/plugin for Koha. That use case seems like a good candidate for a Koha plugin. I do have critical feedback for the proposed design, but one of the advantages of Koha plugins is that it is easy to iteratively develop them. Actually, I also have a few more questions. You mention that you haven't hired a contractor yet, but you've proposed a particular design. I'm guessing that design is coming from the Vendor? I wonder if it would be worthwhile having that vendor get in touch with us. I suspect that the Koha community would be able to give the best advice if we knew more about the Vendor service. Going back to the proposed design, if I understand correctly, I think you may run into issues doing the HTTP POST with the base64 encoded JSON data to Koha when unauthenticated, as the user will be prompted with a login screen that will perform another HTTP request to Koha, which means your "order" field will be lost. But maybe I'm missing something. Thanks for posting to the listserv, and looking forward to hearing more. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of dcook at prosentient.com.au Sent: Tuesday, 8 September 2020 11:44 AM To: 'Ola Andersson' ; koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Review on Koha Order Module/plugin API Hi Ola, I've only skimmed the document, but I really dislike the proposal. It's not really describing an API. It's describing a non-standard workaround. I've seen integrations like this before, but I wouldn't recommend them, especially not for a new development. I'd suggest that the Koha plugin provides an API where the Vendor Service can send the JSON in the body of a background POST request using AJAX. Once that POST request is complete, they could then offer a link to navigate to Koha. That link would be to the Koha plugin and include an identifier returned by the earlier AJAX POST request. In Koha, the user logs in and sees the Vendor Service order as shown by the Koha plugin, and then you can action that order from there however you like. Easy. You would need to provide authentication credentials to the Vendor Service, but that's a reasonable thing to do when consuming an API. I hope that helps. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel > On Behalf Of Ola Andersson Sent: Tuesday, 8 September 2020 12:41 AM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] Review on Koha Order Module/plugin API Importance: High Dear Koha Developers, Here in Sweden we have started a task group in the Swedish Koha User Group to build a Order module/plugin to Koha that allow automatic influx of order data directly from a book vendor into Koha. The API draft is described here: https://docs.google.com/document/d/13EIWxTlN3Wo-8OtJuwu5serQu-dl-zdpK1qY5BNs 0dk/edit#heading=h.jtxo4681sgpr We have had it posted for review in the Swedish user group - but we are thinking it would be valuable to get the larger Koha community to give feedback before we hire contractors to build the module/plugin. Please share thoughts on the API and how to best implement it in Koha from a developer/QA perspective. All comments are appreciated and anyone looking at the Google docs above can send comments/suggestions into the document. When the API is becoming more stable and comments have been looked at we could move it into the Koha wiki site. Please leave comments before 21 September 2020. /Swedish Koha User Group - the book vendor module/plugin task group -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Sep 8 15:34:43 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 8 Sep 2020 23:34:43 +1000 Subject: [Koha-devel] Using Template::Toolkit WRAPPER in Koha plugins In-Reply-To: References: <01ef01d68284$4a59ee70$df0dcb50$@prosentient.com.au> Message-ID: <03f401d685e4$cfa20d70$6ee62850$@prosentient.com.au> Cheers, Martin. In the plugin I was working on, I’ve created even more complex templates (by setting footerjs in the WRAPPER directive), but that plugin isn’t public at the moment. Actually, I’m probably going to not publish that plugin in the end, as it wasn’t scalable enough. The synchronous processing was just too slow. It would be tempting to rearchitect it to use asynchronous processing, but we’ll need more work done for on the task queue front for that. Although this plugin has made me think more about what would be needed there: * Plugin sends message to RabbitMQ * RabbitMQ sends message to Background Worker * Background Worker invokes desired Plugin method for long-running job * Plugin or Background Worker stores results somewhere that can be used later by a Koha web user. I’ve been learning Gitlab CI lately and it’s essentially the same model (but without the RabbitMQ). David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Renvoize, Martin Sent: Tuesday, 8 September 2020 8:47 PM To: Koha Devel Subject: Re: [Koha-devel] Using Template::Toolkit WRAPPER in Koha plugins Looks like a nice approach to me, thanks for the example. Martin Renvoize Development Team Manager Community Release Manager (19.11, 20.05) 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, 4 Sep 2020 at 07:26, > wrote: Hi all, I just wanted to share how I’ve used Template::Toolkit WRAPPER in a Koha plugin. All the details are available at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26381, but basically it boils down to creating 1 wrapper template, and then invoking that using the WRAPPER directive in individual Koha plugin templates like report-step1.tt . It reduces the boiler plate required for each plugin template whether that wrapper template is provided by the Koha plugin or by Koha (both approaches have pros and cons). For a long time, I’ve wanted to use WRAPPER with Koha more broadly, but Koha plugins provide a great opportunity for using them with no refactoring of existing code. Anyway, I hope that others find this useful. I’m going to have a bit of fun with it. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 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 : 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: From tomascohen at gmail.com Tue Sep 8 15:43:12 2020 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 8 Sep 2020 10:43:12 -0300 Subject: [Koha-devel] Review on Koha Order Module/plugin API In-Reply-To: <08af7c7d-484a-9fd8-9763-48b0f04b2a2b@biblibre.com> References: <08af7c7d-484a-9fd8-9763-48b0f04b2a2b@biblibre.com> Message-ID: The main problem I see with Koha's API for this, is the fact that our current workflow Basket > Orderlines > close basket > receive is sometimes too complicated for vendors. Meaning they don't expect to understand that much how Koha does things internally. I faced this when I wrote the GOBI plugin, which had a pretty similar spec. We could add the option to auto-create a basket (that's part of the original orders spec) and we definitely should have a route to add records. It really depends on how much we can make the external system adapt to Koha. Otherwise, you should take the plugin route, unfortunately. El lun., 7 sept. 2020 a las 12:14, Arthur Suzuki (< arthur.suzuki at biblibre.com>) escribió: > Hello Ola, > > I have no idea of what the final purpose is but I kind of understood from > your document you want to achieve automatic input of biblio data from > vendors directly. > > https://wiki.koha-community.org/wiki/Biblios_endpoint_RFC > > The route to get biblio data from koha is implemented in 19.11 but the one > to push to koha is still missing (can't find out which bz it is). > > I'd be really interested into seeing some community route implementing > order operations through the api. > > There is already one existing to interact with Koha vendor data, if of any > help: > > https://wiki.koha-community.org/wiki/Acquisitions_vendors_endpoint_RFC -> > implemented > > One of my concern, the one implementing purchase suggestions operation is > also still a big work in progress: > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17314 > > Maybe nice to file a bug in bugzilla like "Route to create, list, update, > delete an order basket" or something of the like so that anyone can > followup? If you do so, please add me to the CC's :) > > Kind regards, > > Arthur > On 07/09/2020 16:40, Ola Andersson wrote: > > Dear Koha Developers, > > > > Here in Sweden we have started a task group in the Swedish Koha User > Group to build a Order module/plugin to Koha that allow automatic influx of > order data directly from a book vendor into Koha. > > > > The API draft is described here: > https://docs.google.com/document/d/13EIWxTlN3Wo-8OtJuwu5serQu-dl-zdpK1qY5BNs0dk/edit#heading=h.jtxo4681sgpr > > > > We have had it posted for review in the Swedish user group – but we are > thinking it would be valuable to get the larger Koha community to give > feedback before we hire contractors to build the module/plugin. > > > > Please share thoughts on the API and how to best implement it in Koha > from a developer/QA perspective. All comments are appreciated and anyone > looking at the Google docs above can send comments/suggestions into the > document. > > > > When the API is becoming more stable and comments have been looked at we > could move it into the Koha wiki site. > > > > Please leave comments before 21 September 2020. > > > > /Swedish Koha User Group – the book vendor module/plugin task group > > _______________________________________________ > Koha-devel mailing listKoha-devel at lists.koha-community.orghttps://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/ > -- 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 Sep 8 16:02:28 2020 From: arthur.suzuki at biblibre.com (Arthur Suzuki) Date: Tue, 8 Sep 2020 16:02:28 +0200 Subject: [Koha-devel] Review on Koha Order Module/plugin API In-Reply-To: <03ea01d685e3$c3446c40$49cd44c0$@prosentient.com.au> References: <030f01d68581$7e81a7b0$7b84f710$@prosentient.com.au> <03ea01d685e3$c3446c40$49cd44c0$@prosentient.com.au> Message-ID: <641d39a4-dc4f-2b2e-0938-a09c2d0dd025@biblibre.com> Hi again Ola, By seeing the email from David (and previous one from Martin), I just realize I focused on the "API matter" , and "Plugin matter" went completely out of my scope :) I guess you know already but plugins could be a great way to expand Koha API current capabilities by providing "contrib" routes (api extensions provided by plugins). Then, you could use plugin to leverage your developments from the "hassle" of submitting your changes to the community. Work done for the plugin could then maybe be reused at a later time to get integrated to koha with much less effort. Also about authentication, Koha Api also support "Basic Auth", which might help you get rid of user having to log in (again?), given the consumer app holds the koha user password in its data. Good luck! On 08/09/2020 15:27, dcook at prosentient.com.au wrote: > > Hi again Ola, > >   > > Apologies if my previous email came across as rude or aggressive. That > certainly wasn’t my intention. I can be overly enthusiastic about > technology and overly focus on details. I am very excited by the work > you have in mind. > >   > > I think that it’s great that the Swedish Koha User Group has created a > task group for creating a Order module/plugin for Koha. That use case > seems like a good candidate for a Koha plugin. I do have critical > feedback for the proposed design, but one of the advantages of Koha > plugins is that it is easy to iteratively develop them. > >   > > Actually, I also have a few more questions. You mention that you > haven’t hired a contractor yet, but you’ve proposed a particular > design. I’m guessing that design is coming from the Vendor? I wonder > if it would be worthwhile having that vendor get in touch with us. I > suspect that the Koha community would be able to give the best advice > if we knew more about the Vendor service. > >   > > Going back to the proposed design, if I understand correctly, I think > you may run into issues doing the HTTP POST with the base64 encoded > JSON data to Koha when unauthenticated, as the user will be prompted > with a login screen that will perform another HTTP request to Koha, > which means your “order” field will be lost. But maybe I’m missing > something. > >   > > Thanks for posting to the listserv, and looking forward to hearing more. > >   > > David Cook > > Software Engineer > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > >   > > Office: 02 9212 0899 > > Online: 02 8005 0595 > >   > > *From:*Koha-devel *On > Behalf Of *dcook at prosentient.com.au > *Sent:* Tuesday, 8 September 2020 11:44 AM > *To:* 'Ola Andersson' ; > koha-devel at lists.koha-community.org > *Subject:* Re: [Koha-devel] Review on Koha Order Module/plugin API > >   > > Hi Ola, > >   > > I’ve only skimmed the document, but I really dislike the proposal. > It’s not really describing an API. It’s describing a non-standard > workaround. I’ve seen integrations like this before, but I wouldn’t > recommend them, especially not for a new development. > >   > > I’d suggest that the Koha plugin provides an API where the Vendor > Service can send the JSON in the body of a background POST request > using AJAX. Once that POST request is complete, they could then offer > a link to navigate to Koha. That link would be to the Koha plugin and > include an identifier returned by the earlier AJAX POST request. > >   > > In Koha, the user logs in and sees the Vendor Service order as shown > by the Koha plugin, and then you can action that order from there > however you like. Easy. > >   > > You would need to provide authentication credentials to the Vendor > Service, but that’s a reasonable thing to do when consuming an API. > >   > > I hope that helps. > >   > > David Cook > > Software Engineer > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > >   > > Office: 02 9212 0899 > > Online: 02 8005 0595 > >   > > *From:*Koha-devel > *On Behalf Of > *Ola Andersson > *Sent:* Tuesday, 8 September 2020 12:41 AM > *To:* koha-devel at lists.koha-community.org > > *Subject:* [Koha-devel] Review on Koha Order Module/plugin API > *Importance:* High > >   > > Dear Koha Developers, > >   > > Here in Sweden we have started a task group in the Swedish Koha User > Group to build a Order module/plugin to Koha that allow automatic > influx of order data directly from a book vendor into Koha. > >   > > The APIdraft is described here: > https://docs.google.com/document/d/13EIWxTlN3Wo-8OtJuwu5serQu-dl-zdpK1qY5BNs0dk/edit#heading=h.jtxo4681sgpr > >   > > We have had it posted for review in the Swedish user group – but we > are thinking it would be valuable to get the larger Koha community to > give feedback before we hire contractors to build the module/plugin. > >   > > Pleaseshare thoughts on the API and how to best implement it in Koha > from a developer/QA perspective. All comments are appreciated and > anyone looking at the Google docs above can send comments/suggestions > into the document. > >   > > When the API is becoming more stable and comments have been looked at > we could move it into the Koha wiki site. > >   > > Please leave comments before 21 September 2020. > >   > > /Swedish Koha User Group – the book vendor module/plugin task group > > > _______________________________________________ > 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: From ola.andersson at ltu.se Tue Sep 8 17:05:22 2020 From: ola.andersson at ltu.se (Ola Andersson) Date: Tue, 8 Sep 2020 15:05:22 +0000 Subject: [Koha-devel] Review on Koha Order Module/plugin API In-Reply-To: References: Message-ID: Hi, Many thanks for the feedback on our outreach the other day. We will get back to the list with replies to the different questions raised by everyone in the coming days. I am not responding to each and every one now. As some have mentioned this is a first spec which can be further developed in iterations going forward. The order flow setup in its early form were initially proposed by one of our larger book vendors and expanded by the group, we intend in the first iterations to stick to it. This means we have something working, supporting our librarians ordering thousands of books from vendors, requesting this feature. I don’t see a collision between the proposed “punch-out” sending data once and the user continuing in the Koha client and a more refined handshake and redirect on succeed setup. We might be able to support both scenarios in the API and depending on vendor capacities and implementation they choose one over the other. The existing Koha API:s seem too divided/segmented for one vendor to call several API:s for every order. Rather we will have the plugin include the logic to, once order data has reach the plugin, together with the Koha user, using HTML forms, decide on what to do and how to store it (preferably using API:s) into Koha.. I hope this further explains the setup we had in mind. Thanks again for the feedback – keep it coming 👍 /Swedish order module/plugin task group Från: Ola Andersson Skickat: den 7 september 2020 16:41 Till: koha-devel at lists.koha-community.org Ämne: Review on Koha Order Module/plugin API Prioritet: Hög Dear Koha Developers, Here in Sweden we have started a task group in the Swedish Koha User Group to build a Order module/plugin to Koha that allow automatic influx of order data directly from a book vendor into Koha. The API draft is described here: https://docs.google.com/document/d/13EIWxTlN3Wo-8OtJuwu5serQu-dl-zdpK1qY5BNs0dk/edit#heading=h.jtxo4681sgpr We have had it posted for review in the Swedish user group – but we are thinking it would be valuable to get the larger Koha community to give feedback before we hire contractors to build the module/plugin. Please share thoughts on the API and how to best implement it in Koha from a developer/QA perspective. All comments are appreciated and anyone looking at the Google docs above can send comments/suggestions into the document. When the API is becoming more stable and comments have been looked at we could move it into the Koha wiki site. Please leave comments before 21 September 2020. /Swedish Koha User Group – the book vendor module/plugin task group -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmc at equinoxinitiative.org Tue Sep 8 20:26:30 2020 From: gmc at equinoxinitiative.org (Galen Charlton) Date: Tue, 8 Sep 2020 14:26:30 -0400 Subject: [Koha-devel] Cleaning git project list In-Reply-To: References: Message-ID: Hi, On Tue, Sep 8, 2020 at 5:26 AM Jonathan Druart < jonathan.druart at bugs.koha-community.org> wrote: > wip/koha-equinox.git Equinox work in progress Galen Charlton I confirm that this can go away. Regards, Galen -- Galen Charlton Implementation and Services Manager Equinox Open Library Initiative phone: 1-877-OPEN-ILS (673-6457) email: gmc at equinoxInitiative.org web: https://equinoxInitiative.org direct: +1 770-709-5581 cell: +1 404-984-4366 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Fri Sep 11 03:04:57 2020 From: mtj at kohaaloha.com (Mason James) Date: Fri, 11 Sep 2020 13:04:57 +1200 Subject: [Koha-devel] Koha nighty builds and KTD Message-ID: <520c4383-7a8f-5744-071e-9400561b6400@kohaaloha.com> hi folks would people like the latest build for stable, oldstable and oldoldstable branches be used by KTD? i checked the KTD git history, and it seems that historically the latest build from the master branch was used by all KTD branches what do people prefer? From mtj at kohaaloha.com Fri Sep 11 03:17:26 2020 From: mtj at kohaaloha.com (Mason James) Date: Fri, 11 Sep 2020 13:17:26 +1200 Subject: [Koha-devel] Koha nighty builds and KTD In-Reply-To: <520c4383-7a8f-5744-071e-9400561b6400@kohaaloha.com> References: <520c4383-7a8f-5744-071e-9400561b6400@kohaaloha.com> Message-ID: <2ea3cd72-7389-8489-7add-a2ebdeaa34cb@kohaaloha.com> On 11/09/20 1:04 pm, Mason James wrote: > hi folks > would people like the latest build for stable, oldstable and oldoldstable branches be used by KTD? > aah, that should be the latest *nightly* build for stable, oldstable and oldoldstable branches other option is to use the latest *production* builds for stable, oldstable and oldoldstable branches, (this is the current situation) From library.online9 at gmail.com Fri Sep 11 12:51:40 2020 From: library.online9 at gmail.com (Library Online) Date: Fri, 11 Sep 2020 16:21:40 +0530 Subject: [Koha-devel] ERROR IN ACQUISITION MODULE Message-ID: I am using koha 18.11.04 running on ubuntu 18.04 I am trying to set up the acquisition module. i have set a library budget and created funds. afterwards, when i create a vendor and save. i now go to manage orders to search for the vendor i just created. the error seen below pops up. please how do i resolve this? thanks in advance. Dinesh Software error: Can't use an undefined value as an ARRAY reference at /usr/lib/x86_64-linux-gnu/perl5/5.26/DBI.pm line 2081. For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error. *Thanks&Regards* * Dinesh Kumar* Mobile Numebr-9616146991 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Sep 14 01:51:35 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Mon, 14 Sep 2020 09:51:35 +1000 Subject: [Koha-devel] Koha nighty builds and KTD In-Reply-To: <2ea3cd72-7389-8489-7add-a2ebdeaa34cb@kohaaloha.com> References: <520c4383-7a8f-5744-071e-9400561b6400@kohaaloha.com> <2ea3cd72-7389-8489-7add-a2ebdeaa34cb@kohaaloha.com> Message-ID: <008201d68a28$d0906fe0$71b14fa0$@prosentient.com.au> It's a good question. I suppose they both have pros and cons. At this point, I don't know if there is a point changing the status quo, as it's been working fairly well? Using nightly builds might make it harder for different people to share results with each other? David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Koha-devel On Behalf Of Mason James Sent: Friday, 11 September 2020 11:17 AM To: Koha Devel Subject: Re: [Koha-devel] Koha nighty builds and KTD On 11/09/20 1:04 pm, Mason James wrote: > hi folks > would people like the latest build for stable, oldstable and oldoldstable branches be used by KTD? > aah, that should be the latest *nightly* build for stable, oldstable and oldoldstable branches other option is to use the latest *production* builds for stable, oldstable and oldoldstable branches, (this is the current situation) _______________________________________________ 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 Mon Sep 14 09:24:53 2020 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Mon, 14 Sep 2020 09:24:53 +0200 Subject: [Koha-devel] Using Template::Toolkit WRAPPER in Koha plugins In-Reply-To: <01ef01d68284$4a59ee70$df0dcb50$@prosentient.com.au> References: <01ef01d68284$4a59ee70$df0dcb50$@prosentient.com.au> Message-ID: <10a9f20e-8c9d-9f05-34e0-d78c3ceb2e06@biblibre.com> Yep very good idea. Sound really logical to help plugin developpers. On 04/09/2020 08:26, dcook at prosentient.com.au wrote: > Hi all, > > I just wanted to share how I’ve used Template::Toolkit WRAPPER in a Koha > plugin. > > All the details are available at > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26381 > , but > basically it boils down to creating 1 wrapper template, and then > invoking that using the WRAPPER directive in individual Koha plugin > templates like report-step1.tt. > > It reduces the boiler plate required for each plugin template whether > that wrapper template is provided by the Koha plugin or by Koha (both > approaches have pros and cons). > > For a long time, I’ve wanted to use WRAPPER with Koha more broadly, but > Koha plugins provide a great opportunity for using them with no > refactoring of existing code. > > Anyway, I hope that others find this useful. I’m going to have a bit of > fun with it. > > David Cook > > Software Engineer > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > 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 : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From dcook at prosentient.com.au Tue Sep 15 01:46:30 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 15 Sep 2020 09:46:30 +1000 Subject: [Koha-devel] New version of Zebra released Message-ID: <015901d68af1$44eafa90$cec0efb0$@prosentient.com.au> Hi all, As the English idiom goes, the squeaky wheel gets the oil. After I raised an issue on GitHub, IndexData have released a new version of Zebra, and added packages for Debian Buster and Ubuntu Focal, so folk using Koha on Debian Buster no longer have to use the 2.0.59 version (with the ICU bugs) from the Debian repositories. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleisha at catalyst.net.nz Tue Sep 15 03:04:36 2020 From: aleisha at catalyst.net.nz (Aleisha Amohia) Date: Tue, 15 Sep 2020 13:04:36 +1200 Subject: [Koha-devel] String freeze for 19.11.x Message-ID: Hi all, String freeze will go into effect end of on Tuesday 15 September 2020 for the 19.11.x maintenance branch. 19.11.10 release scheduled for Tuesday 22 September 2020. Thanks -- *Aleisha Amohia*(she/her) Koha Developer Catalyst IT - Expert Open Source Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohanews at gmail.com Tue Sep 15 20:19:22 2020 From: kohanews at gmail.com (Koha Newsletter) Date: Tue, 15 Sep 2020 11:19:22 -0700 Subject: [Koha-devel] Call for news: September 2020 Koha Newsletter Message-ID: <723F2CB6-F22D-4B4D-AC11-9262C390735B@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 tomascohen at gmail.com Tue Sep 15 21:58:56 2020 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 15 Sep 2020 16:58:56 -0300 Subject: [Koha-devel] On Koha::Object->store Message-ID: Hi, I've been fixing a bug in Koha::Item->store, and I remembered I wasn't sure why we keep the current behaviour instead of making ->store return the ->get_from_storage result like: return $self->SUPER::store->get_from_storage; I know this is 'how DBIC works' but I don't think there's much gain by avoiding it, and anyone calling ->store and doing something else afterwards, needs to remember ->discard_changes (or better ->get_from_storage) needs to be called in order to have the auto generated/updated fields the DB handles (autoincrement fields, timestamps, etc). So, is there a reason to keep this as-is? -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor at tuxayo.net Tue Sep 15 23:23:27 2020 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Tue, 15 Sep 2020 23:23:27 +0200 Subject: [Koha-devel] Time to translate: string freeze for 19.05.x has begun Message-ID: Hi, saluton, hola, bonjour, String freeze will be into effect now 15 September for the 19.05.x maintenance branch. The 19.05.15 release is scheduled for the 25th of September. This means it's the right time to head over to the translation platform: https://translate.koha-community.org/projects/ Important reminder: if you add or change a translation in version 19.05, then you must also copy it to 19.11 and 20.05. Otherwise your work will be lost for future versions. Happy translating, -- Victor Grousset/tuxayo From martin.renvoize at ptfs-europe.com Wed Sep 16 16:45:05 2020 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Wed, 16 Sep 2020 15:45:05 +0100 Subject: [Koha-devel] On Koha::Object->store In-Reply-To: References: Message-ID: I've been caught by this before myself. I have a vague recollection of such a patch getting in at some point, then being reverted.. perhaps for performance reasons? Either way.. there is *Bug 20621* - Add ability for Koha::Object objects to update themselves with database generated value automatically *Martin Renvoize* Development Team Manager Community Release Manager (19.11, 20.05) *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 Tue, 15 Sep 2020 at 20:59, Tomas Cohen Arazi wrote: > Hi, I've been fixing a bug in Koha::Item->store, and I remembered I wasn't > sure why we keep the current behaviour instead of making ->store return the > ->get_from_storage result like: > > return $self->SUPER::store->get_from_storage; > > I know this is 'how DBIC works' but I don't think there's much gain by > avoiding it, and anyone calling ->store and doing something else > afterwards, needs to remember ->discard_changes (or better > ->get_from_storage) needs to be called in order to have the auto > generated/updated fields the DB handles (autoincrement fields, timestamps, > etc). > > So, is there a reason to keep this as-is? > > -- > 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: From dcook at prosentient.com.au Mon Sep 21 04:28:40 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Mon, 21 Sep 2020 12:28:40 +1000 Subject: [Koha-devel] koha-upgrade-schema extremely slow even when no upgrades to make Message-ID: <058d01d68fbe$eb2ef650$c18ce2f0$@prosentient.com.au> Hi all, Does anyone else notice that koha-upgrade-schema runs extremely slowly, particularly when given a large list of instances, even when there are no upgrades to make? In theory, it should just return very quickly, because there are no schema upgrades to make. I haven't looked into the code yet, but figured I'd put the question to the community. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Sep 22 08:55:36 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 22 Sep 2020 16:55:36 +1000 Subject: [Koha-devel] Code generation for client libraries using an OpenAPI spec Message-ID: <066e01d690ad$5fd90b50$1f8b21f0$@prosentient.com.au> Hi all, Has anyone used (Swagger) code generation for client libraries using an OpenAPI spec? It could be interesting to provide Debian packages with some client SDKs for popular languages for working with Koha. We could even provide a generated Perl SDK and then use it within Koha. Thoughts? David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleisha at catalyst.net.nz Wed Sep 23 01:02:08 2020 From: aleisha at catalyst.net.nz (Aleisha Amohia) Date: Wed, 23 Sep 2020 11:02:08 +1200 Subject: [Koha-devel] Koha 19.11.10 released Message-ID: Hello! The Koha community is proud to announce the release of Koha 19.11.10. Koha 19.11.10 is a security and bugfix/maintenance release including 1 security fixes, 1 enhancements, 35 bugfixes. The full release notes are available here: https://koha-community.org/koha-19-11-10-released/ -- *Aleisha Amohia*(she/her) Koha Developer Catalyst IT - Expert Open Source Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.blouin at inlibro.com Wed Sep 23 19:06:12 2020 From: philippe.blouin at inlibro.com (Philippe Blouin) Date: Wed, 23 Sep 2020 13:06:12 -0400 Subject: [Koha-devel] require_strong_password "too late" in updatedatabase.pl Message-ID: <8345c27a-d350-f524-fabf-30205cfa2f35@inlibro.com> Hello devs! Our "master" instances are exploding. Line 22722 of updatedatabase.pl says ALTER TABLE `categories` ADD COLUMN `exclude_from_local_holds_priority` tinyint(1) default NULL AFTER `require_strong_password` While "require_strong_password" is added later on (line 22786). So we get |Software error||DBIx::Class::Storage::DBI::_dbh_execute(): Unknown column 'me.*exclude_from_local_holds_priority*' in 'field list' at | Regards, Philippe Blouin, Directeur de la technologie Tél.  : (833) 465-4276, poste 230 philippe.blouin at inLibro.com inLibro | pour esprit libre | www.inLibro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Wed Sep 23 19:14:08 2020 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 23 Sep 2020 14:14:08 -0300 Subject: [Koha-devel] require_strong_password "too late" in updatedatabase.pl In-Reply-To: <8345c27a-d350-f524-fabf-30205cfa2f35@inlibro.com> References: <8345c27a-d350-f524-fabf-30205cfa2f35@inlibro.com> Message-ID: I filled a bug for that: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26513 On Wed, Sep 23, 2020, 14:07 Philippe Blouin wrote: > Hello devs! > > Our "master" instances are exploding. > > Line 22722 of updatedatabase.pl says > > ALTER TABLE `categories` ADD COLUMN `exclude_from_local_holds_priority` > tinyint(1) default NULL AFTER `require_strong_password` > > While "require_strong_password" is added later on (line 22786). > > So we get > > Software error DBIx::Class::Storage::DBI::_dbh_execute(): Unknown column > 'me.*exclude_from_local_holds_priority*' in 'field list' at > > Regards, > Philippe Blouin, > Directeur de la technologie > > Tél. : (833) 465-4276, poste 230 > philippe.blouin at inLibro.com > inLibro | pour esprit libre | www.inLibro.com > _______________________________________________ > 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: From jonathan.druart at bugs.koha-community.org Wed Sep 23 22:20:16 2020 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Wed, 23 Sep 2020 22:20:16 +0200 Subject: [Koha-devel] require_strong_password "too late" in updatedatabase.pl In-Reply-To: References: <8345c27a-d350-f524-fabf-30205cfa2f35@inlibro.com> Message-ID: It should be fixed now! Le mer. 23 sept. 2020 à 19:14, Tomas Cohen Arazi a écrit : > > I filled a bug for that: > > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26513 > > On Wed, Sep 23, 2020, 14:07 Philippe Blouin wrote: >> >> Hello devs! >> >> Our "master" instances are exploding. >> >> Line 22722 of updatedatabase.pl says >> >> ALTER TABLE `categories` ADD COLUMN `exclude_from_local_holds_priority` tinyint(1) default NULL AFTER `require_strong_password` >> >> While "require_strong_password" is added later on (line 22786). >> >> So we get >> >> Software error DBIx::Class::Storage::DBI::_dbh_execute(): Unknown column 'me.exclude_from_local_holds_priority' in 'field list' at >> >> Regards, >> >> Philippe Blouin, >> Directeur de la technologie >> >> Tél. : (833) 465-4276, poste 230 >> philippe.blouin at inLibro.com >> >> inLibro | pour esprit libre | www.inLibro.com >> _______________________________________________ >> 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/ From jonathan.druart at bugs.koha-community.org Mon Sep 28 13:18:23 2020 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Mon, 28 Sep 2020 13:18:23 +0200 Subject: [Koha-devel] koha-upgrade-schema extremely slow even when no upgrades to make In-Reply-To: <058d01d68fbe$eb2ef650$c18ce2f0$@prosentient.com.au> References: <058d01d68fbe$eb2ef650$c18ce2f0$@prosentient.com.au> Message-ID: What is "extremely slow"? It takes 1.5s to run for me, time to load the modules (and especially dbic schema) Le lun. 21 sept. 2020 à 04:28, a écrit : > > Hi all, > > > > Does anyone else notice that koha-upgrade-schema runs extremely slowly, particularly when given a large list of instances, even when there are no upgrades to make? > > > > In theory, it should just return very quickly, because there are no schema upgrades to make. > > > > I haven’t looked into the code yet, but figured I’d put the question to the community. > > > > David Cook > > Software Engineer > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > 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 : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ From jonathan.druart at bugs.koha-community.org Mon Sep 28 16:46:55 2020 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Mon, 28 Sep 2020 16:46:55 +0200 Subject: [Koha-devel] New dependency required for master Message-ID: Hi, I have just pushed bug 16357, which added a new dependency: libplack-middleware-logwarn-perl Until our package has it as a dependency, you will have to install it if you are using koha-testing-docker or kohadevbox. sudo apt install libplack-middleware-logwarn-perl should do the trick! The error is "Error while loading /etc/koha/sites/kohadev/plack.psgi: Can't locate Plack/Middleware/LogWarn.pm in @INC" Cheers, Jonathan From tomascohen at gmail.com Mon Sep 28 18:13:21 2020 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 28 Sep 2020 13:13:21 -0300 Subject: [Koha-devel] Cancellable orders Message-ID: Should an acquisition order be cancellable if the items cannot be deleted? -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer.83 at web.de Tue Sep 29 22:12:04 2020 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Tue, 29 Sep 2020 22:12:04 +0200 Subject: [Koha-devel] Cancellable orders In-Reply-To: References: Message-ID: <5290077c-687c-e827-540f-28cfec2caa00@web.de> Hi Tomas, I am torn here. To keep it simple: one reason an item might not be deletable is if it was checked out. If the item is checked out while not received yet... I'd say something has gone wrong. The item should not actually be in the library. So now we could: 1) Notify the user and don't allow cancelling the order. 2) Notify the user that the items could not be deleted, but cancel the order. 3) Notify the user and ask if the order should be cancelled anyway - act according to what the user decides. ... I think the third option could be a nice solution that leaves room for some workflows I am not aware of. Katrin On 28.09.20 18:13, Tomas Cohen Arazi wrote: > Should an acquisition order be cancellable if the items cannot be deleted? > > -- > 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: From dcook at prosentient.com.au Wed Sep 30 09:10:46 2020 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 30 Sep 2020 17:10:46 +1000 Subject: [Koha-devel] Koha stats on http://git.koha-community.org/stats/koha-master/authors.html Message-ID: <094c01d696f8$d16d10d0$74473270$@prosentient.com.au> Hi all, I know it's not really a big drama, but it looks like the Koha stats on http://git.koha-community.org/stats/koha-master/authors.html haven't really updated since 2020-09-11, even though http://git.koha-community.org/stats/koha-master/index.html says it's generated new ones. I'm guessing whatever Koha repo it uses in the background must not be updated. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Wed Sep 30 10:15:33 2020 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Wed, 30 Sep 2020 10:15:33 +0200 Subject: [Koha-devel] Koha stats on http://git.koha-community.org/stats/koha-master/authors.html In-Reply-To: <094c01d696f8$d16d10d0$74473270$@prosentient.com.au> References: <094c01d696f8$d16d10d0$74473270$@prosentient.com.au> Message-ID: (Answered on IRC) Basically git.k-c.org is going to be moved to a new server soon. The way the stats are generated is: have local changes to .mailmap, then pull the koha repo I picked the changes to .mailmap and integrated it into Koha (see 26394). I will ask Chris to fix the problem (the pull fails because of the local changes), and the repo used for stats is not updated. Cheers, Jonathan Le mer. 30 sept. 2020 à 09:10, a écrit : > > Hi all, > > > > I know it’s not really a big drama, but it looks like the Koha stats on http://git.koha-community.org/stats/koha-master/authors.html haven’t really updated since 2020-09-11, even though http://git.koha-community.org/stats/koha-master/index.html says it’s generated new ones. > > > > I’m guessing whatever Koha repo it uses in the background must not be updated. > > > > David Cook > > Software Engineer > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > 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 : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/