From fridolin.somers at biblibre.com Mon Oct 1 12:02:24 2018 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Mon, 1 Oct 2018 12:02:24 +0200 Subject: [Koha-devel] Problem of OpacHiddenItems In-Reply-To: References: <4cb48621-48c3-244c-0365-58da9a833fc9@devinim.com.tr> Message-ID: <5502814d-06fd-da79-4c42-92d2962c4e1c@biblibre.com> We also may consider creating an ES node for staff and one for OPAC. It will correct all side effects like facets, ... Le 28/09/2018 ? 21:28, Mark Tompsett a ?crit?: > Greetings, > >> We faced a quite big problem in Opac search for a while >> and we were not able to find a workaround for that. > [SNIP] > [SYNOPSIS: The count is off, and because of pagination, > sometimes 0 results are shown for the returned page, > because of the way filtering works] >> Is there anybody hit this problem and any workaround for that? > > Yes, I have seen this. No, there is no workaround. > In order to not have crazy long return times, > X results per page are returned from the search server (Zebra or otherwise), > but THEN the filtering happens. This means that you could get X results > back and have them all filtered. > >> We created the bug >> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19688 > > Decent description of the problem, but this is really a "searching needs > a major refactor" problem. > > >> and we think that the change in the bug >> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10584 >> may be the result of this bug. > > No, 10584 was a result of not wanting to show the biblio for something > when all the items are hidden. If a particular book has all its copies in > shelving locations which are not accessible to the public, we don't want > to tell the public about it. > > This has nothing to do with the miscounting and poor filtering problem > you are accurately describing. > > I agree with Fridolin's assessment, > "In my opinion, we should real[l]y consider that it is not possible to hide > records correctly in search pages," > and perhaps attempt to come up with a more flexible, perhaps ajaxy > way to handle searching. This would allow for loading all the result > item numbers, filtering them, and THEN counting and displaying them. > Rather than using the search engine count, THEN filtering and displaying. > > GPML, > Mark Tompsett > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Fridolin SOMERS BibLibre, France - software and system maintainer From jonathan.druart at bugs.koha-community.org Mon Oct 1 22:30:03 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Mon, 1 Oct 2018 17:30:03 -0300 Subject: [Koha-devel] QA script is now able to catch missing filters! Message-ID: Hi devs, A new check to catch missing filters is not in the QA script. Please update, and report bugs! ;) Cheers, Jonathan https://gitlab.com/koha-community/qa-test-tools/issues/3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Oct 2 02:28:36 2018 From: dcook at prosentient.com.au (David Cook) Date: Tue, 2 Oct 2018 10:28:36 +1000 Subject: [Koha-devel] [Koha] Inventory lists incorrectly sorted In-Reply-To: References: <006b01d456f5$1f3d6300$5db82900$@prosentient.com.au> Message-ID: <018301d459e6$db898540$929c8fc0$@prosentient.com.au> I think Koha should be taking care of normalizing the call number into something like ?AL_333_910000000000000_WHY_1986? (admittedly a Dewey-ish example) for sorting purposes. If Koha isn?t sorting the call number correctly, I think it?s worth raising an issue. It seems to me that the on-screen inventory list and the CSV/spreadsheet export inventory list should be identical in how they?re sorted. That way you can print off a shelf list, do your inventory, and then scroll through your screen marking items as seen in the order that they were seen for real. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Sebastian Hierl [mailto:s.hierl at aarome.org] Sent: Friday, 28 September 2018 7:11 PM To: dcook at prosentient.com.au Cc: Koha Devel ; koha Subject: Re: [Koha] Inventory lists incorrectly sorted Thank you for raising this issue, David. We sort the reports we generate from Koha in Excel with the following formula by Lee Ann Nolan and Jameson Conley: https://scholarsphere.psu.edu/concern/generic_works/qv33rw719 The formula is a big help, but it doesn't work for call numbers starting three letters, such as in the K class , where there are numerous call numbers starting with KJA, KKH, KZA, etc. I would love to hear whether anyone has devised a better script or formula to sort LC call numbers in either LibreOffice / OpenOffice or Excel. Thank you, Sebastian -- Sebastian Hierl, Ph.D. Drue Heinz Librarian, Arthur & Janet C. Ross Library American Academy in Rome Via Angelo Masina 5 00153 Rome Italy T: +39 06 5846 417 F: +39 06 5810 788 On Fri, Sep 28, 2018 at 8:33 AM David Cook > wrote: Hi all, Has anyone had a problem where the lists generated by the inventory tool don't seem to be sorted correctly? I received reports of this and during my investigation I found https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19021 but that didn't seem to solve the root problem, which actually appears to be with the item data stored in the database - rather than Koha code per se. I've opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21447 to look into this. I've solved it in my case using touch_all_items.pl , but it might not be feasible for everyone to run this. Keen to hear ideas about how people think we should resolve this issue for all people. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 _______________________________________________ Koha mailing list http://koha-community.org Koha at lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Tue Oct 2 02:42:17 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Mon, 1 Oct 2018 21:42:17 -0300 Subject: [Koha-devel] QA script is now able to catch missing filters! In-Reply-To: References: Message-ID: s/not/now ofc :) On Mon, 1 Oct 2018 at 17:30 Jonathan Druart < jonathan.druart at bugs.koha-community.org> wrote: > Hi devs, > > A new check to catch missing filters is not in the QA script. > > Please update, and report bugs! ;) > > Cheers, > Jonathan > > https://gitlab.com/koha-community/qa-test-tools/issues/3 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Oct 2 12:01:58 2018 From: dcook at prosentient.com.au (David Cook) Date: Tue, 2 Oct 2018 20:01:58 +1000 Subject: [Koha-devel] Can't create new Jessie Kohadevbox Message-ID: <025801d45a36$f500ef40$df02cdc0$@prosentient.com.au> Hi all, I created a Jessie Kohadevbox at the Kohacon18 hackfest and it was all good, but when I've tried making one back at work, it's been failing. Josef pointed me to this issue opened by Owen: https://gitlab.com/koha-community/kohadevbox/issues/273, and I think that I've worked out what's going on. It looks like there was a recent update to the python-reportbug package and it triggers the download of python-openssl version 0.14-1, which seems to create fatal errors in pip and Ansible. The workaround is to remove python-openssl and then re-provision the kohadevbox. Obviously, that's not a great solution for a kohadevbox which should work "out of the box", but it's a solution for now. I haven't tried Stretch with the kohadevbox, but I have a feeling that it might be OK. Hopefully this info is helpful! David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Tue Oct 2 13:57:04 2018 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Tue, 2 Oct 2018 11:57:04 +0000 Subject: [Koha-devel] QA script is now able to catch missing filters! In-Reply-To: References: , Message-ID: Great ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Tue Oct 2 14:13:42 2018 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 2 Oct 2018 09:13:42 -0300 Subject: [Koha-devel] Can't create new Jessie Kohadevbox In-Reply-To: <025801d45a36$f500ef40$df02cdc0$@prosentient.com.au> References: <025801d45a36$f500ef40$df02cdc0$@prosentient.com.au> Message-ID: I created a Stretch one yesterday. Will check Jessie today. We can always remove the package in the ansible playbook (if distribution == 'jessie'). Regards El mar., 2 oct. 2018 a las 7:03, David Cook () escribi?: > Hi all, > > > > I created a Jessie Kohadevbox at the Kohacon18 hackfest and it was all > good, but when I?ve tried making one back at work, it?s been failing. > > > > Josef pointed me to this issue opened by Owen: > https://gitlab.com/koha-community/kohadevbox/issues/273, and I think that > I?ve worked out what?s going on. > > > > It looks like there was a recent update to the python-reportbug package > and it triggers the download of python-openssl version 0.14-1, which seems > to create fatal errors in pip and Ansible. > > > > The workaround is to remove python-openssl and then re-provision the > kohadevbox. > > > > Obviously, that?s not a great solution for a kohadevbox which should work > ?out of the box?, but it?s a solution for now. > > > > I haven?t tried Stretch with the kohadevbox, but I have a feeling that it > might be OK. > > > > Hopefully this info is helpful! > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Tom?s Cohen Arazi Theke Solutions (http://theke.io) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From aurora.marquez at uca.es Wed Oct 3 12:00:50 2018 From: aurora.marquez at uca.es (=?iso-8859-1?Q?Aurora_Marquez_P=E9rez?=) Date: Wed, 3 Oct 2018 12:00:50 +0200 Subject: [Koha-devel] =?iso-8859-1?q?Implementation_of_Koha_in_the_Library?= =?iso-8859-1?q?_of_the_University_of_C=E1diz?= Message-ID: <012e01d45aff$f6db6240$e49226c0$@uca.es> Dear colleagues, after the first year in production, from the Library of the University of C?diz we decided to share our experience on migration from Millennium ILS to Koha by publishing a paper in the Spanish professional journal ?El profesional de la Informaci?n?. Implementing Koha at the University of C?diz Libray. Fern?ndez-Alfaro, Leonor; M?rquez-P?rez, Aurora; Chamorro-Rodr?guez, Ricardo (2018). "Implementation of Koha in the Library of the University of C?diz". The professional of the information, v. 27, n. 4, pp. 928-936. https://doi.org/10.3145/epi.2018.jul.21 As our situation is similar to that of many other libraries that are currently in analogous processes, we encourage you to read them as we describe the different phases of the Project: the choice of software, migration, parameterization and a final consideration as a conclusion. We hope our experience will be useful to you and, of course, we are at your disposal for any question you want to ask us. Kind regards. UCA Aurora M?rquez P?rez Coordinadora Secci?n Proceso T?cnico y Gesti?n Tecnol?gica ?rea de Biblioteca y Archivo Universidad de C?diz C/ Doctor Mara??n, 3 Edificio Andr?s Segovia 11002 - C?diz Tel 956 015273 aurora.marquez at uca.es -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 3553 bytes Desc: not available URL: From victor.grousset at biblibre.com Wed Oct 3 13:44:17 2018 From: victor.grousset at biblibre.com (Victor Grousset/tuxayo) Date: Wed, 3 Oct 2018 13:44:17 +0200 Subject: [Koha-devel] The libre Android application "Web Opac" is planning to integrate Koha Message-ID: Hi :) https://opac.app/en/ https://github.com/opacapp/opacclient https://f-droid.org/packages/de.geeksfactory.opacclient/ https://github.com/opacapp/opacclient/issues/101#issuecomment-425421264 > Status update: As Koha is becoming more popular in Germany (through LMSCloud, who offer Koha hosting), we are now starting to work on implementing full support for Koha OPACs, including account features. As the new Koha API will probably still use SRU for catalogue search, it will only work for Koha libraries that have SRU enabled. Is their analysis correct? (about SRU stuff) And could there be advice that would help them? -- Victor Grousset, dev support/maintenance BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Libre/Open Source software and services for libraries From tomascohen at gmail.com Wed Oct 3 18:48:29 2018 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 3 Oct 2018 13:48:29 -0300 Subject: [Koha-devel] KohaDevBox | Debian Stretch Message-ID: We've shifted the default OS version in KohaDevBox to Debian Stretch. We will try to keep following stable. You can still run Debian Jessie by explicitly asking for it: $ vagrant up jessie $ vagrant ssh jessie and so on. If you already have a Jessie-based box running and update the kohadevbox code, please remember to add the trailing 'jessie' word to the commands you usually ask vagrant to run. Thanks! -- Tom?s Cohen Arazi Theke Solutions (http://theke.io) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu Oct 4 02:41:47 2018 From: dcook at prosentient.com.au (David Cook) Date: Thu, 4 Oct 2018 10:41:47 +1000 Subject: [Koha-devel] Can't create new Jessie Kohadevbox In-Reply-To: References: <025801d45a36$f500ef40$df02cdc0$@prosentient.com.au> Message-ID: <010201d45b7b$08548990$18fd9cb0$@prosentient.com.au> I think switching to Stretch for the default, as per your comment at https://gitlab.com/koha-community/kohadevbox/issues/273#note_106138431, probably makes the most sense. But I think updating Ansible like you?re suggesting is probably a good idea too. I hadn?t thought of that, but that would make it so people wouldn?t have to manually workaround it. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Tomas Cohen Arazi [mailto:tomascohen at gmail.com] Sent: Tuesday, 2 October 2018 10:14 PM To: David Cook Cc: koha-devel Subject: Re: [Koha-devel] Can't create new Jessie Kohadevbox I created a Stretch one yesterday. Will check Jessie today. We can always remove the package in the ansible playbook (if distribution == 'jessie'). Regards El mar., 2 oct. 2018 a las 7:03, David Cook ( >) escribi?: Hi all, I created a Jessie Kohadevbox at the Kohacon18 hackfest and it was all good, but when I?ve tried making one back at work, it?s been failing. Josef pointed me to this issue opened by Owen: https://gitlab.com/koha-community/kohadevbox/issues/273, and I think that I?ve worked out what?s going on. It looks like there was a recent update to the python-reportbug package and it triggers the download of python-openssl version 0.14-1, which seems to create fatal errors in pip and Ansible. The workaround is to remove python-openssl and then re-provision the kohadevbox. Obviously, that?s not a great solution for a kohadevbox which should work ?out of the box?, but it?s a solution for now. I haven?t tried Stretch with the kohadevbox, but I have a feeling that it might be OK. Hopefully this info is helpful! David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- 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 Thu Oct 4 02:43:48 2018 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 3 Oct 2018 21:43:48 -0300 Subject: [Koha-devel] Can't create new Jessie Kohadevbox In-Reply-To: <010201d45b7b$08548990$18fd9cb0$@prosentient.com.au> References: <025801d45a36$f500ef40$df02cdc0$@prosentient.com.au> <010201d45b7b$08548990$18fd9cb0$@prosentient.com.au> Message-ID: David, I didn't mention it, but I tried several ways to workaround this using what you and Owen suggested. If you find a solution, I'll happily implement it out push your PR. Thanks! El mi?., 3 de oct. de 2018 21:41, David Cook escribi?: > I think switching to Stretch for the default, as per your comment at > https://gitlab.com/koha-community/kohadevbox/issues/273#note_106138431, > probably makes the most sense. > > > > But I think updating Ansible like you?re suggesting is probably a good > idea too. I hadn?t thought of that, but that would make it so people > wouldn?t have to manually workaround it. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > > Ultimo, NSW 2007 > > > Australia > > > > > Office: 02 > > 9212 0899 > > Direct: 02 8005 0595 > > > > *From:* Tomas Cohen Arazi [mailto:tomascohen at gmail.com] > *Sent:* Tuesday, 2 October 2018 10:14 PM > *To:* David Cook > *Cc:* koha-devel > *Subject:* Re: [Koha-devel] Can't create new Jessie Kohadevbox > > > > I created a Stretch one yesterday. Will check Jessie today. > > We can always remove the package in the ansible playbook (if distribution > == 'jessie'). > > > > Regards > > > > El mar., 2 oct. 2018 a las 7:03, David Cook () > escribi?: > > Hi all, > > > > I created a Jessie Kohadevbox at the Kohacon18 hackfest and it was all > good, but when I?ve tried making one back at work, it?s been failing. > > > > Josef pointed me to this issue opened by Owen: > https://gitlab.com/koha-community/kohadevbox/issues/273, and I think that > I?ve worked out what?s going on. > > > > It looks like there was a recent update to the python-reportbug package > and it triggers the download of python-openssl version 0.14-1, which seems > to create fatal errors in pip and Ansible. > > > > The workaround is to remove python-openssl and then re-provision the > kohadevbox. > > > > Obviously, that?s not a great solution for a kohadevbox which should work > ?out of the box?, but it?s a solution for now. > > > > I haven?t tried Stretch with the kohadevbox, but I have a feeling that it > might be OK. > > > > Hopefully this info is helpful! > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > > Ultimo, NSW 2007 > > > Australia > > > > > Office: 02 > > 9212 0899 > > Direct: 02 8005 0595 > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > > > > -- > > Tom?s Cohen Arazi > > Theke Solutions (http://theke.io) > ? +54 9351 3513384 > GPG: B2F3C15F > -- Tom?s Cohen Arazi Theke Solutions (https://theke.io ) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu Oct 4 03:16:56 2018 From: dcook at prosentient.com.au (David Cook) Date: Thu, 4 Oct 2018 11:16:56 +1000 Subject: [Koha-devel] Can't create new Jessie Kohadevbox In-Reply-To: References: <025801d45a36$f500ef40$df02cdc0$@prosentient.com.au> <010201d45b7b$08548990$18fd9cb0$@prosentient.com.au> Message-ID: <011201d45b7f$f0e942a0$d2bbc7e0$@prosentient.com.au> Sounds good. I?ll put it on my to do list! David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Tomas Cohen Arazi [mailto:tomascohen at gmail.com] Sent: Thursday, 4 October 2018 10:44 AM To: David Cook Cc: koha-devel Subject: Re: [Koha-devel] Can't create new Jessie Kohadevbox David, I didn't mention it, but I tried several ways to workaround this using what you and Owen suggested. If you find a solution, I'll happily implement it out push your PR. Thanks! El mi?., 3 de oct. de 2018 21:41, David Cook > escribi?: I think switching to Stretch for the default, as per your comment at https://gitlab.com/koha-community/kohadevbox/issues/273#note_106138431, probably makes the most sense. But I think updating Ansible like you?re suggesting is probably a good idea too. I hadn?t thought of that, but that would make it so people wouldn?t have to manually workaround it. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Tomas Cohen Arazi [mailto:tomascohen at gmail.com ] Sent: Tuesday, 2 October 2018 10:14 PM To: David Cook > Cc: koha-devel > Subject: Re: [Koha-devel] Can't create new Jessie Kohadevbox I created a Stretch one yesterday. Will check Jessie today. We can always remove the package in the ansible playbook (if distribution == 'jessie'). Regards El mar., 2 oct. 2018 a las 7:03, David Cook ( >) escribi?: Hi all, I created a Jessie Kohadevbox at the Kohacon18 hackfest and it was all good, but when I?ve tried making one back at work, it?s been failing. Josef pointed me to this issue opened by Owen: https://gitlab.com/koha-community/kohadevbox/issues/273, and I think that I?ve worked out what?s going on. It looks like there was a recent update to the python-reportbug package and it triggers the download of python-openssl version 0.14-1, which seems to create fatal errors in pip and Ansible. The workaround is to remove python-openssl and then re-provision the kohadevbox. Obviously, that?s not a great solution for a kohadevbox which should work ?out of the box?, but it?s a solution for now. I haven?t tried Stretch with the kohadevbox, but I have a feeling that it might be OK. Hopefully this info is helpful! David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Tom?s Cohen Arazi Theke Solutions (http://theke.io ) ? +54 9351 3513384 GPG: B2F3C15F -- Tom?s Cohen Arazi Theke Solutions (https://theke.io ) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolin.somers at biblibre.com Thu Oct 4 11:44:00 2018 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Thu, 4 Oct 2018 11:44:00 +0200 Subject: [Koha-devel] The libre Android application "Web Opac" is planning to integrate Koha In-Reply-To: References: Message-ID: Hi, We can advice that there is also OAI-PMH. But I think there is no search, its just the catalog records for harvest. They also may use opac-search.pl with RSS or ATOM format. Account features will use ILS-DI I assume ? Le 03/10/2018 ? 13:44, Victor Grousset/tuxayo a ?crit?: > Hi :) > > https://opac.app/en/ > https://github.com/opacapp/opacclient > https://f-droid.org/packages/de.geeksfactory.opacclient/ > https://github.com/opacapp/opacclient/issues/101#issuecomment-425421264 > > Status update: As Koha is becoming more popular in Germany (through > LMSCloud, who offer Koha hosting), we are now starting to work on > implementing full support for Koha OPACs, including account features. As > the new Koha API will probably still use SRU for catalogue search, it > will only work for Koha libraries that have SRU enabled. > > Is their analysis correct? (about SRU stuff) And could there be advice > that would help them? > > -- Fridolin SOMERS BibLibre, France - software and system maintainer From fridolin.somers at biblibre.com Fri Oct 5 09:34:15 2018 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Fri, 5 Oct 2018 09:34:15 +0200 Subject: [Koha-devel] Koha 17.05.14 release Message-ID: <66b5bc7c-473e-2dd4-bb37-246f0eb8f238@biblibre.com> The Koha community is proud to announce the release of Koha 17.05.14. This is a maintenance release. Packages will be available in a few days. The full release notes are available at https://koha-community.org/koha-17-05-14-release/ Important /!\ This should be the last 17.05.x release. Please consider upgrading to 17.11.x, it will be maintained for at least the next 6 months. I have proposed to continue managing 17.11.x during next release cycle. Regards, -- Fridolin SOMERS BibLibre, France - software and system maintainer From sonia.bouis at univ-lyon3.fr Sat Oct 6 10:36:55 2018 From: sonia.bouis at univ-lyon3.fr (BOUIS Sonia) Date: Sat, 6 Oct 2018 08:36:55 +0000 Subject: [Koha-devel] Translation too long Message-ID: Hello, I've noticed that there's a translation too long in french in catalogue/moredetail.pl so it's unreadable. Cf image. Is there's something to change in the code to allow a longer but clearer translation : Accession date -> Date d'entr?e dans les collections Or should we just change the translation for a shorter one ? Thanks in advance [cid:image001.png at 01D45D60.7B76E4E0] Sonia BOUIS ------------------------------------------------------ Responsable du Service des applications documentaires Biblioth?ques universitaires Universit? Jean Moulin Lyon 3 ADRESSE G?OGRAPHIQUE > Manufacture des Tabacs | 6 cours Albert Thomas | LYON 8e ADRESSE POSTALE > Biblioth?que de la Manufacture | 1C avenue des Fr?res Lumi?re | CS 78242 - 69372 LYON CEDEX 08 Ligne directe : 33 (0)4 78 78 79 03 http://bu.univ-lyon3.fr| Suivez-nous > Facebook | Twitter| Instagram --------------------------------------------------- L'Universit? Jean Moulin est membre de l'Universit? de Lyon -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 6764 bytes Desc: image001.png URL: From victor.grousset at biblibre.com Sat Oct 6 18:06:47 2018 From: victor.grousset at biblibre.com (Victor Grousset) Date: Sat, 6 Oct 2018 18:06:47 +0200 Subject: [Koha-devel] Translation too long In-Reply-To: References: Message-ID: <15d0c996-df0b-21d7-7af0-c403d8de7b59@biblibre.com> Hi, On 2018-10-06 10:36, BOUIS Sonia wrote: > I?ve noticed that there?s a translation too long in french in > catalogue/moredetail.pl so it?s unreadable. Cf image. > > Is there?s something to change in the code to allow a longer but clearer > translation : Accession date -> Date d'entr?e dans les collections > > Or should we just change the translation for a shorter one ? I noticed it and though I had changed the translation a few weeks ago. But it's not the case http://translate.koha-community.org/fr/17.11/translate/#search=Accession%20date%3A&sfields=source,target http://translate.koha-community.org/fr/18.05/translate/#search=Accession%20date%3A&sfields=source,target I though about "Date d'acquisition" which mean "Acquisition date" which seems to have a suitable meaning. -- Victor Grousset, dev support/maintenance BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Libre/Open Source software and services for libraries From david.nind at gmail.com Sat Oct 6 23:02:27 2018 From: david.nind at gmail.com (David Nind) Date: Sun, 7 Oct 2018 10:02:27 +1300 Subject: [Koha-devel] koha-testing-docker - a couple of questions Message-ID: I've been getting to grips with using koha-testing-docker ( https://gitlab.com/koha-community/koha-testing-docker) since KohaCon 18. Thanks Kyle and Tom?s for having a session on it at the HackFest! A couple of questions - apologies if the answers to these are obvious, I've not really used docker until now... I'm using docker on a Ubuntu 18.04 desktop. env/defaults.env and .env ==================== Is the copy you make of defaults.env only required because docker requires it (as instructed under Setup in the README.md file)? Anything I've updated in .env seems to be ignored in favour of what is in the env/defaults.env file, for example your Git user name and email. However, if you don't have the .env file you get this error when running docker-compose -p koha up : > WARNING: The KOHA_INTRANET_PREFIX variable is not set. Defaulting to a blank string. > WARNING: The KOHA_INSTANCE variable is not set. Defaulting to a blank string. > WARNING: The KOHA_INTRANET_SUFFIX variable is not set. Defaulting to a blank string. > WARNING: The KOHA_DOMAIN variable is not set. Defaulting to a blank string. > WARNING: The KOHA_OPAC_PREFIX variable is not set. Defaulting to a blank string. > WARNING: The KOHA_OPAC_SUFFIX variable is not set. Defaulting to a blank string. > WARNING: The RUN_TESTS_AND_EXIT variable is not set. Defaulting to a blank string. > WARNING: The COVERAGE variable is not set. Defaulting to a blank string. > ERROR: The Compose file './docker-compose.yml' is invalid because: > services.koha.networks.kohanet contains non-unique items, please remove duplicates from [u'', u''] For the moment I just make changes in env/defaults.env and copy this to .env UNIMARC support ============== Does koha-testing-docker support UNIMARC at this stage? Adding either UNIMARC or unimarc to the env/defaults.env file didn't seem to make any difference. Normally I would use MARC21, but I was trying to test a UNIMARC patch - the UNIMARC specific script said it only works on UNIMARC (surprisingly enough!). If I try reset_all_unimarc in the container it hangs at the last line: > Inserting /kohadevbox/koha/installer/data/mysql/en/marcflavour/unimarc/mandatory/authorities_normal_unimarc.sql... > Inserting /kohadevbox/koha/installer/data/mysql/en/marcflavour/unimarc/mandatory/unimarc_framework_DEFAULT.sql... > Setting the MARC flavour on the sysprefs... > Setting Koha version to 18.0600035... > Running [sudo koha-shell kohadev -p -c 'PERL5LIB=/kohadevbox/koha:/kohadevbox/qa-test-tools perl /kohadevbox/misc4dev/create_superlibrarian.pl --userid koha --password koha ']... > Running [sudo koha-shell kohadev -c 'PERL5LIB=/kohadevbox/koha:/kohadevbox/qa-test-tools perl /kohadevbox/misc4dev/insert_data.pl --marcflavour UNIMARC']... > There is no records data for UNIMARC yet at /kohadevbox/misc4dev/ insert_data.pl line 50. Also, is there an easy way to tell if Koha is using UNIMARC? I assume you can tell by looking at the default cataloguing framework (if you know what you are looking for, which I don't). Rebuilding search indexes ===================== After docker is running you don't get any search reults when searching the catalogue. Is having to rebuild the search index manually once docker has started the normal behaviour? Is it possible to have the indexes created as part of docker starting up? Or is there a reason why this isn't done? (Depending on whether you want to use Zebra or Elastic.) Getting my head around docker ========================= I found this quick guide useful to get the concepts of docker https://vsupalov.com/6-docker-basics/ As well, the docker documentation is helpful after that https://docs.docker.com/get-started/ Are there any other useful guides or tutorials that you would recommend to people new to docker? Thanks for everyone's work that has made koha-testing-docker possible! David Nind | david.nind at gmail.com PO Box 12367, Thorndon, Wellington, New Zealand 6144 m. +64 21 0537 847 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.nind at gmail.com Sat Oct 6 23:39:02 2018 From: david.nind at gmail.com (David Nind) Date: Sun, 7 Oct 2018 10:39:02 +1300 Subject: [Koha-devel] koha-testing-docker - a couple of questions In-Reply-To: References: Message-ID: And I think I forgot to mention Nick for the KohaCon session - my brain is a bit fuzzy! If I got it wrong, thanks to all those who ran the session! David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Oct 8 02:41:00 2018 From: dcook at prosentient.com.au (David Cook) Date: Mon, 8 Oct 2018 11:41:00 +1100 Subject: [Koha-devel] koha-testing-docker - a couple of questions In-Reply-To: References: Message-ID: <033a01d45e9f$95adbfb0$c1093f10$@prosentient.com.au> Hi David, I?m going to leave most of these questions for Kyle and Tomas, since they relate directly to koha-testing-docker, and I don?t have enough experience with it yet. However, I have been using Docker more and more, and my advice would be to just practice and try things out. For instance, the other day I wanted to try out https://github.com/UniversalViewer/uv-hello-world, so I just started a Docker container using a small generic Ubuntu image and did my work in there. I didn?t even bother making a Dockerfile in order to make my own image. I just created a container as a sort of workspace. Once I?d tried out the software, I exited and let the container destroy itself. I had to play with the options a bit (like --rm and -p) to get what I wanted, but it was such a basic use case that it was really easy to see what was going on. Jessie Frazelle used to maintain the Docker core and I love this blog post of hers: https://blog.jessfraz.com/post/docker-containers-on-the-desktop/. It inspired me to use a Docker container for running the Arduino IDE on my Debian desktop at home. I haven?t shared my Dockerfile and scripts yet for that, but you can find something similar at https://github.com/tombenke/darduino. Btw, Jessie Frazelle is funny, nice, and really smart. Worth reading her blog in general as she focuses a lot on containers, although it tends to be more intermediate/advanced level I reckon. More recently, I?ve been making my own Docker images for other work projects and I?ve been thinking about Dockerizing a lot of the apps I?ve made at home for my own purposes. I just haven?t gotten to it yet. But really the world is your oyster! Hope that?s a bit inspiring at least? heh. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of David Nind Sent: Sunday, 7 October 2018 8:02 AM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] koha-testing-docker - a couple of questions I've been getting to grips with using koha-testing-docker (https://gitlab.com/koha-community/koha-testing-docker) since KohaCon 18. Thanks Kyle and Tom?s for having a session on it at the HackFest! A couple of questions - apologies if the answers to these are obvious, I've not really used docker until now... I'm using docker on a Ubuntu 18.04 desktop. env/defaults.env and .env ==================== Is the copy you make of defaults.env only required because docker requires it (as instructed under Setup in the README.md file)? Anything I've updated in .env seems to be ignored in favour of what is in the env/defaults.env file, for example your Git user name and email. However, if you don't have the .env file you get this error when running docker-compose -p koha up : > WARNING: The KOHA_INTRANET_PREFIX variable is not set. Defaulting to a blank string. > WARNING: The KOHA_INSTANCE variable is not set. Defaulting to a blank string. > WARNING: The KOHA_INTRANET_SUFFIX variable is not set. Defaulting to a blank string. > WARNING: The KOHA_DOMAIN variable is not set. Defaulting to a blank string. > WARNING: The KOHA_OPAC_PREFIX variable is not set. Defaulting to a blank string. > WARNING: The KOHA_OPAC_SUFFIX variable is not set. Defaulting to a blank string. > WARNING: The RUN_TESTS_AND_EXIT variable is not set. Defaulting to a blank string. > WARNING: The COVERAGE variable is not set. Defaulting to a blank string. > ERROR: The Compose file './docker-compose.yml' is invalid because: > services.koha.networks.kohanet contains non-unique items, please remove duplicates from [u'', u''] For the moment I just make changes in env/defaults.env and copy this to .env UNIMARC support ============== Does koha-testing-docker support UNIMARC at this stage? Adding either UNIMARC or unimarc to the env/defaults.env file didn't seem to make any difference. Normally I would use MARC21, but I was trying to test a UNIMARC patch - the UNIMARC specific script said it only works on UNIMARC (surprisingly enough!). If I try reset_all_unimarc in the container it hangs at the last line: > Inserting /kohadevbox/koha/installer/data/mysql/en/marcflavour/unimarc/mandatory/authorities_normal_unimarc.sql... > Inserting /kohadevbox/koha/installer/data/mysql/en/marcflavour/unimarc/mandatory/unimarc_framework_DEFAULT.sql... > Setting the MARC flavour on the sysprefs... > Setting Koha version to 18.0600035... > Running [sudo koha-shell kohadev -p -c 'PERL5LIB=/kohadevbox/koha:/kohadevbox/qa-test-tools perl /kohadevbox/misc4dev/create_superlibrarian.pl --userid koha --password koha ']... > Running [sudo koha-shell kohadev -c 'PERL5LIB=/kohadevbox/koha:/kohadevbox/qa-test-tools perl /kohadevbox/misc4dev/insert_data.pl --marcflavour UNIMARC']... > There is no records data for UNIMARC yet at /kohadevbox/misc4dev/insert_data.pl line 50. Also, is there an easy way to tell if Koha is using UNIMARC? I assume you can tell by looking at the default cataloguing framework (if you know what you are looking for, which I don't). Rebuilding search indexes ===================== After docker is running you don't get any search reults when searching the catalogue. Is having to rebuild the search index manually once docker has started the normal behaviour? Is it possible to have the indexes created as part of docker starting up? Or is there a reason why this isn't done? (Depending on whether you want to use Zebra or Elastic.) Getting my head around docker ========================= I found this quick guide useful to get the concepts of docker https://vsupalov.com/6-docker-basics/ As well, the docker documentation is helpful after that https://docs.docker.com/get-started/ Are there any other useful guides or tutorials that you would recommend to people new to docker? Thanks for everyone's work that has made koha-testing-docker possible! David Nind | david.nind at gmail.com PO Box 12367, Thorndon, Wellington, New Zealand 6144 m. +64 21 0537 847 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sonia.bouis at univ-lyon3.fr Mon Oct 8 12:19:57 2018 From: sonia.bouis at univ-lyon3.fr (BOUIS Sonia) Date: Mon, 8 Oct 2018 10:19:57 +0000 Subject: [Koha-devel] [Koha-translate] Translation too long In-Reply-To: <15d0c996-df0b-21d7-7af0-c403d8de7b59@biblibre.com> References: <15d0c996-df0b-21d7-7af0-c403d8de7b59@biblibre.com> Message-ID: Thanks Victor. There's already an order date tn this page and this date (accession date) is more related to the creation date of the item. But, if it's not a problem in the template, we will find a suitable translation. It would be great to know if there are constraints on template about the length of the sentence when we are translating. I don't know if it occurs in other pages... Regards -----Message d'origine----- De?: koha-translate-bounces at lists.koha-community.org [mailto:koha-translate-bounces at lists.koha-community.org] De la part de Victor Grousset Envoy??: samedi 6 octobre 2018 18:07 ??: koha-devel at lists.koha-community.org; Koha-translate at lists.koha-community.org Objet?: Re: [Koha-translate] [Koha-devel] Translation too long Hi, On 2018-10-06 10:36, BOUIS Sonia wrote: > I've noticed that there's a translation too long in french in > catalogue/moredetail.pl so it's unreadable. Cf image. > > Is there's something to change in the code to allow a longer but > clearer translation : Accession date -> Date d'entr?e dans les > collections > > Or should we just change the translation for a shorter one ? I noticed it and though I had changed the translation a few weeks ago. But it's not the case http://translate.koha-community.org/fr/17.11/translate/#search=Accession%20date%3A&sfields=source,target http://translate.koha-community.org/fr/18.05/translate/#search=Accession%20date%3A&sfields=source,target I though about "Date d'acquisition" which mean "Acquisition date" which seems to have a suitable meaning. -- Victor Grousset, dev support/maintenance BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Libre/Open Source software and services for libraries _______________________________________________ Koha-translate mailing list Koha-translate at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate website: www.koha-community.org git: git.koha-community.org bugs: bugs.koha-community.org From jonathan.druart at bugs.koha-community.org Mon Oct 8 20:52:56 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Mon, 8 Oct 2018 15:52:56 -0300 Subject: [Koha-devel] [Koha-translate] Translation too long In-Reply-To: References: <15d0c996-df0b-21d7-7af0-c403d8de7b59@biblibre.com> Message-ID: Salut Sonia, I would say you should open a bug report and... fix the translation until it's not fixed :) I am not sure we will be able to provide a quick and global solution for this problem. Cheers, Jonathan On Mon, 8 Oct 2018 at 07:19 BOUIS Sonia wrote: > Thanks Victor. > > There's already an order date tn this page and this date (accession date) > is more related to the creation date of the item. > But, if it's not a problem in the template, we will find a suitable > translation. > It would be great to know if there are constraints on template about the > length of the sentence when we are translating. > I don't know if it occurs in other pages... > > Regards > > -----Message d'origine----- > De : koha-translate-bounces at lists.koha-community.org [mailto: > koha-translate-bounces at lists.koha-community.org] De la part de Victor > Grousset > Envoy? : samedi 6 octobre 2018 18:07 > ? : koha-devel at lists.koha-community.org; > Koha-translate at lists.koha-community.org > Objet : Re: [Koha-translate] [Koha-devel] Translation too long > > Hi, > > On 2018-10-06 10:36, BOUIS Sonia wrote: > > I've noticed that there's a translation too long in french in > > catalogue/moredetail.pl so it's unreadable. Cf image. > > > > Is there's something to change in the code to allow a longer but > > clearer translation : Accession date -> Date d'entr?e dans les > > collections > > > > Or should we just change the translation for a shorter one ? > > > I noticed it and though I had changed the translation a few weeks ago. > But it's not the case > > http://translate.koha-community.org/fr/17.11/translate/#search=Accession%20date%3A&sfields=source,target > > http://translate.koha-community.org/fr/18.05/translate/#search=Accession%20date%3A&sfields=source,target > > I though about "Date d'acquisition" which mean "Acquisition date" which > seems to have a suitable meaning. > > > -- > Victor Grousset, dev support/maintenance > BibLibre, Services en logiciels libres pour les biblioth?ques > BibLibre, Libre/Open Source software and services for libraries > _______________________________________________ > Koha-translate mailing list > Koha-translate at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate > website: www.koha-community.org > git: git.koha-community.org > bugs: bugs.koha-community.org > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Tue Oct 9 17:13:48 2018 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 9 Oct 2018 11:13:48 -0400 Subject: [Koha-devel] [Koha-translate] Translation too long In-Reply-To: References: <15d0c996-df0b-21d7-7af0-c403d8de7b59@biblibre.com> Message-ID: > I've noticed that there's a translation too long in french in > catalogue/moredetail.pl so it's unreadable. Cf image. This is a problem with the page's stylesheet which can be corrected immediately by adding some CSS to your intranetUserCSS system preference: ol.bibliodetails li { clear: left; } .label { white-space: normal; border-radius: 0; text-align: left; line-height: inherit; } I have filed Bug 21522 for an official fix. -- Owen -- Web Developer Athens County Public Libraries https://www.myacpl.org From theod at physics.auth.gr Wed Oct 10 15:25:11 2018 From: theod at physics.auth.gr (Theodoros Theodoropoulos) Date: Wed, 10 Oct 2018 16:25:11 +0300 Subject: [Koha-devel] Possible issues with 942$0 (totalissues) values? Message-ID: <0721357b-aaa8-a79e-1423-3c2cd93838a6@physics.auth.gr> Hello everyone, There might be some issues in Koha involving 942$0, update_totalissues script and sorting by popularity. If I understand correctly, the update_totalissues script updates biblioitems.totalissues and updates the 942$0 too (see C4::UpdateTotalIssues). Also I believe that sorting by popularity is based on the indexed 942$0 values and not on the values in biblioitems.totalissues So, I think there are a couple of cases where this number can be inaccurate leading to a false sorting-by-polularity. 1. If the value is prefilled by the script, regardless of the 942$0 subfield being hidden in the Marc framework, a librarian with cataloguing permissions may go into the marc editor and change it directly. That number will be indexed by zebra and used in sorting by popularity. The only way of 942$0 being 'fixed' by the system is after a checkout of an item of this biblio is made. Then, the update_totalissues script will requery the DB tables to count the total number of checkouts and update 942$0 2. Likewise, when a librarian with cataloguing permissions duplicates a biblio record with a value in 942$0, this value will be copied to the cloned record as well. As you imagine, this is wrong because it's a NEW biblio record (and probably has no items yet, so no checkouts), so 942$0 should be initially 0. Again this 'cloned' value will be taken by the system as the 'official' number of total checkouts for this biblio (at least for sorting purposes) and will remain there until a checkout of an item of this biblio is made (so the script will recalculate the proper number and hopefully update it) The 1st cannot be solved by simply 'hiding' 942$0 in the Default framework. The script will have the value filled, so the subfield will be visible and editable. Is there a way to hide (or make readonly) certain fields from the cataloguer (even in the advanced editor?). Maybe a new syspref could be incorporated to restrict viewing/editing of certain MARC field/subfields? The 2nd issue seems equally (if not more) important because it's more likely to happen. I vaguely remember a discussion from the past where it was mentioned that by selecting 'flagged' in "Edit Framework Subfields > Advanced constraint values > Visibility", the value of that subfield would not be cloned in a new biblio, but I couldn't reproduce it in my tests. Maybe we could use this for differentiating the case when all checkboxes are unchecked and where flagged is selected? (I believe that right now the behavior of these two is identical). I'm only thinking aloud, so any ideas/comments would be more than welcome! Kind regards, Theodoros Theodoropoulos From martin.renvoize at ptfs-europe.com Fri Oct 12 09:43:16 2018 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Fri, 12 Oct 2018 08:43:16 +0100 Subject: [Koha-devel] Invitation to join the core team Message-ID: Hi everyone, I just wanted to remind you all that the role proposals page for the upcoming 19.05 development cycle is available at https://wiki.koha-community.org/wiki/Roles_for_19.05 and we'd love to see some new names on the volunteers' list. The vote on roles will be held at the next irc general meeting. Roles to draw your attention to: * Bug Wranglers - We can always do with more bug wranglers! These people love to keep things tidy and Bugzilla is always in need of your help. We need people to help manage 'the list', identifying the duplicates, promoting bugs to specialists and finding people to do signoffs and testing. Everyone is invited to this party, we need you! * Documentation Team - The documentation team is a growing team that's made great inroads into bringing Koha's documentation up to date and ensuring we have a really well-documented piece of software. There's plenty more to do and they're always on the lookout for new contributors. * Wiki Curators - Koha's wiki is bursting at the seams with good information, but we need your help to bring order to the chaos and keep improving the content. If you've got an interest in maintaining an area of the Wiki, helping identify out of date information or categorizing data then this is a job for you. * Quality Assurance Team - This vitally important team is always looking for new recruits! If you've got an eye for detail, or you're a tester who likes rolling up their sleeves a little bit and looking at how a piece of code works, then we'd love to hear from you. Again, there's always support available from 'the usual suspects' so don't shy away, why not make this your first cycle on the QA team and see how much fun it can be working with this important team. * Quality Assurance Topic Expert - Do you know one particular area of koha better than the rest? Are you the 'go to' guy (or gal) for SIP2, EDI, Acquisitions or another area of Koha? We'd like to hear from you too. You don't have to know the whole codebase to be a great QA Specialist, you're an expert in what you know and we always need more experts. * Release Maintainer 18.05 - I've enjoyed being RMaint this last five months, and have offered to take up the mantle again for the next 'stable' (18.11) release. So, we need someone to take up my mantle and maintain 'oldstable' (18.05). As ever, the community is a great place and lots of support will be available to show you the ropes. See https://wiki.koha-community.org/wiki/Release_maintenance for a description of the day to day activities of this role. Those are just a few highlights, please see the wiki page above for the full list. *Martin Renvoize* Development Team Manager *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize at ptfs-europe.com *Fax:* +44 (0) 800 756 6384 www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info at ptfs-europe.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at pobox.com Fri Oct 12 19:46:12 2018 From: marka at pobox.com (Mark Alexander) Date: Fri, 12 Oct 2018 13:46:12 -0400 Subject: [Koha-devel] Kanopy and SIP2 hack Message-ID: <1539365380-sup-1998@x201s> Our little library is preparing to use the Kanopy video streaming service. Kanopy can use SIP2 to query our Koha server for the purpose of user authentication. That's great; I can enable SIP2 pretty easily. The problem is that our librarian wants to put limits on which patrons can use Kanopy. The idea is that we don't want to allow more than one person per household to be able stream videos; otherwise mom, pop, and all the kids could go crazy one weekend on a Buffy The Vampire Slayer binge, for example. But Kanopy and Koha don't have a way to impose this kind of limit. So I came up with the following idea, which does seem to work in my test VM: 1. Add a new patron attribute called "KANOPY_OK", which has a yes/no value. Set it to yes for those patrons that will be allowed access to Kanopy. 2. Hack the SIP server code for "handle patron status" to check the incoming client's IP address against a Kanopy-provided list of IP addresses. If there is a match, authenticate the patron only if their "KANOPY_OK" atribute is "yes" (actually "1"). But I hate the fact that I had to hack Koha to do this (see part of the hack below). Am I'm going at this the wrong way? Would it make more sense to enhance the plugin architecture to add a SIP2 patron filter function like the one below? Is this just too ugly to ever be considered seriously? Thanks in advance, Mark P.S. Here's the main part of the hack, which is a function that is called from handle_patron_status and handle_patron_info. my @kanopy_ips = ( "208.66.24.46", "104.239.197.182", "18.209.148.51", "34.232.89.121", "34.234.81.211", "34.235.227.70", "34.235.53.173", "52.203.108.44" ); sub sip2_check_patron { my ( $patron, $server ) = @_; if ( $patron ) { my $ipaddr = $server->{server}->{client}->peerhost; foreach my $kanopy ( @kanopy_ips ) { if ( $ipaddr =~ /^(::ffff:)?\Q$kanopy\E$/ ) { my $borrowernumber = $patron->{borrowernumber}; my $value = C4::Members::Attributes::GetBorrowerAttributeValue( $borrowernumber, 'KANOPY_OK' $ return $value eq "1"; } } } return 1; } From katrin.fischer.83 at web.de Sun Oct 14 12:02:44 2018 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Sun, 14 Oct 2018 12:02:44 +0200 Subject: [Koha-devel] Kanopy and SIP2 hack In-Reply-To: <1539365380-sup-1998@x201s> References: <1539365380-sup-1998@x201s> Message-ID: Hi Mark, reading your use case made me think of some open bugs we have, the first being maybe a similar use case to yours: *Bug?16694* - Limit SIP2 auth by patron attribute *Bug?10077* - Pass extended patron attributes via Borrower SIP protocol Hope this helps, Katrin On 12.10.2018 19:46, Mark Alexander wrote: > Our little library is preparing to use the Kanopy video streaming > service. Kanopy can use SIP2 to query our Koha server for the purpose > of user authentication. That's great; I can enable SIP2 pretty > easily. > > The problem is that our librarian wants to put limits on which patrons > can use Kanopy. The idea is that we don't want to allow more than > one person per household to be able stream videos; otherwise mom, pop, > and all the kids could go crazy one weekend on a Buffy The Vampire Slayer > binge, for example. > > But Kanopy and Koha don't have a way to impose this kind of limit. > So I came up with the following idea, which does seem to work in > my test VM: > > 1. Add a new patron attribute called "KANOPY_OK", which has a yes/no value. > Set it to yes for those patrons that will be allowed access to Kanopy. > > 2. Hack the SIP server code for "handle patron status" to check the incoming client's > IP address against a Kanopy-provided list of IP addresses. If there is a match, > authenticate the patron only if their "KANOPY_OK" atribute is "yes" (actually "1"). > > But I hate the fact that I had to hack Koha to do this (see part of > the hack below). Am I'm going at this the wrong way? Would it make > more sense to enhance the plugin architecture to add a SIP2 patron > filter function like the one below? Is this just too ugly to ever > be considered seriously? > > Thanks in advance, > Mark > > P.S. Here's the main part of the hack, which is a function that is called > from handle_patron_status and handle_patron_info. > > my @kanopy_ips = ( > "208.66.24.46", > "104.239.197.182", > "18.209.148.51", > "34.232.89.121", > "34.234.81.211", > "34.235.227.70", > "34.235.53.173", > "52.203.108.44" > ); > > sub sip2_check_patron { > my ( $patron, $server ) = @_; > > if ( $patron ) { > my $ipaddr = $server->{server}->{client}->peerhost; > foreach my $kanopy ( @kanopy_ips ) { > if ( $ipaddr =~ /^(::ffff:)?\Q$kanopy\E$/ ) { > my $borrowernumber = $patron->{borrowernumber}; > my $value = C4::Members::Attributes::GetBorrowerAttributeValue( $borrowernumber, 'KANOPY_OK' $ > return $value eq "1"; > } > } > } > return 1; > } > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at pobox.com Sun Oct 14 15:12:59 2018 From: marka at pobox.com (Mark Alexander) Date: Sun, 14 Oct 2018 09:12:59 -0400 Subject: [Koha-devel] Kanopy and SIP2 hack In-Reply-To: References: <1539365380-sup-1998@x201s> Message-ID: <1539522043-sup-9905@x201s> Excerpts from Katrin Fischer's message of 2018-10-14 12:02:44 +0200: > reading your use case made me think of some open bugs we have, the first > being maybe a similar use case to yours: > > *Bug?16694* > - > Limit SIP2 auth by patron attribute Thank you for that! It's very similar, except that our use case is more complicated than I said. It turns out our library has to deal with two different services in the SIP2 code. One service is Kanopy, as I mentioned; the other is a consortium connected to Overdrive that provides ebooks and audio books. Each service has to be handled slightly differently, perhaps using a separate patron attribute for each. We need to find out which service is performing the SIP2 request by examining the client IP address. In the bug mentioned above, Marcel suggested putting the validation code in Patron.pm. But our very site-specific complications led me to think of putting the validation code into a plugin. From kohanews at gmail.com Wed Oct 17 03:42:04 2018 From: kohanews at gmail.com (kohanews) Date: Tue, 16 Oct 2018 18:42:04 -0700 Subject: [Koha-devel] Call for News: October 2018 Newsletter Message-ID: <1ec87407-346d-3674-5a9c-8eeab222f930@gmail.com> I'm collecting news for the October newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: ?? - Please include dates for past events. If I can't find dates I may not add it. ?? - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon ?? - For past events , **** one month back is the cut-off? ****. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. Thank you! -- Chad Roseburg Editor, Koha Community Newsletter From dcook at prosentient.com.au Wed Oct 17 11:06:37 2018 From: dcook at prosentient.com.au (David Cook) Date: Wed, 17 Oct 2018 20:06:37 +1100 Subject: [Koha-devel] Generic OpenIDConnect client Message-ID: <03a101d465f8$b5feb390$21fc1ab0$@prosentient.com.au> Hi all, About 4 years ago, I wrote a generic OpenIDConnect client, and kept telling myself that I would upstream it but I never did. until now: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21586. I wrote it for 1 specific client, so it exists heavily in a set of "Prosentient" namespaces and some of the code is legacy from 3.14 and could be replaced by modern code (I'm looking at you Koha::Prosentient::Borrowers), but maybe people can try it out and give me some feedback to make it worthy of a sign off, or people can adapt it and I can give feedback. (I already have some things I would like to change. I think I overuse base64url. but it is essential when working with JWTs. I think I just got carried away with a substitution command once.) I know we already have the GoogleOpenIdConnect. I actually wrote this code before that code existed, but I don't think my code would work for Google the way it is now. It would probably need some alterations. Anyway, I was sick of telling myself that I would upstream it one day, so I sat down and made a patch and now it's shared. Cheers, David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at enger.priv.no Wed Oct 17 15:48:27 2018 From: magnus at enger.priv.no (Magnus Enger) Date: Wed, 17 Oct 2018 15:48:27 +0200 Subject: [Koha-devel] Is finesMode = test still operational and sending emails? Message-ID: Hi! The help of the cronjob fines.pl says: This script calculates and charges overdue fines to patron accounts. The Koha system preference 'finesMode' controls whether the fines are calculated and charged to the patron accounts ("Calculate and charge"); calculated and emailed to the admin but not applied ("Calculate (but only for mailing to the admin)"); or not calculated ("Don't calculate"). I have a library set up with finesMode = test and as far as I can tell everything is as it should be. But no emails are sent to KohaAdminEmailAddress. Reading through fines.pl I can see it generating a file, but not doing any emailing. Am I missing something or did we loose the emailing somewhere along the way? Best regards, Magnus From tomascohen at gmail.com Wed Oct 17 15:48:52 2018 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 17 Oct 2018 10:48:52 -0300 Subject: [Koha-devel] Generic OpenIDConnect client In-Reply-To: <03a101d465f8$b5feb390$21fc1ab0$@prosentient.com.au> References: <03a101d465f8$b5feb390$21fc1ab0$@prosentient.com.au> Message-ID: David, it is nice to see your code submitted! I implemented a generic prototype too, based on the current code for Google's. At that point the doubts I had were about how to inject new routes for the callback. But that's solved the way we did in bug 21116. I didn't submit my prototype because: - I wasn't able to inject routes (yet) - A page for CRUD operations on OAuth providers needs to be implemented - An attribute mapping UI needs to be added for each OAuth provider - I had the feeling this should be done with plugins. Because every implementation has its details that make them less compatible with the other. This are my thoughts on the subject as well! El mi?., 17 oct. 2018 a las 6:07, David Cook () escribi?: > Hi all, > > > > About 4 years ago, I wrote a generic OpenIDConnect client, and kept > telling myself that I would upstream it but I never did? until now: > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21586. > > > > I wrote it for 1 specific client, so it exists heavily in a set of > ?Prosentient? namespaces and some of the code is legacy from 3.14 and could > be replaced by modern code (I?m looking at you > Koha::Prosentient::Borrowers), but maybe people can try it out and give me > some feedback to make it worthy of a sign off, or people can adapt it and I > can give feedback. (I already have some things I would like to change. I > think I overuse base64url? but it is essential when working with JWTs. I > think I just got carried away with a substitution command once.) > > > > I know we already have the GoogleOpenIdConnect. I actually wrote this code > before that code existed, but I don?t think my code would work for Google > the way it is now. It would probably need some alterations. > > > > Anyway, I was sick of telling myself that I would upstream it one day, so > I sat down and made a patch and now it?s shared. > > > > Cheers, > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Tom?s Cohen Arazi Theke Solutions (http://theke.io) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtompset at hotmail.com Wed Oct 17 17:00:02 2018 From: mtompset at hotmail.com (Mark Tompsett) Date: Wed, 17 Oct 2018 15:00:02 +0000 Subject: [Koha-devel] Generic OpenIDConnect client In-Reply-To: References: <03a101d465f8$b5feb390$21fc1ab0$@prosentient.com.au> Message-ID: Greetings, tcohen wrote in response to dcook?s request for feedback: > - I had the feeling this should be done with plugins. > Because every implementation has its details that make them less compatible with the other. I concur with this idea. Tangentially, it would also make refactoring authentication easier. Right now, certain combinations of authentication work in a particular order, and there is no way to change that. Plugins would let us access them in a particular order, and even configure them IN the staff client, not just koha-conf.xml which gets filled pretty quickly with authentication cruft (ldap, shibboleth, cas, etc.) GPML, Mark Tompsett -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Wed Oct 17 17:08:43 2018 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 17 Oct 2018 12:08:43 -0300 Subject: [Koha-devel] Generic OpenIDConnect client In-Reply-To: References: <03a101d465f8$b5feb390$21fc1ab0$@prosentient.com.au> Message-ID: We would still need to refactor and modularize auth El mi?., 17 de oct. de 2018 12:00, Mark Tompsett escribi?: > Greetings, > > tcohen wrote in response to dcook?s request for feedback: > > - I had the feeling this should be done with plugins. > > Because every implementation has its details that make them less > compatible with the other. > > I concur with this idea. > > Tangentially, it would also make refactoring authentication easier. > Right now, certain combinations of authentication work in a particular > order, and there is no way to change that. > Plugins would let us access them in a particular order, and even configure > them IN the staff client, not just > koha-conf.xml which gets filled pretty quickly with authentication cruft > (ldap, shibboleth, cas, etc.) > > GPML, > Mark Tompsett > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Thu Oct 18 01:38:43 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Wed, 17 Oct 2018 20:38:43 -0300 Subject: [Koha-devel] Master broken by 20521 (sql modes) Message-ID: Hi devs, I quick email to let you know that master and tests are (completely) broken because of the recent push of bug 20521. It turned on the "problematic SQL modes" for dev installs (I let you search for that in your emails if it did not ring you the bell). I am working on fixing the different test failures (the ones we introduced since bug 20144, 6 months ago). They are all regressions and there are a lot! This shows us that we absolutely need this change, to alert us when we are doing something wrong, that's why I would not recommend a revert. If you are stuck in something urgent/important you can revert commit aafd0476342ca9691fd8a7c2c754c425ae1cf61f Bug 20521: Enable problematic SQL modes for dev installs Or easier, remove the dev_install flag in your koha-conf (but do not forget to switch it back in a few days!). Cheers, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer.83 at web.de Thu Oct 18 07:11:13 2018 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Thu, 18 Oct 2018 07:11:13 +0200 Subject: [Koha-devel] Master broken by 20521 (sql modes) In-Reply-To: References: Message-ID: <43514a39-5eaf-0fee-6e3a-64b869c9182e@web.de> Hi all, I guess this effects the sandboxes as well? This afternoon and tomorrow morning is a hackday in Sweden and I was hoping for some sign-offs! Katrin On 18.10.18 01:38, Jonathan Druart wrote: > Hi devs, > > I quick email to let you know that master and tests are (completely) > broken because of the recent push of bug 20521. > It turned on the "problematic SQL modes" for dev installs (I let you > search for that in your emails if it did not ring you the bell). > > I am working on fixing the different test failures (the ones we > introduced since bug 20144, 6 months ago). They are all regressions > and there are a lot! > > This shows us that we absolutely need this change, to alert us when we > are doing something wrong, that's why I would not recommend a revert. > > If you are stuck in something urgent/important you can revert > ? commit aafd0476342ca9691fd8a7c2c754c425ae1cf61f > ? Bug 20521: Enable problematic SQL modes for dev installs > Or easier, remove the dev_install flag in your koha-conf (but do not > forget to switch it back in a few days!). > > Cheers, > Jonathan > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.renvoize at ptfs-europe.com Thu Oct 18 10:09:42 2018 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Thu, 18 Oct 2018 09:09:42 +0100 Subject: [Koha-devel] Master broken by 20521 (sql modes) In-Reply-To: <43514a39-5eaf-0fee-6e3a-64b869c9182e@web.de> References: <43514a39-5eaf-0fee-6e3a-64b869c9182e@web.de> Message-ID: The Bywater one's may be stuffed by this (assuming they all set dev_install inside their koha-testing-docker based setup).. but the ptfs-e one's don't yet set dev_install so they should be fine I think. *Martin Renvoize* Development Team Manager *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize at ptfs-europe.com *Fax:* +44 (0) 800 756 6384 www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info at ptfs-europe.com On Thu, 18 Oct 2018 at 06:11, Katrin Fischer wrote: > Hi all, > > I guess this effects the sandboxes as well? This afternoon and tomorrow > morning is a hackday in Sweden and I was hoping for some sign-offs! > > Katrin > On 18.10.18 01:38, Jonathan Druart wrote: > > Hi devs, > > I quick email to let you know that master and tests are (completely) > broken because of the recent push of bug 20521. > It turned on the "problematic SQL modes" for dev installs (I let you > search for that in your emails if it did not ring you the bell). > > I am working on fixing the different test failures (the ones we introduced > since bug 20144, 6 months ago). They are all regressions and there are a > lot! > > This shows us that we absolutely need this change, to alert us when we are > doing something wrong, that's why I would not recommend a revert. > > If you are stuck in something urgent/important you can revert > commit aafd0476342ca9691fd8a7c2c754c425ae1cf61f > Bug 20521: Enable problematic SQL modes for dev installs > Or easier, remove the dev_install flag in your koha-conf (but do not > forget to switch it back in a few days!). > > Cheers, > Jonathan > > _______________________________________________ > Koha-devel mailing listKoha-devel at lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer.83 at web.de Thu Oct 18 10:20:55 2018 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Thu, 18 Oct 2018 10:20:55 +0200 Subject: [Koha-devel] Master broken by 20521 (sql modes) In-Reply-To: References: <43514a39-5eaf-0fee-6e3a-64b869c9182e@web.de> Message-ID: <91310ef9-c345-8be5-101c-2fdb35ca7210@web.de> I've tested the Bywater sandboxes - can confirm some of the basics features are broken. On 18.10.18 10:09, Renvoize, Martin wrote: > The Bywater one's may be stuffed by this (assuming they all set > dev_install inside their koha-testing-docker based setup).. but the > ptfs-e one's don't yet set dev_install so they should be fine I think. > > > *Martin Renvoize* > > > > > > Development Team Manager > > *Phone:*?+44 (0) 1483 378728 > > > > *Mobile:*?+44 (0) 7725 985 636 > > *Email:* martin.renvoize at ptfs-europe.com > > > > > *Fax:*?+44 (0) 800 756 6384 > > > > > www.ptfs-europe.com > > Registered in the United Kingdom No. 06416372???VAT Reg No. 925 7211 30 > > > The information contained in this email message may be privileged, > confidential and protected from disclosure. If you are not the > intended recipient, any dissemination, distribution or copying is > strictly prohibited. If you think that you have received this email > message in error, please email the sender at info at ptfs-europe.com > > > > > > On Thu, 18 Oct 2018 at 06:11, Katrin Fischer > wrote: > > Hi all, > > I guess this effects the sandboxes as well? This afternoon and > tomorrow morning is a hackday in Sweden and I was hoping for some > sign-offs! > > Katrin > > On 18.10.18 01:38, Jonathan Druart wrote: >> Hi devs, >> >> I quick email to let you know that master and tests are >> (completely) broken because of the recent push of bug 20521. >> It turned on the "problematic SQL modes" for dev installs (I let >> you search for that in your emails if it did not ring you the bell). >> >> I am working on fixing the different test failures (the ones we >> introduced since bug 20144, 6 months ago). They are all >> regressions and there are a lot! >> >> This shows us that we absolutely need this change, to alert us >> when we are doing something wrong, that's why I would not >> recommend a revert. >> >> If you are stuck in something urgent/important you can revert >> ? commit aafd0476342ca9691fd8a7c2c754c425ae1cf61f >> ? Bug 20521: Enable problematic SQL modes for dev installs >> Or easier, remove the dev_install flag in your koha-conf (but do >> not forget to switch it back in a few days!). >> >> Cheers, >> Jonathan >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website :http://www.koha-community.org/ >> git :http://git.koha-community.org/ >> bugs :http://bugs.koha-community.org/ > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bargioni at pusc.it Thu Oct 18 15:56:53 2018 From: bargioni at pusc.it (Stefano Bargioni) Date: Thu, 18 Oct 2018 15:56:53 +0200 Subject: [Koha-devel] bulkmarcimport -d and -fk Message-ID: <41901D82-345A-4881-93CB-668B21A2CF31@pusc.it> Hi, all, before adding a bug, I'd like to discuss this issue with others. For testing, I installed Koha 18.06.00.032 and Elasticsearch on a Debian 8 virtual machine, using packages koha-common and koha-elasticsearch. Mysql is "mysql Ver 14.14 Distrib 5.5.60, for debian-linux-gnu (x86_64) using readline 6.3". bulkmarcimport.pl -d fails with errors like Cannot truncate a table referenced in a foreign key constraint when going to truncate tables biblio, biblioitems, items. The -fk option is required. This is probably due to the more strict "way of life" of Mysql. Do we need to force -fk when -d is specified? Or simply we have to update the -h documentation? Thx. Stefano From jonathan.druart at bugs.koha-community.org Fri Oct 19 00:40:35 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Thu, 18 Oct 2018 19:40:35 -0300 Subject: [Koha-devel] Master broken by 20521 (sql modes) In-Reply-To: References: Message-ID: Hi all, Today's update: Good news, master is no longer broken, but not fixed! :) A new entry from koha-conf is going to be used: without 1 you will not be impacted by the recent failures. We are going to turn it on for Jenkins. I still recommend you to turn it on in order to catch inconsistencies in our code. If you find bugs, you can create a new one and link it to the existing omnibus (bug 17258). Make sure it's not fixed yet, there a quite a bunch waiting in the bug tracker. Waiting for a signoff: Bug 21603 - Remove Group by clause in SearchCourses Bug 21604 - Cannot add/edit funds, cannot add budgets Bug 21606 - Issues with matching rules Bug 21610 - Koha::Object->store needs to handle incorrect values Bug 21612 - Incorrect GROUP BY in Koha::Virtualshelves Waiting for a patch: Bug 21605 - Cannot create EDI account Cheers, Jonathan On Wed, 17 Oct 2018 at 20:38 Jonathan Druart < jonathan.druart at bugs.koha-community.org> wrote: > Hi devs, > > I quick email to let you know that master and tests are (completely) > broken because of the recent push of bug 20521. > It turned on the "problematic SQL modes" for dev installs (I let you > search for that in your emails if it did not ring you the bell). > > I am working on fixing the different test failures (the ones we introduced > since bug 20144, 6 months ago). They are all regressions and there are a > lot! > > This shows us that we absolutely need this change, to alert us when we are > doing something wrong, that's why I would not recommend a revert. > > If you are stuck in something urgent/important you can revert > commit aafd0476342ca9691fd8a7c2c754c425ae1cf61f > Bug 20521: Enable problematic SQL modes for dev installs > Or easier, remove the dev_install flag in your koha-conf (but do not > forget to switch it back in a few days!). > > Cheers, > Jonathan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barton at bywatersolutions.com Fri Oct 19 17:59:08 2018 From: barton at bywatersolutions.com (Barton Chittenden) Date: Fri, 19 Oct 2018 11:59:08 -0400 Subject: [Koha-devel] SQL queries showing data that will cause software errors. In-Reply-To: <8885f437-b5da-5d72-9ae1-ab57cffc458a@web.de> References: <8885f437-b5da-5d72-9ae1-ab57cffc458a@web.de> Message-ID: Here's another data issue we run into sometimes -- the date from items.onloan does not match issues.date_due This is an actual bug; I have *no* idea what triggers it, but I know that I've seen it happen in the wild. SELECT biblionumber, itemnumber FROM items left join issues WHERE items.onloan != date(issues.date_due) On Sat, Sep 29, 2018 at 5:48 AM Katrin Fischer wrote: > Hi Barton, > > I think holds on items without item types is a special case of "items > without itemtypes". Generally items without itemtypes (with > item-level_itype on items) will cause problems with Koha and should be > avoided. I think the best option would be to make itemtype mandatory now > that bug 14662 is fixed. > > Jonathan has started a new script to catch inconsistencies like that, that > can check for missing itemtypes: > > Bug 21150 - Data inconsistencies - item types > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21150 > > It can also check for false authority types, and missing holdingbranch and > homebranch in items. More could be added to it. > > Hope this helps, > > Katrin > > On 28.09.2018 21:20, Barton Chittenden wrote: > > When ByWater started upgrading our partners to 17.11 last spring, I > noticed that we were getting a lot of errors of the form > > "can't call method * on an undefined value at ..." > > We're starting to see these errors because more and more of our code uses > Koha objects, and these will fail if a method is called on an undefined > object. > > I brought this up here: > http://lists.koha-community.org/pipermail/koha-devel/2018-June/044613.html > > I think that there was also another thread about this, which I can't find > at the moment... Jonathan's opinion on this is that we should start > creating queries which find data that will fail. This thread is for those > queries, since I have an example: > > Circulating or holdable items without item type > > SELECT > biblionumber, > itemnumber, > barcode, > title, > notforloan > FROM > items > INNER JOIN biblio USING (biblionumber) > WHERE > notforloan < 1 > AND itype IS NULL > > Once we have a few of these at hand, I'll start a page on the Koha wiki. > > > > _______________________________________________ > Koha-devel mailing listKoha-devel at lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From barton at bywatersolutions.com Mon Oct 22 15:48:09 2018 From: barton at bywatersolutions.com (Barton Chittenden) Date: Mon, 22 Oct 2018 09:48:09 -0400 Subject: [Koha-devel] Questions about terminology Message-ID: I've been looking at the Koha terminology page ( https://wiki.koha-community.org/wiki/Terminology). There are still a handful of occurrences of incorrect terminology throughout the '.tt' files. I'm starting with looking for instances of 'biblio', which should be 'Bibliographic record'. I'm wondering about instances of "Biblio number" in the text... I think that "Bibliographic number" is actually *less* clear... "Bibliographic Record Number" is better, but in most cases where Biblio number is used (e.g. the Marc Editor), Biblio number makes sense in its context. Cheers, --Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Mon Oct 22 16:14:27 2018 From: oleonard at myacpl.org (Owen Leonard) Date: Mon, 22 Oct 2018 10:14:27 -0400 Subject: [Koha-devel] Questions about terminology In-Reply-To: References: Message-ID: > I'm starting with looking for instances of 'biblio', which should be 'Bibliographic record'. Hopefully Bug 19833 took care of (most of?) them. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19833 > I'm wondering about instances of "Biblio number" in the text... I think that > "Bibliographic number" is actually *less* clear... "Bibliographic Record Number" > is better, but in most cases where Biblio number is used (e.g. the Marc Editor), > Biblio number makes sense in its context. As a human-readable term I prefer "Bibliographic record number." However, operations which reference biblionumber should all be fairly technical, and thus a technical term might be appropriate. I'm curious what edge cases there might be that don't fall into the "technical" category. On the other hand, if we expect these more technical users to know what biblionumber is... how did they learn? -- Owen -- Web Developer Athens County Public Libraries https://www.myacpl.org From barton at bywatersolutions.com Mon Oct 22 18:27:05 2018 From: barton at bywatersolutions.com (Barton Chittenden) Date: Mon, 22 Oct 2018 12:27:05 -0400 Subject: [Koha-devel] Questions about terminology In-Reply-To: References: Message-ID: On Mon, Oct 22, 2018 at 10:14 AM Owen Leonard wrote: > > I'm starting with looking for instances of 'biblio', which should be > 'Bibliographic record'. > > Hopefully Bug 19833 took care of (most of?) them. > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19833 I found a dozen or so in master. > > I'm wondering about instances of "Biblio number" in the text... I think > that > > "Bibliographic number" is actually *less* clear... "Bibliographic Record > Number" > > is better, but in most cases where Biblio number is used (e.g. the Marc > Editor), > > Biblio number makes sense in its context. > > As a human-readable term I prefer "Bibliographic record number." > However, operations which reference biblionumber should all be fairly > technical, and thus a technical term might be appropriate. I'm curious > what edge cases there might be that don't fall into the "technical" > category. > Most of the ones that I found were via grepping, I'm going to be looking at them in more detail shortly, so I'll have more context. > On the other hand, if we expect these more technical users to know > what biblionumber is... how did they learn? > I'm guessing that most probably learn from the URL or the database schema/reports library. It depends on level of expertise, I'm sure. I suppose I could ask on the koha general mailing list... --Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From liz at catalyst.net.nz Mon Oct 22 21:39:46 2018 From: liz at catalyst.net.nz (Liz Rea) Date: Tue, 23 Oct 2018 08:39:46 +1300 Subject: [Koha-devel] Questions about terminology In-Reply-To: Message-ID: <9e7c5a65-2718-4f87-96ca-c1e004c00602@email.android.com> An HTML attachment was scrubbed... URL: From indradg at l2c2.co.in Mon Oct 22 21:58:36 2018 From: indradg at l2c2.co.in (Indranil Das Gupta) Date: Tue, 23 Oct 2018 01:28:36 +0530 Subject: [Koha-devel] Questions about terminology In-Reply-To: <9e7c5a65-2718-4f87-96ca-c1e004c00602@email.android.com> References: <9e7c5a65-2718-4f87-96ca-c1e004c00602@email.android.com> Message-ID: On 23 October 2018 at 01:09, Liz Rea wrote: With that in mind, I don't see why we would need to drop biblionumber at > all - it references exactly what it is, is specific to Koha, and can be > understood and trained in that context, fully independent of MARC. > +1 cheers -idg -------------- next part -------------- An HTML attachment was scrubbed... URL: From barton at bywatersolutions.com Mon Oct 22 22:02:49 2018 From: barton at bywatersolutions.com (Barton Chittenden) Date: Mon, 22 Oct 2018 16:02:49 -0400 Subject: [Koha-devel] Questions about terminology In-Reply-To: <9e7c5a65-2718-4f87-96ca-c1e004c00602@email.android.com> References: <9e7c5a65-2718-4f87-96ca-c1e004c00602@email.android.com> Message-ID: On Mon, Oct 22, 2018 at 3:39 PM Liz Rea wrote: > The term bibliographic number is easily confused with "inventory number" > and any local or old internal record numbers that migrated MARC may have. > Agreed, bibliographic number is confusing. > > I think the most accurate long form representation is "Koha internal > record number", as the biblionumber has nothing at all to do with MARC, and > wouldn't necessarily be carried over to another system if the record was > moved (not that anybody would *leave* Koha, amirite). > > With that in mind, I don't see why we would need to drop biblionumber at > all - it references exactly what it is, is specific to Koha, and can be > understood and trained in that context, fully independent of MARC. > I think the use of biblionumber is fine in context -- that's generally used specifically when database tables are being mentioned. The term 'Biblio number' (containing a space) is what I'm more concerned about. I don't know that the marc editor was the only place that I saw that used. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liz at catalyst.net.nz Tue Oct 23 00:03:48 2018 From: liz at catalyst.net.nz (Liz Rea) Date: Tue, 23 Oct 2018 11:03:48 +1300 Subject: [Koha-devel] Questions about terminology In-Reply-To: References: <9e7c5a65-2718-4f87-96ca-c1e004c00602@email.android.com> Message-ID: Personally, I'd probably convert any "Biblio number" into "Biblionumber," and if that needs explaining, it's the "Koha internal record number" or "Koha unique record identifier" On 23/10/18 09:02, Barton Chittenden wrote: > On Mon, Oct 22, 2018 at 3:39 PM Liz Rea wrote: > >> The term bibliographic number is easily confused with "inventory number" >> and any local or old internal record numbers that migrated MARC may have. >> > Agreed, bibliographic number is confusing. > >> I think the most accurate long form representation is "Koha internal >> record number", as the biblionumber has nothing at all to do with MARC, and >> wouldn't necessarily be carried over to another system if the record was >> moved (not that anybody would *leave* Koha, amirite). >> >> With that in mind, I don't see why we would need to drop biblionumber at >> all - it references exactly what it is, is specific to Koha, and can be >> understood and trained in that context, fully independent of MARC. >> > I think the use of biblionumber is fine in context -- that's generally used > specifically when database tables are being mentioned. The term 'Biblio > number' (containing a space) is what I'm more concerned about. I don't know > that the marc editor was the only place that I saw that used. > -- -- Liz Rea Catalyst.Net Limited Level 6, Catalyst House, 150 Willis Street, Wellington. P.O Box 11053, Manners Street, Wellington 6142 04 803 2265 GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7 From dcook at prosentient.com.au Tue Oct 23 04:07:17 2018 From: dcook at prosentient.com.au (David Cook) Date: Tue, 23 Oct 2018 13:07:17 +1100 Subject: [Koha-devel] Replacing koha-plack, koha-start-zebra, etc with systemd services? Message-ID: <066401d46a75$1f7d99f0$5e78cdd0$@prosentient.com.au> Hi all, I'm about to start working on a systemd service for running Plack (for a non-package Koha install), and I was wondering if anyone else has thought about or is using systemd services for Plack, Zebra, etc. Mason did a great job with a systemd service https://github.com/KohaAloha/koha-mysql-init/blob/master/koha-mysql-init.ser vice for getting around the autoincrement issue (fixed in MySQL 8.0 https://dev.mysql.com/doc/refman/8.0/en/innodb-auto-increment-handling.html and MariaDB 10.2.4 https://mariadb.com/kb/en/library/auto_increment/). Anyway, once I've got something working, I'm happy to share it. Curious if anyone has any systemd unit files they'd like to share. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Oct 23 04:45:41 2018 From: dcook at prosentient.com.au (David Cook) Date: Tue, 23 Oct 2018 13:45:41 +1100 Subject: [Koha-devel] Replacing koha-plack, koha-start-zebra, etc with systemd services? In-Reply-To: <066401d46a75$1f7d99f0$5e78cdd0$@prosentient.com.au> References: <066401d46a75$1f7d99f0$5e78cdd0$@prosentient.com.au> Message-ID: <066e01d46a7a$7cb5f180$7621d480$@prosentient.com.au> Hi all, Here's what I came up with. I based the command against the koha-plack script. I think a person could use systemd "instances" to make some of the command arguments more dynamic, which you'd want for a package install. One could also explore other configuration options. I suppose we could also have a wrapper script executed instead of executing starman directly. Lots of possibilities! SystemD Service File: ################################################################## [Unit] Description=Koha Test Plack [Service] ExecStart=/usr/bin/starman \ --max-requests 50 \ --workers 2 \ --access-log /opt/koha/logs/plack.log \ --error-log /opt/koha/logs/plack-error.log \ -E deployment \ --socket /opt/koha/var/plack.sock \ /opt/koha/plack.psgi Environment=PERL5LIB=/opt/koha/lib Environment=KOHA_CONF=/opt/koha/etc/koha-conf.xml Environment=KOHA_HOME=/opt/koha Restart=always RestartSec=15 [Install] WantedBy=multi-user.target ################################################################## David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of David Cook Sent: Tuesday, 23 October 2018 1:07 PM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] Replacing koha-plack, koha-start-zebra, etc with systemd services? Hi all, I'm about to start working on a systemd service for running Plack (for a non-package Koha install), and I was wondering if anyone else has thought about or is using systemd services for Plack, Zebra, etc. Mason did a great job with a systemd service https://github.com/KohaAloha/koha-mysql-init/blob/master/koha-mysql-init.ser vice for getting around the autoincrement issue (fixed in MySQL 8.0 https://dev.mysql.com/doc/refman/8.0/en/innodb-auto-increment-handling.html and MariaDB 10.2.4 https://mariadb.com/kb/en/library/auto_increment/). Anyway, once I've got something working, I'm happy to share it. Curious if anyone has any systemd unit files they'd like to share. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.moravec at gmail.com Tue Oct 23 12:07:37 2018 From: josef.moravec at gmail.com (Josef Moravec) Date: Tue, 23 Oct 2018 12:07:37 +0200 Subject: [Koha-devel] New Rest API RFCs Message-ID: Hello developers, Me and Michal Denar were thinking a bit about some REST api endpoints, write down some rfcs and would like to see any comment on them ;) Thanks in advance https://wiki.koha-community.org/wiki/Checkouts_endpoint_RFC https://wiki.koha-community.org/wiki/Availability_endpoints_RFC In this one we heavily used Katrin's comments and proposed new object definition, thanks Katrin ;) https://wiki.koha-community.org/wiki/Items_endpoint_RFC -- Josef Moravec josef.moravec at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Tue Oct 23 13:49:52 2018 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Tue, 23 Oct 2018 11:49:52 +0000 Subject: [Koha-devel] New Rest API RFCs In-Reply-To: References: Message-ID: +1 Just glacing through I saw external_id for barcode. Not sure if that is a good choice btw. I do not recognize external as meaning barcode, rfid or qr code. What about something with tag, label ? And id or code ? Checkout availability is kind of a hard term to me? Loanable ? And reservable, can_be_reserved ? Is 403 the right response for not available ? 404 or 400 ? Marcel ________________________________ Van: koha-devel-bounces at lists.koha-community.org namens Josef Moravec Verzonden: dinsdag 23 oktober 2018 12:07:37 Aan: koha-devel Onderwerp: [Koha-devel] New Rest API RFCs Hello developers, Me and Michal Denar were thinking a bit about some REST api endpoints, write down some rfcs and would like to see any comment on them ;) Thanks in advance https://wiki.koha-community.org/wiki/Checkouts_endpoint_RFC https://wiki.koha-community.org/wiki/Availability_endpoints_RFC In this one we heavily used Katrin's comments and proposed new object definition, thanks Katrin ;) https://wiki.koha-community.org/wiki/Items_endpoint_RFC -- Josef Moravec josef.moravec at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From barton at bywatersolutions.com Tue Oct 23 14:42:21 2018 From: barton at bywatersolutions.com (Barton Chittenden) Date: Tue, 23 Oct 2018 08:42:21 -0400 Subject: [Koha-devel] New Rest API RFCs In-Reply-To: References: Message-ID: I'm not a big fan of items.onloan... If you want to check item availability, use the checkouts API. ...and then I realized that there's no route for items in the checkouts API. On Tue, Oct 23, 2018, 6:07 AM Josef Moravec wrote: > Hello developers, > > Me and Michal Denar were thinking a bit about some REST api endpoints, > write down some rfcs and would like to see any comment on them ;) > > Thanks in advance > > https://wiki.koha-community.org/wiki/Checkouts_endpoint_RFC > https://wiki.koha-community.org/wiki/Availability_endpoints_RFC > > In this one we heavily used Katrin's comments and proposed new object > definition, thanks Katrin ;) > https://wiki.koha-community.org/wiki/Items_endpoint_RFC > > -- > Josef Moravec > josef.moravec at gmail.com > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Tue Oct 23 14:51:31 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Tue, 23 Oct 2018 09:51:31 -0300 Subject: [Koha-devel] Bugs for 18.11 Message-ID: Hi devs, I have started using the 'rel_18_11_candidate' bugzilla keyword to keep track of the bugs we need to fix before the release. Here is the list: https://frama.link/koha_bz_rel_18_11_candidate They are either regressions or bug fixes for new features of 18.11. They should be considered as high priority (blocker for the release) for the next weeks. Cheers, Jonathan PS: You really should bookmark this link ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From irma at calyx.net.au Tue Oct 23 15:31:32 2018 From: irma at calyx.net.au (Irma Birchall) Date: Wed, 24 Oct 2018 00:31:32 +1100 Subject: [Koha-devel] Questions about terminology In-Reply-To: References: <9e7c5a65-2718-4f87-96ca-c1e004c00602@email.android.com> Message-ID: Hi Liz and Barton, About "I think the most accurate long form representation is "Koha internal record number", as the biblionumber has nothing at all to do with MARC" I received this feedback from Libraries Australia today : *MARC Field 035 $a - System Control Number : Koha Record Numbers* <> Every record should have one instance of MARC field 035 containing the current Koha record number before re-exporting. So simply call biblionumber <> "Koha record number"? Irma CALYX On 23 October 2018 at 09:03, Liz Rea wrote: > Personally, I'd probably convert any "Biblio number" into > "Biblionumber," and if that needs explaining, it's the "Koha internal > record number" or "Koha unique record identifier" > > > On 23/10/18 09:02, Barton Chittenden wrote: > > On Mon, Oct 22, 2018 at 3:39 PM Liz Rea wrote: > > > >> The term bibliographic number is easily confused with "inventory number" > >> and any local or old internal record numbers that migrated MARC may > have. > >> > > Agreed, bibliographic number is confusing. > > > >> I think the most accurate long form representation is "Koha internal > >> record number", as the biblionumber has nothing at all to do with MARC, > and > >> wouldn't necessarily be carried over to another system if the record was > >> moved (not that anybody would *leave* Koha, amirite). > >> > >> With that in mind, I don't see why we would need to drop biblionumber at > >> all - it references exactly what it is, is specific to Koha, and can be > >> understood and trained in that context, fully independent of MARC. > >> > > I think the use of biblionumber is fine in context -- that's generally > used > > specifically when database tables are being mentioned. The term 'Biblio > > number' (containing a space) is what I'm more concerned about. I don't > know > > that the marc editor was the only place that I saw that used. > > > > -- > -- > Liz Rea > Catalyst.Net Limited > Level 6, Catalyst House, > 150 Willis Street, Wellington. > P.O Box 11053, Manners Street, > Wellington 6142 > 04 803 2265 > > GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7 > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Tue Oct 23 15:34:54 2018 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 23 Oct 2018 10:34:54 -0300 Subject: [Koha-devel] New Rest API RFCs In-Reply-To: References: Message-ID: https://github.com/thekesolutions/koha-plugin-bibliocommons/blob/master/Koha/Plugin/Com/Theke/BiblioCommons/ItemsController.pm#L145-L179 El mar., 23 oct. 2018 a las 10:21, Barton Chittenden (< barton at bywatersolutions.com>) escribi?: > I'm not a big fan of items.onloan... If you want to check item > availability, use the checkouts API. > > ...and then I realized that there's no route for items in the checkouts > API. > > On Tue, Oct 23, 2018, 6:07 AM Josef Moravec > wrote: > >> Hello developers, >> >> Me and Michal Denar were thinking a bit about some REST api endpoints, >> write down some rfcs and would like to see any comment on them ;) >> >> Thanks in advance >> >> https://wiki.koha-community.org/wiki/Checkouts_endpoint_RFC >> https://wiki.koha-community.org/wiki/Availability_endpoints_RFC >> >> In this one we heavily used Katrin's comments and proposed new object >> definition, thanks Katrin ;) >> https://wiki.koha-community.org/wiki/Items_endpoint_RFC >> >> -- >> Josef Moravec >> josef.moravec at gmail.com >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Tom?s Cohen Arazi Theke Solutions (http://theke.io) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Tue Oct 23 16:21:06 2018 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 23 Oct 2018 11:21:06 -0300 Subject: [Koha-devel] Questions about terminology In-Reply-To: References: <9e7c5a65-2718-4f87-96ca-c1e004c00602@email.android.com> Message-ID: The API uses: "internally assigned biblio identifier" El mar., 23 oct. 2018 a las 10:32, Irma Birchall () escribi?: > Hi Liz and Barton, > > About "I think the most accurate long form representation is "Koha > internal record number", as the biblionumber has nothing at all to do with > MARC" > > I received this feedback from Libraries Australia today : > > *MARC Field 035 $a - System Control Number : Koha Record Numbers* <> > Every record should have one instance of MARC field 035 containing the > current Koha record number before re-exporting. > > So simply call biblionumber <> "Koha record number"? > > Irma > CALYX > > > > On 23 October 2018 at 09:03, Liz Rea wrote: > >> Personally, I'd probably convert any "Biblio number" into >> "Biblionumber," and if that needs explaining, it's the "Koha internal >> record number" or "Koha unique record identifier" >> >> >> On 23/10/18 09:02, Barton Chittenden wrote: >> > On Mon, Oct 22, 2018 at 3:39 PM Liz Rea wrote: >> > >> >> The term bibliographic number is easily confused with "inventory >> number" >> >> and any local or old internal record numbers that migrated MARC may >> have. >> >> >> > Agreed, bibliographic number is confusing. >> > >> >> I think the most accurate long form representation is "Koha internal >> >> record number", as the biblionumber has nothing at all to do with >> MARC, and >> >> wouldn't necessarily be carried over to another system if the record >> was >> >> moved (not that anybody would *leave* Koha, amirite). >> >> >> >> With that in mind, I don't see why we would need to drop biblionumber >> at >> >> all - it references exactly what it is, is specific to Koha, and can be >> >> understood and trained in that context, fully independent of MARC. >> >> >> > I think the use of biblionumber is fine in context -- that's generally >> used >> > specifically when database tables are being mentioned. The term 'Biblio >> > number' (containing a space) is what I'm more concerned about. I don't >> know >> > that the marc editor was the only place that I saw that used. >> > >> >> -- >> -- >> Liz Rea >> Catalyst.Net Limited >> Level 6, Catalyst House, >> 150 Willis Street, Wellington. >> P.O Box 11053, Manners Street, >> Wellington 6142 >> 04 803 2265 >> >> GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7 >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ >> > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Tom?s Cohen Arazi Theke Solutions (http://theke.io) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From ere.maijala at helsinki.fi Tue Oct 23 16:24:39 2018 From: ere.maijala at helsinki.fi (Ere Maijala) Date: Tue, 23 Oct 2018 17:24:39 +0300 Subject: [Koha-devel] New Rest API RFCs In-Reply-To: References: Message-ID: <3d184ac6-e360-f579-482f-eef4654a856c@helsinki.fi> Josef, Thanks for the taking the initiative! I added some comments about the checkouts endpoint in the wiki, but perhaps it's easier to discuss here, so I'll add them here too: While fetching the information about the checkout itself is a good start, often some more information is needed, and if it means that several requests need to be made, things get slow pretty quickly. So I'd suggest adding an expanded version of the response with at least the following extra information. This is based on my experiences with integrating several different ILS's with our VuFind based discovery interface. 1. Renewability 2. Maximum number of renewals 3. Basic information about the biblio and item (biblio.biblionumber, biblio.title, items.barcode, items.enumchron) When there are a lot of loans, supporting server-side paging and sorting can make a huge difference (especially with the expanded response). This could be accomplished with the addition of offset, limit and sort parameters. 403 is valid response code if you try to renew a non-renewable loan, but error codes should not be used to indicate a status. So the renewability check should rather return 200 and an actual response telling if renewal is possible. Regards, Ere Josef Moravec kirjoitti 23.10.2018 klo 13.07: > Hello developers, > > Me and Michal Denar were thinking a bit about some REST api endpoints, > write down some rfcs and would like to see any comment on them ;) > > Thanks in advance > > https://wiki.koha-community.org/wiki/Checkouts_endpoint_RFC > https://wiki.koha-community.org/wiki/Availability_endpoints_RFC > > In this one we heavily used Katrin's comments and proposed new object > definition, thanks Katrin ;) > https://wiki.koha-community.org/wiki/Items_endpoint_RFC > > -- > Josef Moravec > josef.moravec at gmail.com > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Ere Maijala Kansalliskirjasto / The National Library of Finland From martin.renvoize at ptfs-europe.com Tue Oct 23 18:11:51 2018 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Tue, 23 Oct 2018 17:11:51 +0100 Subject: [Koha-devel] Koha 18.05.05 release Message-ID: The Koha community is proud to announce the release of Koha 18.05.05. This is a maintenance release containing 67 bugfixes The full release notes are available at https://koha-community.org/koha-18-05-05-release/ Debian packages will be updated within a few days Many thanks to everyone involved, *Martin Renvoize* Development Team Manager *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize at ptfs-europe.com *Fax:* +44 (0) 800 756 6384 www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info at ptfs-europe.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Wed Oct 24 06:42:52 2018 From: dcook at prosentient.com.au (David Cook) Date: Wed, 24 Oct 2018 15:42:52 +1100 Subject: [Koha-devel] Generic OpenIDConnect client In-Reply-To: References: <03a101d465f8$b5feb390$21fc1ab0$@prosentient.com.au> Message-ID: <008a01d46b54$060e6aa0$122b3fe0$@prosentient.com.au> Thanks for your feedback, Tomas! Apologies for my delay in responding. I hadn?t thought about making it so that web users could configure providers? but that could be interesting. I think that?s a good point with the plugins. Even with the 3 providers with which I integrate, I notice implementation differences. Some of them legitimate and some illegitimate according to the OpenIDConnect specification. I really like the idea of refactoring and modularizing auth. I think maybe my patch actually shows that it shouldn?t be that hard to create hooks for authentication plugins. I?m swamped at the moment (like usual) but it would be fun/interesting to try? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Tomas Cohen Arazi [mailto:tomascohen at gmail.com] Sent: Thursday, 18 October 2018 12:49 AM To: David Cook Cc: koha-devel Subject: Re: [Koha-devel] Generic OpenIDConnect client David, it is nice to see your code submitted! I implemented a generic prototype too, based on the current code for Google's. At that point the doubts I had were about how to inject new routes for the callback. But that's solved the way we did in bug 21116. I didn't submit my prototype because: - I wasn't able to inject routes (yet) - A page for CRUD operations on OAuth providers needs to be implemented - An attribute mapping UI needs to be added for each OAuth provider - I had the feeling this should be done with plugins. Because every implementation has its details that make them less compatible with the other. This are my thoughts on the subject as well! El mi?., 17 oct. 2018 a las 6:07, David Cook ( >) escribi?: Hi all, About 4 years ago, I wrote a generic OpenIDConnect client, and kept telling myself that I would upstream it but I never did? until now: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21586. I wrote it for 1 specific client, so it exists heavily in a set of ?Prosentient? namespaces and some of the code is legacy from 3.14 and could be replaced by modern code (I?m looking at you Koha::Prosentient::Borrowers), but maybe people can try it out and give me some feedback to make it worthy of a sign off, or people can adapt it and I can give feedback. (I already have some things I would like to change. I think I overuse base64url? but it is essential when working with JWTs. I think I just got carried away with a substitution command once.) I know we already have the GoogleOpenIdConnect. I actually wrote this code before that code existed, but I don?t think my code would work for Google the way it is now. It would probably need some alterations. Anyway, I was sick of telling myself that I would upstream it one day, so I sat down and made a patch and now it?s shared. Cheers, David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Tom?s Cohen Arazi Theke Solutions (http://theke.io ) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From Holger.Meissner at hs-gesundheit.de Wed Oct 24 12:37:48 2018 From: Holger.Meissner at hs-gesundheit.de (Holger Meissner) Date: Wed, 24 Oct 2018 10:37:48 +0000 Subject: [Koha-devel] Price format in order by email Message-ID: <6279fdc754b1421ebe529ca076e8e263@nExchange1.hsg.intra> Dear koha devs, when we send an order by email <> is formatted with decimal point and six decimal places, in spite of syspref CurrencyFormat set to EUR. Is anyone working on this? Is there some kind of workaround? koha version 17.11.10.000. Thanks, Holger From fridolin.somers at biblibre.com Wed Oct 24 13:14:43 2018 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Wed, 24 Oct 2018 13:14:43 +0200 Subject: [Koha-devel] Koha 17.11.11 release Message-ID: <13368f30-39aa-e721-dd63-d8482df66fac@biblibre.com> The Koha community is proud to announce the release of Koha 17.11.11. This is a maintenance release. The full release notes are available at https://koha-community.org/koha-17-11-11-release/ Debian packages will be upgraded in a few days. I've proposed to continue maitaining 17.11.x in Koha 19.05 roles. Regards, -- Fridolin SOMERS BibLibre, France - software and system maintainer From barton at bywatersolutions.com Wed Oct 24 15:39:42 2018 From: barton at bywatersolutions.com (Barton Chittenden) Date: Wed, 24 Oct 2018 09:39:42 -0400 Subject: [Koha-devel] Price format in order by email In-Reply-To: <6279fdc754b1421ebe529ca076e8e263@nExchange1.hsg.intra> References: <6279fdc754b1421ebe529ca076e8e263@nExchange1.hsg.intra> Message-ID: I'm guessing that this could be fixed using template toolkit in the notice, but I don't know the syntax off hand. On Wed, Oct 24, 2018, 6:38 AM Holger Meissner < Holger.Meissner at hs-gesundheit.de> wrote: > Dear koha devs, > > when we send an order by email <> is formatted with > decimal point and six decimal places, in spite of syspref CurrencyFormat > set to EUR. > > Is anyone working on this? Is there some kind of workaround? > > koha version 17.11.10.000. > > Thanks, > Holger > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Holger.Meissner at hs-gesundheit.de Wed Oct 24 17:08:55 2018 From: Holger.Meissner at hs-gesundheit.de (Holger Meissner) Date: Wed, 24 Oct 2018 15:08:55 +0000 Subject: [Koha-devel] Price format in order by email Message-ID: Thank you, Barton! [%- USE Price -%] [% <> | $Price %] did the trick :) From jonathan.druart at bugs.koha-community.org Wed Oct 24 17:32:48 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Wed, 24 Oct 2018 12:32:48 -0300 Subject: [Koha-devel] Price format in order by email In-Reply-To: References: Message-ID: Indeed, you should use the TT syntax, but not both :) Can you try the following instead: [%- USE Price -%] [% order | $Price %] You certainly need to loop on "orders" before. On Wed, 24 Oct 2018 at 12:08 Holger Meissner < Holger.Meissner at hs-gesundheit.de> wrote: > Thank you, Barton! > > [%- USE Price -%] > [% <> | $Price %] > > did the trick :) > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtompset at hotmail.com Wed Oct 24 18:42:31 2018 From: mtompset at hotmail.com (Mark Tompsett) Date: Wed, 24 Oct 2018 16:42:31 +0000 Subject: [Koha-devel] The order of "use" Message-ID: Greetings, I was looking at bug 21641, and noticed the patch was explicitly stating C4::Accounts:: on the function in question. I vaguely recalled this sort of symptom shows itself in a knotted ?use? mess. C4::Circulation ?> C4::Members ?> C4::Accounts C4::Circulation ?> C4::Accounts C4::Circulation ?> C4::Overdues ?> C4::Accounts What is the best order to list these? C4::Accounts last? Is putting the C4::Accounts:: on the function in question still something we should do anyways? Feedback appreciated, Mark Tompsett From jonathan.druart at bugs.koha-community.org Wed Oct 24 19:21:03 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Wed, 24 Oct 2018 14:21:03 -0300 Subject: [Koha-devel] The order of "use" In-Reply-To: References: Message-ID: See commit ce96080f3005be5a63c9f2cab8d4b6c81e9b5b27 Bug 21133: Fix use statements order On Wed, 24 Oct 2018 at 13:42 Mark Tompsett wrote: > Greetings, > > I was looking at bug 21641, and noticed the patch was explicitly stating > C4::Accounts:: on the function in question. I vaguely recalled this sort > of > symptom shows itself in a knotted ?use? mess. > > C4::Circulation ?> C4::Members ?> C4::Accounts > C4::Circulation ?> C4::Accounts > C4::Circulation ?> C4::Overdues ?> C4::Accounts > > What is the best order to list these? C4::Accounts last? > Is putting the C4::Accounts:: on the function in question still something > we > should do anyways? > > Feedback appreciated, > Mark Tompsett > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu Oct 25 01:24:26 2018 From: dcook at prosentient.com.au (David Cook) Date: Thu, 25 Oct 2018 10:24:26 +1100 Subject: [Koha-devel] The order of "use" In-Reply-To: References: Message-ID: <013401d46bf0$b44e7230$1ceb5690$@prosentient.com.au> Whether or not to prefix the function with "C4::Accounts::" is something we should probably talk about at some point. Historically, a lot of Koha modules use the "Exporter" module to export their functions into the main namespace of the caller. When "use C4::Accounts" runs, it automatically calls the "import" function in C4::Accounts, which in most/all cases is provided by the Exporter module. Blah blah blah. You can use the syntax "use C4::Accounts qw()" to prevent the importing of any functions or you can selectively import functions with "use C4::Accounts qw(function1 function2)". Fun times... If you don't automatically import functions into the main namespace of the caller, then you'd want to definitely prefix the function with C4::Accounts::, otherwise you'll get an error since that function would be declared in the main namespace (or worse it's the same function name and you wind up with more errors/unexpected behaviour). Personally, I rather use object oriented programming like we're trying in the Koha:: modules and/or have function libraries that don't use Exporter and instead require use of full namespace (e.g. C4::Accounts::function1). I think that's just a lot more transparent. More verbose but more explicit and easier to understand. Also fewer changes of function name collisions and less messy main namespace in the caller. That's my 2 cents. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Mark Tompsett Sent: Thursday, 25 October 2018 3:43 AM To: Koha-devel Subject: [Koha-devel] The order of "use" Greetings, I was looking at bug 21641, and noticed the patch was explicitly stating C4::Accounts:: on the function in question. I vaguely recalled this sort of symptom shows itself in a knotted ?use? mess. C4::Circulation ?> C4::Members ?> C4::Accounts C4::Circulation ?> C4::Accounts C4::Circulation ?> C4::Overdues ?> C4::Accounts What is the best order to list these? C4::Accounts last? Is putting the C4::Accounts:: on the function in question still something we should do anyways? Feedback appreciated, Mark Tompsett _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From jonathan.druart at bugs.koha-community.org Thu Oct 25 01:49:12 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Wed, 24 Oct 2018 20:49:12 -0300 Subject: [Koha-devel] The order of "use" In-Reply-To: <013401d46bf0$b44e7230$1ceb5690$@prosentient.com.au> References: <013401d46bf0$b44e7230$1ceb5690$@prosentient.com.au> Message-ID: "At some point", yes... *Bug 8244* - Script to find exporter problems *Bug 17600* - Standardize the EXPORT On Wed, 24 Oct 2018 at 20:24 David Cook wrote: > Whether or not to prefix the function with "C4::Accounts::" is something > we should probably talk about at some point. > > Historically, a lot of Koha modules use the "Exporter" module to export > their functions into the main namespace of the caller. When "use > C4::Accounts" runs, it automatically calls the "import" function in > C4::Accounts, which in most/all cases is provided by the Exporter module. > Blah blah blah. You can use the syntax "use C4::Accounts qw()" to prevent > the importing of any functions or you can selectively import functions with > "use C4::Accounts qw(function1 function2)". Fun times... > > If you don't automatically import functions into the main namespace of the > caller, then you'd want to definitely prefix the function with > C4::Accounts::, otherwise you'll get an error since that function would be > declared in the main namespace (or worse it's the same function name and > you wind up with more errors/unexpected behaviour). > > Personally, I rather use object oriented programming like we're trying in > the Koha:: modules and/or have function libraries that don't use Exporter > and instead require use of full namespace (e.g. C4::Accounts::function1). I > think that's just a lot more transparent. More verbose but more explicit > and easier to understand. Also fewer changes of function name collisions > and less messy main namespace in the caller. > > That's my 2 cents. > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St > Ultimo, NSW 2007 > Australia > > Office: 02 9212 0899 <02%2092%2012%2008%2099> > Direct: 02 8005 0595 <02%2080%2005%2005%2095> > > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] On Behalf Of Mark Tompsett > Sent: Thursday, 25 October 2018 3:43 AM > To: Koha-devel > Subject: [Koha-devel] The order of "use" > > Greetings, > > I was looking at bug 21641, and noticed the patch was explicitly stating > C4::Accounts:: on the function in question. I vaguely recalled this sort > of symptom shows itself in a knotted ?use? mess. > > C4::Circulation ?> C4::Members ?> C4::Accounts C4::Circulation ?> > C4::Accounts C4::Circulation ?> C4::Overdues ?> C4::Accounts > > What is the best order to list these? C4::Accounts last? > Is putting the C4::Accounts:: on the function in question still something > we should do anyways? > > Feedback appreciated, > Mark Tompsett > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : > http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu Oct 25 02:38:22 2018 From: dcook at prosentient.com.au (David Cook) Date: Thu, 25 Oct 2018 11:38:22 +1100 Subject: [Koha-devel] The order of "use" In-Reply-To: References: <013401d46bf0$b44e7230$1ceb5690$@prosentient.com.au> Message-ID: <013d01d46bfb$08aa9f70$19ffde50$@prosentient.com.au> I meant on koha-devel, but here we are now. Ahh I see https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17600#c82. It is frustrating when we don?t get the feedback for which we?re hoping. I actually don?t monitor the Koha Bugs List listserv as the volume is just too high(I?m 55,000 emails behind apparently) and I have too much other work to do, so I never even knew about this bug. I?m sure I must not be alone in not monitoring that listserv for that reason? But I guess there are too many issues to have koha-devel threads for everything? Looking at https://wiki.koha-community.org/wiki/Roles_for_18.11 and https://wiki.koha-community.org/wiki/Roles_for_19.05, I wonder if we should have ?interest groups? or ?steering groups?, which could be responsible for providing feedback and guidance on patches for Koha? Looking at the ?Component? in Bugzilla, I know I?m interested in all things ?Architecture, internals, and plumbing?, ?Authentication?, ?Cataloging?, ?MARC*?, ?REST API?, ?Searching*?, ?Task Scheduler?, ?Web Services?, and ?Z39.50*?. I?d happily provide feedback on all those topics. Maybe members of ?interest groups? could be automatically added to the ?CC List? for those components in which they participate? And if we list the members of interest groups, contributors could approach those people directly for feedback/guidance? That might be easier than the process now of emailing koha-devel, saying something in #koha, or opening a Bugzilla issue and hoping that you somehow reach interested people? Honestly, there are many topics in Koha where I don?t really have an opinion. I just want those areas, like circulation, to work and I?m happy for everyone else to take care of them. I?m really interested in the areas I mention above. Mostly relating to data, system design/performance, and interoperability. Anyway, it?s just a thought. I?ll go comment on #17600 in any case ;). David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Jonathan Druart [mailto:jonathan.druart at bugs.koha-community.org] Sent: Thursday, 25 October 2018 10:49 AM To: David Cook Cc: Mark Tompsett ; Koha-devel Subject: Re: [Koha-devel] The order of "use" "At some point", yes... Bug 8244 - Script to find exporter problems Bug 17600 - Standardize the EXPORT On Wed, 24 Oct 2018 at 20:24 David Cook > wrote: Whether or not to prefix the function with "C4::Accounts::" is something we should probably talk about at some point. Historically, a lot of Koha modules use the "Exporter" module to export their functions into the main namespace of the caller. When "use C4::Accounts" runs, it automatically calls the "import" function in C4::Accounts, which in most/all cases is provided by the Exporter module. Blah blah blah. You can use the syntax "use C4::Accounts qw()" to prevent the importing of any functions or you can selectively import functions with "use C4::Accounts qw(function1 function2)". Fun times... If you don't automatically import functions into the main namespace of the caller, then you'd want to definitely prefix the function with C4::Accounts::, otherwise you'll get an error since that function would be declared in the main namespace (or worse it's the same function name and you wind up with more errors/unexpected behaviour). Personally, I rather use object oriented programming like we're trying in the Koha:: modules and/or have function libraries that don't use Exporter and instead require use of full namespace (e.g. C4::Accounts::function1). I think that's just a lot more transparent. More verbose but more explicit and easier to understand. Also fewer changes of function name collisions and less messy main namespace in the caller. That's my 2 cents. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org ] On Behalf Of Mark Tompsett Sent: Thursday, 25 October 2018 3:43 AM To: Koha-devel > Subject: [Koha-devel] The order of "use" Greetings, I was looking at bug 21641, and noticed the patch was explicitly stating C4::Accounts:: on the function in question. I vaguely recalled this sort of symptom shows itself in a knotted ?use? mess. C4::Circulation ?> C4::Members ?> C4::Accounts C4::Circulation ?> C4::Accounts C4::Circulation ?> C4::Overdues ?> C4::Accounts What is the best order to list these? C4::Accounts last? Is putting the C4::Accounts:: on the function in question still something we should do anyways? Feedback appreciated, Mark Tompsett _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Thu Oct 25 03:12:40 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Wed, 24 Oct 2018 22:12:40 -0300 Subject: [Koha-devel] The order of "use" In-Reply-To: <013d01d46bfb$08aa9f70$19ffde50$@prosentient.com.au> References: <013401d46bf0$b44e7230$1ceb5690$@prosentient.com.au> <013d01d46bfb$08aa9f70$19ffde50$@prosentient.com.au> Message-ID: "What's on in koha-devel", #8 and #9 :) On Wed, 24 Oct 2018 at 21:38 David Cook wrote: > I meant on koha-devel, but here we are now. > > > > Ahh I see > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17600#c82. It > is frustrating when we don?t get the feedback for which we?re hoping. > > > > I actually don?t monitor the Koha Bugs List listserv as the volume is just > too high(I?m 55,000 emails behind apparently) and I have too much other > work to do, so I never even knew about this bug. I?m sure I must not be > alone in not monitoring that listserv for that reason? But I guess there > are too many issues to have koha-devel threads for everything? > > > > Looking at https://wiki.koha-community.org/wiki/Roles_for_18.11 and > https://wiki.koha-community.org/wiki/Roles_for_19.05, I wonder if we > should have ?interest groups? or ?steering groups?, which could be > responsible for providing feedback and guidance on patches for Koha? > > > > Looking at the ?Component? in Bugzilla, I know I?m interested in all > things ?Architecture, internals, and plumbing?, ?Authentication?, > ?Cataloging?, ?MARC*?, ?REST API?, ?Searching*?, ?Task Scheduler?, ?Web > Services?, and ?Z39.50*?. I?d happily provide feedback on all those topics. > > > > Maybe members of ?interest groups? could be automatically added to the ?CC > List? for those components in which they participate? And if we list the > members of interest groups, contributors could approach those people > directly for feedback/guidance? That might be easier than the process now > of emailing koha-devel, saying something in #koha, or opening a Bugzilla > issue and hoping that you somehow reach interested people? > > > > Honestly, there are many topics in Koha where I don?t really have an > opinion. I just want those areas, like circulation, to work and I?m happy > for everyone else to take care of them. I?m really interested in the areas > I mention above. Mostly relating to data, system design/performance, and > interoperability. > > > > Anyway, it?s just a thought. I?ll go comment on #17600 in any case ;). > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > > Ultimo, NSW 2007 > > > Australia > > > > > Office: 02 9212 0899 <02%2092%2012%2008%2099> > > Direct: 02 8005 0595 <02%2080%2005%2005%2095> > > > > *From:* Jonathan Druart [mailto:jonathan.druart at bugs.koha-community.org] > *Sent:* Thursday, 25 October 2018 10:49 AM > *To:* David Cook > *Cc:* Mark Tompsett ; Koha-devel < > koha-devel at lists.koha-community.org> > *Subject:* Re: [Koha-devel] The order of "use" > > > > "At some point", yes... > > *Bug 8244* > - Script > to find exporter problems > > *Bug 17600* > - > Standardize the EXPORT > > > > On Wed, 24 Oct 2018 at 20:24 David Cook wrote: > > Whether or not to prefix the function with "C4::Accounts::" is something > we should probably talk about at some point. > > Historically, a lot of Koha modules use the "Exporter" module to export > their functions into the main namespace of the caller. When "use > C4::Accounts" runs, it automatically calls the "import" function in > C4::Accounts, which in most/all cases is provided by the Exporter module. > Blah blah blah. You can use the syntax "use C4::Accounts qw()" to prevent > the importing of any functions or you can selectively import functions with > "use C4::Accounts qw(function1 function2)". Fun times... > > If you don't automatically import functions into the main namespace of the > caller, then you'd want to definitely prefix the function with > C4::Accounts::, otherwise you'll get an error since that function would be > declared in the main namespace (or worse it's the same function name and > you wind up with more errors/unexpected behaviour). > > Personally, I rather use object oriented programming like we're trying in > the Koha:: modules and/or have function libraries that don't use Exporter > and instead require use of full namespace (e.g. C4::Accounts::function1). I > think that's just a lot more transparent. More verbose but more explicit > and easier to understand. Also fewer changes of function name collisions > and less messy main namespace in the caller. > > That's my 2 cents. > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > Office: > 02 > 9212 0899 <02%2092%2012%2008%2099> > Direct: 02 8005 0595 <02%2080%2005%2005%2095> > > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] On Behalf Of Mark Tompsett > Sent: Thursday, 25 October 2018 3:43 AM > To: Koha-devel > Subject: [Koha-devel] The order of "use" > > Greetings, > > I was looking at bug 21641, and noticed the patch was explicitly stating > C4::Accounts:: on the function in question. I vaguely recalled this sort > of symptom shows itself in a knotted ?use? mess. > > C4::Circulation ?> C4::Members ?> C4::Accounts C4::Circulation ?> > C4::Accounts C4::Circulation ?> C4::Overdues ?> C4::Accounts > > What is the best order to list these? C4::Accounts last? > Is putting the C4::Accounts:: on the function in question still something > we should do anyways? > > Feedback appreciated, > Mark Tompsett > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : > http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu Oct 25 03:20:19 2018 From: dcook at prosentient.com.au (David Cook) Date: Thu, 25 Oct 2018 12:20:19 +1100 Subject: [Koha-devel] The order of "use" In-Reply-To: References: <013401d46bf0$b44e7230$1ceb5690$@prosentient.com.au> <013d01d46bfb$08aa9f70$19ffde50$@prosentient.com.au> Message-ID: <015801d46c00$e4adeb30$ae09c190$@prosentient.com.au> Touch?! I?ll endeavour to read those more attentively! I never go to meetings as they don?t work for my timezone, but surely I could read these emails more carefully. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Jonathan Druart [mailto:jonathan.druart at bugs.koha-community.org] Sent: Thursday, 25 October 2018 12:13 PM To: David Cook Cc: Koha-devel Subject: Re: [Koha-devel] The order of "use" "What's on in koha-devel", #8 and #9 :) On Wed, 24 Oct 2018 at 21:38 David Cook > wrote: I meant on koha-devel, but here we are now. Ahh I see https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17600#c82. It is frustrating when we don?t get the feedback for which we?re hoping. I actually don?t monitor the Koha Bugs List listserv as the volume is just too high(I?m 55,000 emails behind apparently) and I have too much other work to do, so I never even knew about this bug. I?m sure I must not be alone in not monitoring that listserv for that reason? But I guess there are too many issues to have koha-devel threads for everything? Looking at https://wiki.koha-community.org/wiki/Roles_for_18.11 and https://wiki.koha-community.org/wiki/Roles_for_19.05, I wonder if we should have ?interest groups? or ?steering groups?, which could be responsible for providing feedback and guidance on patches for Koha? Looking at the ?Component? in Bugzilla, I know I?m interested in all things ?Architecture, internals, and plumbing?, ?Authentication?, ?Cataloging?, ?MARC*?, ?REST API?, ?Searching*?, ?Task Scheduler?, ?Web Services?, and ?Z39.50*?. I?d happily provide feedback on all those topics. Maybe members of ?interest groups? could be automatically added to the ?CC List? for those components in which they participate? And if we list the members of interest groups, contributors could approach those people directly for feedback/guidance? That might be easier than the process now of emailing koha-devel, saying something in #koha, or opening a Bugzilla issue and hoping that you somehow reach interested people? Honestly, there are many topics in Koha where I don?t really have an opinion. I just want those areas, like circulation, to work and I?m happy for everyone else to take care of them. I?m really interested in the areas I mention above. Mostly relating to data, system design/performance, and interoperability. Anyway, it?s just a thought. I?ll go comment on #17600 in any case ;). David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Jonathan Druart [mailto:jonathan.druart at bugs.koha-community.org ] Sent: Thursday, 25 October 2018 10:49 AM To: David Cook > Cc: Mark Tompsett >; Koha-devel > Subject: Re: [Koha-devel] The order of "use" "At some point", yes... Bug 8244 - Script to find exporter problems Bug 17600 - Standardize the EXPORT On Wed, 24 Oct 2018 at 20:24 David Cook > wrote: Whether or not to prefix the function with "C4::Accounts::" is something we should probably talk about at some point. Historically, a lot of Koha modules use the "Exporter" module to export their functions into the main namespace of the caller. When "use C4::Accounts" runs, it automatically calls the "import" function in C4::Accounts, which in most/all cases is provided by the Exporter module. Blah blah blah. You can use the syntax "use C4::Accounts qw()" to prevent the importing of any functions or you can selectively import functions with "use C4::Accounts qw(function1 function2)". Fun times... If you don't automatically import functions into the main namespace of the caller, then you'd want to definitely prefix the function with C4::Accounts::, otherwise you'll get an error since that function would be declared in the main namespace (or worse it's the same function name and you wind up with more errors/unexpected behaviour). Personally, I rather use object oriented programming like we're trying in the Koha:: modules and/or have function libraries that don't use Exporter and instead require use of full namespace (e.g. C4::Accounts::function1). I think that's just a lot more transparent. More verbose but more explicit and easier to understand. Also fewer changes of function name collisions and less messy main namespace in the caller. That's my 2 cents. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org ] On Behalf Of Mark Tompsett Sent: Thursday, 25 October 2018 3:43 AM To: Koha-devel > Subject: [Koha-devel] The order of "use" Greetings, I was looking at bug 21641, and noticed the patch was explicitly stating C4::Accounts:: on the function in question. I vaguely recalled this sort of symptom shows itself in a knotted ?use? mess. C4::Circulation ?> C4::Members ?> C4::Accounts C4::Circulation ?> C4::Accounts C4::Circulation ?> C4::Overdues ?> C4::Accounts What is the best order to list these? C4::Accounts last? Is putting the C4::Accounts:: on the function in question still something we should do anyways? Feedback appreciated, Mark Tompsett _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at sherohman.org Thu Oct 25 14:48:10 2018 From: dave at sherohman.org (Dave Sherohman) Date: Thu, 25 Oct 2018 07:48:10 -0500 Subject: [Koha-devel] Replacing koha-plack, koha-start-zebra, etc with systemd services? In-Reply-To: <066401d46a75$1f7d99f0$5e78cdd0$@prosentient.com.au> References: <066401d46a75$1f7d99f0$5e78cdd0$@prosentient.com.au> Message-ID: <20181025124810.GC32114@sherohman.org> On Tue, Oct 23, 2018 at 01:07:17PM +1100, David Cook wrote: > I'm about to start working on a systemd service for running Plack (for a > non-package Koha install), and I was wondering if anyone else has thought > about or is using systemd services for Plack, Zebra, etc. I'm currently faking it with init.d-scripts-under-systemd for zebra, sip, and ncip services, but I have created a couple real systemd config files for koha-under-plack. Converting sip/ncip/zebra from init.d scripts is on my to-do list, but, well... I'm no systemd expert (not even a systemd fan, but that's the way the wind is blowing) and don't really know what I'm doing with systemd service files, so they're very basic and could almost certainly be improved upon, but they do work. --- koha-opac.service --- [Unit] Description=Koha opac backend After=network.target [Service] Type=forking PIDFile=/var/run/koha/opac.pid User=www-data Group=www-data ExecStart=/etc/nginx/starman/opac-server.sh ExecReload=/bin/kill -HUP $MAINPID ExecStop=/bin/kill $MAINPID Restart=always [Install] WantedBy=multi-user.target --- koha-staff.service --- [Unit] Description=Koha staff backend After=network.target [Service] Type=forking PIDFile=/var/run/koha/staff.pid User=www-data Group=www-data ExecStart=/etc/nginx/starman/staff-server.sh ExecReload=/bin/kill -HUP $MAINPID ExecStop=/bin/kill $MAINPID Restart=always [Install] WantedBy=multi-user.target -- Dave Sherohman From jonathan.druart at bugs.koha-community.org Fri Oct 26 17:28:38 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Fri, 26 Oct 2018 12:28:38 -0300 Subject: [Koha-devel] SQL-modes wiki page Message-ID: Hi, I have opened a wiki page to try and explain the problems we are facing (and trying to fix) with the SQL modes. I let you read carefully this page and tell me if something is not clear enough:https://wiki.koha-community.org/wiki/SQL_modes Cheers, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.moravec at gmail.com Fri Oct 26 17:49:32 2018 From: josef.moravec at gmail.com (Josef Moravec) Date: Fri, 26 Oct 2018 17:49:32 +0200 Subject: [Koha-devel] SQL-modes wiki page In-Reply-To: References: Message-ID: +1 great job Jonathan On Fri, Oct 26, 2018 at 5:29 PM Jonathan Druart < jonathan.druart at bugs.koha-community.org> wrote: > Hi, > > I have opened a wiki page to try and explain the problems we are facing > (and trying to fix) with the SQL modes. > > I let you read carefully this page and tell me if something is not clear > enough:https://wiki.koha-community.org/wiki/SQL_modes > > Cheers, > Jonathan > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Josef Moravec josef.moravec at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Fri Oct 26 19:29:12 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Fri, 26 Oct 2018 14:29:12 -0300 Subject: [Koha-devel] Escape all the TT variables! (aka prevent XSS vulnerabilities) Message-ID: Hi devs, This needs an update. Bug 13618 has been pushed to master. Now you will have to escape all the variables template-side. See the wiki page to understand why and how - https://wiki.koha-community.org/wiki/Coding_Guidelines#HTML9:_filter_all_the_variables There is a test in the QA script (missing_filter) as well as a test in the codebase to catch missing filters (xt/find-missing-filters.t) To make things easier you can use the misc script (misc/devel/ add_missing_filters.pl) to automatically add the missing filters! Cheers, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer.83 at web.de Sat Oct 27 11:41:52 2018 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Sat, 27 Oct 2018 11:41:52 +0200 Subject: [Koha-devel] bulkmarcimport -d and -fk In-Reply-To: <41901D82-345A-4881-93CB-668B21A2CF31@pusc.it> References: <41901D82-345A-4881-93CB-668B21A2CF31@pusc.it> Message-ID: <52b3c201-750f-f63f-d05e-818d6f387958@web.de> Hi all, if you want to follow-up, the bug Stefano describes has been filed here: bulkmarcimport.pl -d option should use DELETE instead of TRUNCATE https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12488 Katrin On 18.10.18 15:56, Stefano Bargioni wrote: > Hi, all, > before adding a bug, I'd like to discuss this issue with others. > For testing, I installed Koha 18.06.00.032 and Elasticsearch on a Debian 8 virtual machine, using packages koha-common and koha-elasticsearch. > Mysql is "mysql Ver 14.14 Distrib 5.5.60, for debian-linux-gnu (x86_64) using readline 6.3". > > bulkmarcimport.pl -d fails with errors like > Cannot truncate a table referenced in a foreign key constraint > when going to truncate tables biblio, biblioitems, items. The -fk option is required. > > This is probably due to the more strict "way of life" of Mysql. > Do we need to force -fk when -d is specified? Or simply we have to update the -h documentation? > Thx. Stefano > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer.83 at web.de Sat Oct 27 12:52:09 2018 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Sat, 27 Oct 2018 12:52:09 +0200 Subject: [Koha-devel] Is finesMode = test still operational and sending emails? In-Reply-To: References: Message-ID: <12a9732e-00cb-5116-9094-77dba940c253@web.de> Hi all, there is also a bug report now: 21633 - Did finesMode = test ever send email? https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21633 Katrin On 17.10.18 15:48, Magnus Enger wrote: > Hi! > > The help of the cronjob fines.pl says: > > This script calculates and charges overdue fines to patron accounts. > The Koha system preference 'finesMode' controls whether the fines are > calculated and charged to the patron accounts ("Calculate and > charge"); calculated and emailed to the admin but not applied > ("Calculate (but only for mailing to the admin)"); or not calculated > ("Don't calculate"). > > I have a library set up with finesMode = test and as far as I can tell > everything is as it should be. But no emails are sent to > KohaAdminEmailAddress. Reading through fines.pl I can see it > generating a file, but not doing any emailing. Am I missing something > or did we loose the emailing somewhere along the way? > > Best regards, > Magnus > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer.83 at web.de Sat Oct 27 17:27:23 2018 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Sat, 27 Oct 2018 17:27:23 +0200 Subject: [Koha-devel] Kanopy and SIP2 hack In-Reply-To: <1539522043-sup-9905@x201s> References: <1539365380-sup-1998@x201s> <1539522043-sup-9905@x201s> Message-ID: <0816dc38-86fb-3ee6-0520-394f42c07a67@web.de> Hi Mark, just wondering, reading this again - Are you not using separate entries with different logins for the different services? Katrin On 14.10.18 15:12, Mark Alexander wrote: > Excerpts from Katrin Fischer's message of 2018-10-14 12:02:44 +0200: >> reading your use case made me think of some open bugs we have, the first >> being maybe a similar use case to yours: >> >> *Bug?16694* >> - >> Limit SIP2 auth by patron attribute > Thank you for that! It's very similar, except that our use case is more > complicated than I said. > > It turns out our library has to deal with two different services in > the SIP2 code. One service is Kanopy, as I mentioned; the other is a > consortium connected to Overdrive that provides ebooks and audio > books. Each service has to be handled slightly differently, perhaps > using a separate patron attribute for each. We need to find out which > service is performing the SIP2 request by examining the client IP > address. > > In the bug mentioned above, Marcel suggested putting the validation > code in Patron.pm. But our very site-specific complications led me to > think of putting the validation code into a plugin. > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ From marka at pobox.com Sat Oct 27 17:35:18 2018 From: marka at pobox.com (Mark Alexander) Date: Sat, 27 Oct 2018 11:35:18 -0400 Subject: [Koha-devel] Kanopy and SIP2 hack In-Reply-To: <0816dc38-86fb-3ee6-0520-394f42c07a67@web.de> References: <1539365380-sup-1998@x201s> <1539522043-sup-9905@x201s> <0816dc38-86fb-3ee6-0520-394f42c07a67@web.de> Message-ID: <1540654285-sup-6703@x201s> Excerpts from Katrin Fischer's message of 2018-10-27 17:27:23 +0200: > just wondering, reading this again - Are you not using separate entries > with different logins for the different services? That is the intent. I didn't think of this until just now, but it looks like I can use the different logins to distinguish between the services. Thanks for the hint! From katrin.fischer.83 at web.de Sat Oct 27 17:40:32 2018 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Sat, 27 Oct 2018 17:40:32 +0200 Subject: [Koha-devel] New Rest API RFCs In-Reply-To: References: Message-ID: <84e16c27-d198-684f-746a-da3d135935a4@web.de> Hi Josef, I've added some new comments on the wiki for Checkouts and Items. Hope it's helpful! Katrin On 23.10.18 12:07, Josef Moravec wrote: > Hello developers, > > Me and Michal Denar were thinking a bit about some REST api endpoints, > write down some rfcs and would like to see any comment on them ;) > > Thanks in advance > > https://wiki.koha-community.org/wiki/Checkouts_endpoint_RFC > https://wiki.koha-community.org/wiki/Availability_endpoints_RFC > > In this one we heavily used Katrin's comments and proposed new object > definition, thanks Katrin ;) > https://wiki.koha-community.org/wiki/Items_endpoint_RFC > > -- > Josef Moravec > josef.moravec at gmail.com > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer.83 at web.de Sat Oct 27 17:41:30 2018 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Sat, 27 Oct 2018 17:41:30 +0200 Subject: [Koha-devel] Kanopy and SIP2 hack In-Reply-To: <1540654285-sup-6703@x201s> References: <1539365380-sup-1998@x201s> <1539522043-sup-9905@x201s> <0816dc38-86fb-3ee6-0520-394f42c07a67@web.de> <1540654285-sup-6703@x201s> Message-ID: Glad it was helpful :) On 27.10.18 17:35, Mark Alexander wrote: > Excerpts from Katrin Fischer's message of 2018-10-27 17:27:23 +0200: >> just wondering, reading this again - Are you not using separate entries >> with different logins for the different services? > That is the intent. I didn't think of this until just now, but it > looks like I can use the different logins to distinguish between the > services. Thanks for the hint! From jonathan.druart at bugs.koha-community.org Tue Oct 30 03:41:56 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Mon, 29 Oct 2018 23:41:56 -0300 Subject: [Koha-devel] wrong url/uri filters Message-ID: Hi devs, Another quick update about the ongoing work on the variable filtering. Bug 21526 fixes the href attributes for links in a naive way (replacing html with uri), but there are a few wrong replacements that have been done (uri should have been url instead). I tried to fix them today with a follow-up on the bug, but it is not ready yet. If you find internal links that do not work it is certainly caused by this bug. Instead of opening a new bug report, please make sure the follow-up fixes the issue. Cheers, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian.maurice at biblibre.com Tue Oct 30 14:23:19 2018 From: julian.maurice at biblibre.com (Julian Maurice) Date: Tue, 30 Oct 2018 14:23:19 +0100 Subject: [Koha-devel] Bug 15395: Internationalization, plural forms, context and more Message-ID: <298bd36a-825d-47fd-466e-1d8c0548a78e@biblibre.com> Hi all, This bug has been signed off more than a year ago but it is still not Passed QA. It seems that not everyone agree on it. It should probably be discussed during an IRC meeting, but in the meantime, I wrote a wiki page [1] to better explain what it is supposed to do and created a thread on framavox [2] to gather opinions. If you have some time, I would really appreciate feedback on this feature. Thanks. [1] https://wiki.koha-community.org/wiki/Internationalization,_plural_forms,_context,_and_more_RFC [2] https://framavox.org/d/2juWqIMz/internationalization-plural-forms-context-and-more PS: framavox.org is a free software (Loomio) hosted by a French association (Framasoft) promoting free software. It only requires an e-mail address to create an account. -- Julian Maurice BibLibre From kohanews at gmail.com Wed Oct 31 23:35:23 2018 From: kohanews at gmail.com (kohanews) Date: Wed, 31 Oct 2018 15:35:23 -0700 Subject: [Koha-devel] Koha Community Newsletter: October 2018 Message-ID: <2d8cb11a-a7a1-7076-080f-82728a0844e6@gmail.com> The Koha Community Newsletter for October 2018 is here: https://koha-community.org/koha-community-newsletter-september-2018/ Many thanks to the folks ( and poultry ) who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. -- Chad Roseburg Editor, Koha Community Newsletter -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisc at catalyst.net.nz Wed Oct 31 23:40:49 2018 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Thu, 01 Nov 2018 11:40:49 +1300 Subject: [Koha-devel] [Koha] Koha Community Newsletter: October 2018 In-Reply-To: <2d8cb11a-a7a1-7076-080f-82728a0844e6@gmail.com> References: <2d8cb11a-a7a1-7076-080f-82728a0844e6@gmail.com> Message-ID: <0B3A62D7-E643-4869-9B3D-6ED37CF80C00@catalyst.net.nz> Oops, this link instead https://koha-community.org/koha-community-newsletter-october-2018/ Chris On 1 November 2018 11:35:23 AM NZDT, kohanews wrote: >The Koha Community Newsletter for October 2018 is here: >https://koha-community.org/koha-community-newsletter-september-2018/ > >Many thanks to the folks ( and poultry > ) 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 > >_______________________________________________ >Koha mailing list http://koha-community.org >Koha at lists.katipo.co.nz >https://lists.katipo.co.nz/mailman/listinfo/koha -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohanews at gmail.com Wed Oct 31 23:47:00 2018 From: kohanews at gmail.com (kohanews) Date: Wed, 31 Oct 2018 15:47:00 -0700 Subject: [Koha-devel] [Koha] Koha Community Newsletter: October 2018 In-Reply-To: <0B3A62D7-E643-4869-9B3D-6ED37CF80C00@catalyst.net.nz> References: <2d8cb11a-a7a1-7076-080f-82728a0844e6@gmail.com> <0B3A62D7-E643-4869-9B3D-6ED37CF80C00@catalyst.net.nz> Message-ID: Thanks, Chris! Was too hasty with the cut and paste! Chad On 10/31/18 3:40 PM, Chris Cormack wrote: > Oops, this link instead > > https://koha-community.org/koha-community-newsletter-october-2018/ > > Chris > > On 1 November 2018 11:35:23 AM NZDT, kohanews wrote: > > The Koha Community Newsletter for October 2018 is here: > https://koha-community.org/koha-community-newsletter-september-2018/ > > Many thanks to the folks ( and poultry > ) who submitted articles > and news to this month's newsletter. > > Please feel free to email me with any corrections or suggestions. > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Chad Roseburg Editor, Koha Community Newsletter -------------- next part -------------- An HTML attachment was scrubbed... URL: