From fridolin.somers at biblibre.com Fri Mar 1 09:52:03 2024 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Fri, 1 Mar 2024 09:52:03 +0100 Subject: [Koha-devel] Koha February release with security fixes Message-ID: <6e892b8e-f8db-414b-99a3-93745542d8c3@biblibre.com> Hello everyone 🤗 The Koha community is proud to announce the release of February version: 23.11.03 23.05.09 22.11.15 22.05.19 It is a bugfix/maintenance release including a lot of security fixes. It is highly recommended to upgrade. The full release notes are available here: https://koha-community.org/koha-23-11-03-released/ https://koha-community.org/koha-23-05-09-released/ https://koha-community.org/koha-22-11-15-released/ https://koha-community.org/koha-22-05-19-released/ Debian packages are available. Best regards 🤓 -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From nick at bywatersolutions.com Fri Mar 1 14:25:39 2024 From: nick at bywatersolutions.com (Nick Clemens) Date: Fri, 1 Mar 2024 08:25:39 -0500 Subject: [Koha-devel] Koha CSRF protection Message-ID: Hello all! We have pushed the CSRF work from 34478 and related bugs today. We know there are more follow-ups needed, and have filed a series of bugs under an omnibus: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 We have a framapad where issues can be reported/found: https://annuel.framapad.org/p/koha_34478_remaining And we have bugs for each of the sections of the document. We need all developers to submit patches when they encounter issues, and for other users testing master to report found issues on the pad. Testers can report issues on the pad as well. There is a new coding guideline - all POSTs to forms in Koha will need to include a csrf token: https://wiki.koha-community.org/wiki/Coding_Guidelines#Security This has been a big work, many thanks to all involved, and there is still work to be done, but this is an important fix that we must do. You can reach out to me on IRC (kidclamp) or via email and I will do my best to help anyone contribute. Thanks, Nick -- Nick Clemens ByWater Solutions bywatersolutions.com Phone: (888) 900-8944 Pronouns: (he/him/his) Timezone: Eastern Follow us: -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Fri Mar 1 14:59:29 2024 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 1 Mar 2024 10:59:29 -0300 Subject: [Koha-devel] Koha CSRF protection In-Reply-To: References: Message-ID: Congrats team! El vie, 1 mar 2024 a las 10:26, Nick Clemens via Koha-devel (< koha-devel at lists.koha-community.org>) escribió: > Hello all! > > We have pushed the CSRF work from 34478 and related bugs today. We know > there are more follow-ups needed, and have filed a series of bugs under an > omnibus: > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 > > We have a framapad where issues can be reported/found: > https://annuel.framapad.org/p/koha_34478_remaining > > And we have bugs for each of the sections of the document. We need all > developers to submit patches when they encounter issues, and for other > users testing master to report found issues on the pad. Testers can report > issues on the pad as well. > > There is a new coding guideline - all POSTs to forms in Koha will need to > include a csrf token: > https://wiki.koha-community.org/wiki/Coding_Guidelines#Security > > This has been a big work, many thanks to all involved, and there is still > work to be done, but this is an important fix that we must do. > > You can reach out to me on IRC (kidclamp) or via email and I will do my > best to help anyone contribute. > > Thanks, > Nick > > -- > Nick Clemens > ByWater Solutions > bywatersolutions.com > Phone: (888) 900-8944 > Pronouns: (he/him/his) > Timezone: Eastern > Follow us: > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer.83 at web.de Fri Mar 1 22:31:52 2024 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Fri, 1 Mar 2024 22:31:52 +0100 Subject: [Koha-devel] Z3950 authority server integrated with ElasticSearch In-Reply-To: References: Message-ID: <56cffd0f-b38e-46b1-921b-e94a958d1ab3@web.de> Hi Hammat, you probably already found this, but some information on the use and config of the z3950-responder can be found here: https://wiki.koha-community.org/wiki/Setting_up_the_Z39.50_and_SRU_Server The original bug introducing it was: *Bug 13937* - Add an Elasticsearch-compatible Z39.50/SRU daemon There are some open bugs and some closed ones (search for "ALL responder"), but I couldn't find information on searching authorities. Hope this helps, Katrin On 28.02.24 22:37, Hammat Wele via Koha-devel wrote: > Hello everyone, > > I'm currently facing an issue with a new Z3950 authority server > integrated with ElasticSearch that I'm trying to set up. My basic > searches are functioning properly, but when I attempt to use @attr > attributes, it doesn't seem to work. Interestingly, attribute 1=1 > (personal name) works fine. I've attempted to address this by adding > the attributes in the /etc/z3950/attribute_mappings.yaml file, but > unfortunately, that hasn't resolved the issue. > > This situation has led me to question whether it's possible, with > ElasticSearch for authorities, to perform a search on a specific > field, such as a title by adding @attr 1=4 on yaz-client command line. > In contrast, I haven't encountered this problem with an authority > server under ZEBRA. For example, when I use @attr 1=4, it works > seamlessly, but with ElasticSearch, it's not functioning as expected. > > Example > with a Z3950 authority server under Zebra > > $ yaz-client xxx.xxx.xxx.xxx:xxxx/authorities > Connecting...OK. > Sent initrequest. > Connection accepted by v3 target. > ID     : 81 > Name   : Zebra Information Server/GFS/YAZ > Version: 2.0.44/4.2.69 026ad3d737be4cbba4e98c6b6dc753f8029e3655 > Options: search present delSet triggerResourceCtrl scan sort > extendedServices namedResultSets > Elapsed: 0.446096 > Z> f canada > Sent searchRequest. > Received SearchResponse. > Search was a success. > Number of hits: 172856, setno 1 > SearchResult-1: term=canada cnt=172856 > records returned: 0 > Elapsed: 0.208821 > Z> f @attr 1=4 canada > Sent searchRequest. > Received SearchResponse. > Search was a success. > Number of hits: 1920, setno 2 > SearchResult-1: term=canada cnt=1920 > records returned: 0 > Elapsed: 0.858340 > Z> > > With a Z3950 authority server under ElasticSearch > $ yaz-client xxx.xxx.xxx.xxx:xxxx/authorities > Connecting...OK. > Sent initrequest. > Connection accepted by v3 target. > ID     : 81 > Name   : Koha/GFS/YAZ > Version: 21.05.11.000/5.27.1 872b6f92a024bb53bc1c11dfeccd47f065f98238 > Options: search present triggerResourceCtrl namedResultSets > Elapsed: 0.425683 > Z> f canada > Sent searchRequest. > Received SearchResponse. > Search was a success. > Number of hits: 56811, setno 1 > records returned: 0 > Elapsed: 0.478937 > Z> f @attr 1=4 canada > Sent searchRequest. > Received SearchResponse. > Search was a success. > Number of hits: 56811, setno 2 > records returned: 0 > Elapsed: 0.261396 > Z> > > Utilizing a Z3950 authority server with ElasticSearch, the yaz-client > connects successfully to Koha/GFS/YAZ (Version 21.05.11.000/5.27.1). > However, when attempting searches for 'canada' with the attribute > '@attr 1=4', the number of results (56811) remains the same, '@attr > 1=4' does not have effect. > > I aim to enable the functionality of attributes to be able to search > via these field >         nameany           => '@attr 1=1002 "#term" ', >         authorany         => '@attr 1=1003 "#term" ', >         authorcorp        => '@attr 1=2 "#term" ', >         authorpersonal    => '@attr 1=1 "#term" ', >         authormeetingcon  => '@attr 1=3 "#term" ', >         subject           => '@attr 1=21 "#term" ', >         subjectsubdiv     => '@attr 1=47 "#term" ', >         title             => '@attr 1=4 "#term" ', >         uniformtitle      => '@attr 1=6 "#term" ', >         srchany           => '@attr 1=1016 "#term" ', >         controlnumber     => '@attr 1=12 "#term" ', > > > Do you have any suggestion/check to fix this situation ? > > Cheers > Hammat Wele > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Mon Mar 4 08:37:36 2024 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 4 Mar 2024 07:37:36 +0000 Subject: [Koha-devel] Koha CSRF protection In-Reply-To: References: Message-ID: Great work! From: Koha-devel On Behalf Of Nick Clemens via Koha-devel Sent: Friday, March 1, 2024 2:26 PM To: Koha Devel ; Koha Subject: [Koha-devel] Koha CSRF protection Hello all! We have pushed the CSRF work from 34478 and related bugs today. We know there are more follow-ups needed, and have filed a series of bugs under an omnibus: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 We have a framapad where issues can be reported/found: https://annuel.framapad.org/p/koha_34478_remaining And we have bugs for each of the sections of the document. We need all developers to submit patches when they encounter issues, and for other users testing master to report found issues on the pad. Testers can report issues on the pad as well. There is a new coding guideline - all POSTs to forms in Koha will need to include a csrf token: https://wiki.koha-community.org/wiki/Coding_Guidelines#Security This has been a big work, many thanks to all involved, and there is still work to be done, but this is an important fix that we must do. You can reach out to me on IRC (kidclamp) or via email and I will do my best to help anyone contribute. Thanks, Nick -- Nick Clemens ByWater Solutions bywatersolutions.com Phone: (888) 900-8944 Pronouns: (he/him/his) Timezone: Eastern [https://docs.google.com/uc?export=download&id=1eLlHaKRZxg0CP6nlW7rG0J4qdtoIuoNr&revid=0B0ga69kSs543QWlEa3V4aGI4dFlXMlVQd0ZEbVY5dFBXQUk0PQ] Follow us: [https://docs.google.com/uc?export=download&id=1UU2Vj_xX_WgcBojhYbea9ck0TaLwoLky&revid=0B0ga69kSs543R2xUajk5MnF0VE9EcjhtSjZBc1R0YVpSL0NFPQ] [https://docs.google.com/uc?export=download&id=1SCTJQAzf1zB5c7NmTLQwtexAgNl4_jPC&revid=0B0ga69kSs543N0tKSG9ZRk55MXk2Qmt3TXJ2TE1Ca1g4T1hFPQ] [https://docs.google.com/uc?export=download&id=1zVkZyWeLDKyDM5RhOLMRHigl4VYN5j43&revid=0B0ga69kSs543eU9ZUVVyalFqNlVodEtZTmRSNElrQlV2MlhJPQ] [https://docs.google.com/uc?export=download&id=1b9EkTbJHwpA_Lf4iKYdoSyIlxwyasLPq&revid=0B0ga69kSs543WWFieW52VkRpZEhkdGRjcXVBejBTZUltS0hrPQ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Mon Mar 4 15:26:57 2024 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 4 Mar 2024 15:26:57 +0100 Subject: [Koha-devel] calendar change request on koha-community.org Message-ID: Hello all, I don't know who to ask, so asking widely, sorry. The hackfest announcement on https://koha-community.org/calendar/ is correct. However, it points to an old email, could it point to: https://lists.koha-community.org/pipermail/koha-devel/2024-February/048495.html Thanks -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Mon Mar 4 15:43:15 2024 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Mon, 4 Mar 2024 15:43:15 +0100 Subject: [Koha-devel] calendar change request on koha-community.org In-Reply-To: References: Message-ID: Hi Paul, I've adjusted the description of the event. Cheers, Jonathan Le lun. 4 mars 2024 à 15:26, Paul Poulain via Koha-devel a écrit : > > Hello all, > > I don't know who to ask, so asking widely, sorry. > The hackfest announcement on https://koha-community.org/calendar/ is correct. However, it points to an old email, could it point to: https://lists.koha-community.org/pipermail/koha-devel/2024-February/048495.html > > Thanks > > -- > Paul Poulain, Associé-gérant / co-owner > BibLibre, Services en logiciels libres pour les bibliothèques > BibLibre, Open Source software and services for libraries > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ From dcook at prosentient.com.au Mon Mar 4 23:15:42 2024 From: dcook at prosentient.com.au (David Cook) Date: Tue, 5 Mar 2024 09:15:42 +1100 Subject: [Koha-devel] PatternFly for design? Message-ID: <05bd01da6e81$8b111500$a1333f00$@prosentient.com.au> Hi all, Has anyone used PatternFly for designing? https://www.patternfly.org/ David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.wagner at desy.de Tue Mar 5 18:08:52 2024 From: alexander.wagner at desy.de (Wagner, Alexander) Date: Tue, 5 Mar 2024 18:08:52 +0100 (CET) Subject: [Koha-devel] Ponderings on locations Message-ID: <1531286618.21167163.1709658532458.JavaMail.zimbra@desy.de> Hi! While migrating our catalogue to Koha I get quite confused with the location handling. Location for me is "the place where I have to go to fetch the item". So an item could be in the general collection `main reading room`, but I may have a special area there like an exhibition or a new items shelf. And it can be at it's usual location or at some temporary place. AFAIS Koha items have internally a `location` and a `permanent_location`. (In my still current world they'd be named `temporary location` (876__l) and `location` (aka `852__a`), respectively, so slightly the other way round.) Now, in item cataloguing the location I get exposed to the editor seems to be a mixture of `permanent_location` and `location`, in the sense that the editor always sets both. Using mappings for `UpdateItemLocationOnCheckin` however, some values are magic. If `CART` and `PROC` get mapped they only change the `location`, while all others change both. (I do understand that the magic value is used by some cron-job.) However, I wonder if the procedures were not more flexible and easier to understand if "any mapped location" juggles the `location` and leaves the `permanent_location`, while I do get both values in the item editor and the actual place where an item is is defined as `permanet_location` if there is no `location` set. There is already `_PERM_` to access the permanent location in mappings, but with the current logic it's value is gone once a non-magical location enters the game. IMHO one could achieve the same functionality like now by just clearing `location` once an item is back at it's permanent location. (At least this is how our old system does it right now.) Example: - We order an item and set it's location to `On Order`. ORD is non-magical. - The item arrives, I check it in, `ORD: PROC` "moves" it to cataloguing. Cataloguing wants to change the permanent location. - After cataloguing it should go to the new items shelf. Check in, `PROC: NEW`. Everything fine in the OPAC display. - After a week or so on the new items shelf, check in, `NEW: _PERM_` moves it back to `on order`. To work around my trouble with the location, I played with a similar juggling for `UpdateNotForLoanStatusOnCheckin`. (Sidenote: it seems that I am required to use numbers for the values to juggle there, e.g. `-1: -3`, while the editor allows for text. If this is a bug I'd add one to bz.) This propagates as expected and from a display perspective it would also be ok. Unfortunately, the strict `not for loan` doesn't work well for us. We are open 24/7, but not staffed 24/7. IOW whatever hits the shelf can be taken. If someone checks out an item that is in principle not for loan, I'd really like to check it out, just to know who has it ;) I did not yet find a way to soften `not for loan` to something like `2 days and immediately send a recall letter`. (Current procedure.) Additionally, we check in _all items_ from the CART all the time as we have a lot of patrons that just drop them into the box and they need to be returned to get the RFID into the proper state. (So in our case the cron wouldn't help.) BTW: what proved pretty flexible in our current system are what I called back then "special patrons". If I check out an item to those the item is not actually checked out, but they manipulate some Marc fields. We used them a lot to set the temporary locations to values like `repair`, `cataloguing`, `on display` or `library desk` (for items ready for the patron to fetch; Koha does this differently). Unlike checking in, where I have to rely on automatic propagation, checking out allows to select what I want to do by means of the cardnumber I get as a second parameter on the SIP-terminal. For configuration I used something like 788 _7 |2 P:(DE-HGF) |a {"j": "available", "l": "Cataloguing"} |i 8767_ which would set `876 7_ |javailable |lCataloguing`, ie the item is available, but in cataloguing. (Our patrons are currently just authority records, so I have full Marc at my disposal.) -- Kind regards, Alexander Wagner Deutsches Elektronen-Synchrotron DESY Library and Documentation Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg phone: +49-40-8998-1758 e-mail: alexander.wagner at desy.de From michael.hafen at washk12.org Tue Mar 5 18:27:50 2024 From: michael.hafen at washk12.org (Michael Hafen) Date: Tue, 5 Mar 2024 10:27:50 -0700 Subject: [Koha-devel] Ponderings on locations In-Reply-To: <1531286618.21167163.1709658532458.JavaMail.zimbra@desy.de> References: <1531286618.21167163.1709658532458.JavaMail.zimbra@desy.de> Message-ID: Forgive me if I add to your confusion a bit instead of clearing it up. There are actually three locations in Koha: Permanent location, current location, and shelving location. The first two only matter if you have more than one site; if you only have one site you can set them to the same value and effectively ignore them. These are home branch and holding branch internally. It seems like most of what you are talking about here is the Shelving Location. I'll also mention that Koha can have pseudo patrons also, these can be one of many types. For example I have an Organizational type patron category called 'Library', and I may have a 'On Display', or 'Repair room' patron in that category. This doesn't help with automatically changing the Shelving Location though. There is also an 'after_circ_action' plugin hook. Perhaps there is, or you could have created, a Koha plugin to mangle the Shelving Location based on who an item is checked out to / returned from. On Tue, Mar 5, 2024 at 10:08 AM Wagner, Alexander via Koha-devel < koha-devel at lists.koha-community.org> wrote: > Hi! > > While migrating our catalogue to Koha I get quite confused with the > location handling. Location for me is "the place where I have to go to > fetch the item". So an item could be in the general collection `main > reading room`, but I may have a special area there like an exhibition or a > new items shelf. And it can be at it's usual location or at some temporary > place. > > AFAIS Koha items have internally a `location` and a `permanent_location`. > (In my still current world they'd be named `temporary location` (876__l) > and `location` (aka `852__a`), respectively, so slightly the other way > round.) > > Now, in item cataloguing the location I get exposed to the editor seems to > be a mixture of `permanent_location` and `location`, in the sense that the > editor always sets both. Using mappings for `UpdateItemLocationOnCheckin` > however, some values are magic. If `CART` and `PROC` get mapped they only > change the `location`, while all others change both. (I do understand that > the magic value is used by some cron-job.) > > However, I wonder if the procedures were not more flexible and easier to > understand if "any mapped location" juggles the `location` and leaves the > `permanent_location`, while I do get both values in the item editor and the > actual place where an item is is defined as `permanet_location` if there is > no `location` set. There is already `_PERM_` to access the permanent > location in mappings, but with the current logic it's value is gone once a > non-magical location enters the game. IMHO one could achieve the same > functionality like now by just clearing `location` once an item is back at > it's permanent location. (At least this is how our old system does it right > now.) > > Example: > > - We order an item and set it's location to `On Order`. ORD is non-magical. > - The item arrives, I check it in, `ORD: PROC` "moves" it to cataloguing. > Cataloguing wants to change the permanent location. > - After cataloguing it should go to the new items shelf. Check in, `PROC: > NEW`. > > Everything fine in the OPAC display. > > - After a week or so on the new items shelf, check in, `NEW: _PERM_` moves > it back to `on order`. > > To work around my trouble with the location, I played with a similar > juggling for `UpdateNotForLoanStatusOnCheckin`. (Sidenote: it seems that I > am required to use numbers for the values to juggle there, e.g. `-1: -3`, > while the editor allows for text. If this is a bug I'd add one to bz.) This > propagates as expected and from a display perspective it would also be ok. > > Unfortunately, the strict `not for loan` doesn't work well for us. We are > open 24/7, but not staffed 24/7. IOW whatever hits the shelf can be taken. > If someone checks out an item that is in principle not for loan, I'd really > like to check it out, just to know who has it ;) I did not yet find a way > to soften `not for loan` to something like `2 days and immediately send a > recall letter`. (Current procedure.) > > Additionally, we check in _all items_ from the CART all the time as we > have a lot of patrons that just drop them into the box and they need to be > returned to get the RFID into the proper state. (So in our case the cron > wouldn't help.) > > BTW: what proved pretty flexible in our current system are what I called > back then "special patrons". If I check out an item to those the item is > not actually checked out, but they manipulate some Marc fields. We used > them a lot to set the temporary locations to values like `repair`, > `cataloguing`, `on display` or `library desk` (for items ready for the > patron to fetch; Koha does this differently). Unlike checking in, where I > have to rely on automatic propagation, checking out allows to select what I > want to do by means of the cardnumber I get as a second parameter on the > SIP-terminal. For configuration I used something like > > 788 _7 |2 P:(DE-HGF) > |a {"j": "available", "l": "Cataloguing"} > |i 8767_ > > which would set `876 7_ |javailable |lCataloguing`, ie the item is > available, but in cataloguing. (Our patrons are currently just authority > records, so I have full Marc at my disposal.) > > -- > Kind regards, > > Alexander Wagner > > Deutsches Elektronen-Synchrotron DESY > Library and Documentation > > Building 01d Room OG1.444 > Notkestr. 85 > 22607 Hamburg > > phone: +49-40-8998-1758 > e-mail: alexander.wagner at desy.de > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -- Michael Hafen Washington County School District Technology Department Systems Analyst -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.wagner at desy.de Wed Mar 6 09:11:15 2024 From: alexander.wagner at desy.de (Wagner, Alexander) Date: Wed, 6 Mar 2024 09:11:15 +0100 (CET) Subject: [Koha-devel] Ponderings on locations In-Reply-To: References: <1531286618.21167163.1709658532458.JavaMail.zimbra@desy.de> Message-ID: <572377161.21472171.1709712675284.JavaMail.zimbra@desy.de> Hi! > Forgive me if I add to your confusion a bit instead of clearing it up. > There are actually three locations in Koha: Permanent location, current > location, and shelving location. The first two only matter if you have > more than one site; if you only have one site you can set them to the same > value and effectively ignore them. Indeed I did not dive into "more than one site". I do have that also, but I understood that this is modelled on the `branch` concept. > These are home branch and holding branch internally. > It seems like most of what you are talking about here is the Shelving > Location. Yes. My question is mainly: how do I tell, also to patrons in the OPAC but also me if I explain the OPAC to a new patron, where to go for an item. E.g. if it has been requested and is prepared for some patron another one will not find it in the shelves, so IMHO it is a good idea to show in OPAC that it is in a different location. (Currently, we add a temporary location like `Library Desk Hamburg` or `Library Desk Zeuthen` in this case.) > I'll also mention that Koha can have pseudo patrons also, these can be one > of many types. For example I have an Organizational type patron category > called 'Library', and I may have a 'On Display', or 'Repair room' patron in > that category. This doesn't help with automatically changing the Shelving > Location though. I saw those and noticed that I can check out items. I was pondering those for items we temporarily remove from the collection. In our situation this doesn't help too much for items on some shelve though. We are open 24/7, so everyone with an access card can enter the library and take whatever is in the open shelves and even if _we_ checkout items we use the SIP-machine... IOW, even if _we_ think, that e.g. new items should be on display for a week or so you could take them. That's why I'd prefer to check items out even if this is not intended. IOW anything making things in the reading room unable to be checked out at all doesn't really work well for us. > There is also an 'after_circ_action' plugin hook. Perhaps there is, or you > could have created, a Koha plugin to mangle the Shelving Location based on > who an item is checked out to / returned from. This sounds like an option to re-implement my special patrons. Thanks for the pointer. :) -- Kind regards, Alexander Wagner Deutsches Elektronen-Synchrotron DESY Library and Documentation Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg phone: +49-40-8998-1758 e-mail: alexander.wagner at desy.de From katrin.fischer at bsz-bw.de Wed Mar 6 09:52:38 2024 From: katrin.fischer at bsz-bw.de (Fischer, Katrin) Date: Wed, 6 Mar 2024 09:52:38 +0100 Subject: [Koha-devel] REMINDER: Development IRC meeting 6 March 2024 Message-ID: <00c501da6fa3$a46e85f0$ed4b91d0$@bsz-bw.de> Hi all, just a quick reminder that we have a Development IRC Meeting for today: https://wiki.koha-community.org/wiki/Development_IRC_meeting_6_March_2024 Time converter: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IR C+Meeting &iso=20240306T1300 Road map 24.05: . If you are a project lead, please prepare an update on your projects' status . You can also add the roadmap_24_05 now on Bugzilla to highlight any bugs/patches Hope to see you there! Katrin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7253 bytes Desc: not available URL: From michael.hafen at washk12.org Wed Mar 6 18:46:13 2024 From: michael.hafen at washk12.org (Michael Hafen) Date: Wed, 6 Mar 2024 10:46:13 -0700 Subject: [Koha-devel] Ponderings on locations In-Reply-To: <572377161.21472171.1709712675284.JavaMail.zimbra@desy.de> References: <1531286618.21167163.1709658532458.JavaMail.zimbra@desy.de> <572377161.21472171.1709712675284.JavaMail.zimbra@desy.de> Message-ID: On Wed, Mar 6, 2024 at 1:11 AM Wagner, Alexander wrote: > Hi! > > ... > > These are home branch and holding branch internally. > > It seems like most of what you are talking about here is the Shelving > > Location. > > Yes. My question is mainly: how do I tell, also to patrons in the OPAC but > also me if I explain the OPAC to a new patron, where to go for an item. > E.g. if it has been requested and is prepared for some patron another one > will not find it in the shelves, so IMHO it is a good idea to show in OPAC > that it is in a different location. (Currently, we add a temporary location > like `Library Desk Hamburg` or `Library Desk Zeuthen` in this case.) > > I was recently looking at Shelving location actually, and this was the thing the librarian who wanted it mentioned, how to show the shelving location on the OPAC. I found there are a couple relevant system preferences. OpacLocationOnDetail : controls if shelving location is shown in the same column as one of the branch fields, or in its own column, or is not shown. This also mentions the item_shelving_location column in the table settings administration page, in the OPAC group, in the "holdingst" table. (Make sure it is unchecked so it is not hidden.) OpacAdvancedSearchTypes and AdvancedSearchTypes : controls whether the shelving location is presented in a tab group on the search page with the item types. The other field that can be in that tab group is Collection. ... > -- > Kind regards, > > Alexander Wagner > > Deutsches Elektronen-Synchrotron DESY > Library and Documentation > > Building 01d Room OG1.444 > Notkestr. 85 > 22607 Hamburg > > phone: +49-40-8998-1758 > e-mail: alexander.wagner at desy.de > -- Michael Hafen Washington County School District Technology Department Systems Analyst -------------- next part -------------- An HTML attachment was scrubbed... URL: From Emily.Lamancusa at montgomerycountymd.gov Wed Mar 6 19:15:00 2024 From: Emily.Lamancusa at montgomerycountymd.gov (Lamancusa, Emily) Date: Wed, 6 Mar 2024 18:15:00 +0000 Subject: [Koha-devel] Ponderings on locations In-Reply-To: <572377161.21472171.1709712675284.JavaMail.zimbra@desy.de> References: <1531286618.21167163.1709658532458.JavaMail.zimbra@desy.de> <572377161.21472171.1709712675284.JavaMail.zimbra@desy.de> Message-ID: Hi Alexander, Welcome to the Koha community! ?? Many of the things you're trying to do can be done in Koha through some other mechanism. > E.g. if it has been requested and is prepared for some patron > another one will not find it in the shelves, so IMHO it is a good > idea to show in OPAC that it is in a different location. In Koha we would do this by placing a hold on the item for that patron, and then check the item in - then Koha will display it as "On hold" in the OPAC and "Waiting hold for such-and-such patron" on the Staff Intranet. > Unfortunately, the strict `not for loan` doesn't work well for us. We > are open 24/7, but not staffed 24/7. IOW whatever hits the shelf can > be taken. If someone checks out an item that is in principle not for > loan, I'd really like to check it out, just to know who has it ;) I did not > yet find a way to soften `not for loan` to something like `2 days and > immediately send a recall letter`. (Current procedure.) One way you could do this would be to define a NOTFORLOAN item type, and then edit the Circulation and Fines Rules to give that item type a loan period of 2 days with no renewals. If you want Koha to automatically send a recall letter for those that is different than the standard due/overdue notice, that would take a bit of doing when adjusting the notice template, but off the top of my head I believe it would be possible. That being said, it certainly would be nice to have more flexibility in defining temporary locations for items (such as displays or mending) - there is (at least one) bug for that in Bugzilla if you want to follow and/or comment: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 Our library system is currently in the process of working with ByWater to sponsor/co-sponsor a feature like that. Finally, I just want to clarify that Shelving Location does indeed consist of both a "location" and "permanent location" (separate from homebranch and holdingbranch), though that's not necessarily obvious depending on where you're looking, and you're right that the distinction mostly exists for the benefit of the "magic" values of CART and PROC. I point this out partly because it can be a stumbling block in custom SQL reports...I learned this the hard way when an enterprising librarian contacted me asking why the "items list per shelving location" reports for her branch were showing so few items. It turned out that everything that had recently been checked in, and thus had a "location" of CART, was being left off the reports - which was very noticeable because she was using the reports in the first place for some inventory work, and checking in large numbers of books in the process! Emily Lamancusa (she/her) IT Specialist III Montgomery County Public Libraries (240) 777-0052 ________________________________ From: Wagner, Alexander Sent: Wednesday, March 6, 2024 3:11 AM To: Michael Hafen Cc: Koha Devel Subject: Re: [Koha-devel] Ponderings on locations Hi! > Forgive me if I add to your confusion a bit instead of clearing it up. > There are actually three locations in Koha: Permanent location, current > location, and shelving location. The first two only matter if you have > more than one site; if you only have one site you can set them to the same > value and effectively ignore them. Indeed I did not dive into "more than one site". I do have that also, but I understood that this is modelled on the `branch` concept. > These are home branch and holding branch internally. > It seems like most of what you are talking about here is the Shelving > Location. Yes. My question is mainly: how do I tell, also to patrons in the OPAC but also me if I explain the OPAC to a new patron, where to go for an item. E.g. if it has been requested and is prepared for some patron another one will not find it in the shelves, so IMHO it is a good idea to show in OPAC that it is in a different location. (Currently, we add a temporary location like `Library Desk Hamburg` or `Library Desk Zeuthen` in this case.) > I'll also mention that Koha can have pseudo patrons also, these can be one > of many types. For example I have an Organizational type patron category > called 'Library', and I may have a 'On Display', or 'Repair room' patron in > that category. This doesn't help with automatically changing the Shelving > Location though. I saw those and noticed that I can check out items. I was pondering those for items we temporarily remove from the collection. In our situation this doesn't help too much for items on some shelve though. We are open 24/7, so everyone with an access card can enter the library and take whatever is in the open shelves and even if _we_ checkout items we use the SIP-machine... IOW, even if _we_ think, that e.g. new items should be on display for a week or so you could take them. That's why I'd prefer to check items out even if this is not intended. IOW anything making things in the reading room unable to be checked out at all doesn't really work well for us. > There is also an 'after_circ_action' plugin hook. Perhaps there is, or you > could have created, a Koha plugin to mangle the Shelving Location based on > who an item is checked out to / returned from. This sounds like an option to re-implement my special patrons. Thanks for the pointer. :) -- Kind regards, Alexander Wagner Deutsches Elektronen-Synchrotron DESY Library and Documentation Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg phone: +49-40-8998-1758 e-mail: alexander.wagner at desy.de [https://www.montgomerycountymd.gov/mcg/Resources/Images/Cybersecurity-footer.png] For more helpful Cybersecurity Resources, visit: https://www.montgomerycountymd.gov/cybersecurity -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at hofstetter.at Thu Mar 7 09:21:33 2024 From: mark at hofstetter.at (Mark Hofstetter) Date: Thu, 7 Mar 2024 09:21:33 +0100 Subject: [Koha-devel] koha SIP" over HTTPS Message-ID: Hi, we need (at least I think) SIP2 over https. I found some clues googling but no actual code for koha Is there something, does somebody do it, does it need implementing? thx for hints Mark -- -- Mag. Mark Hofstetter 2452 Mannersdorf Zwischen den Weingärten 3 +43 676 7345660 From M.de.Rooy at rijksmuseum.nl Thu Mar 7 09:36:10 2024 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 7 Mar 2024 08:36:10 +0000 Subject: [Koha-devel] koha SIP" over HTTPS In-Reply-To: References: Message-ID: Look for stunnel. This seems to be the usual way to secure SIP2 traffic. ________________________________ Van: Koha-devel namens Mark Hofstetter via Koha-devel Verzonden: donderdag 7 maart 2024 09:21 Aan: koha-devel at lists.koha-community.org Onderwerp: [Koha-devel] koha SIP" over HTTPS Hi, we need (at least I think) SIP2 over https. I found some clues googling but no actual code for koha Is there something, does somebody do it, does it need implementing? thx for hints Mark -- -- Mag. Mark Hofstetter 2452 Mannersdorf Zwischen den Weingärten 3 +43 676 7345660 _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.koha-community.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fkoha-devel&data=05%7C02%7Cm.de.rooy%40rijksmuseum.nl%7Ca8e089486cbd4fc318a008dc3e7f9f78%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638453965085503915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jmSISfnJbsVypUPxk6kDOStt%2B7VmmAdFBMqeUylx670%3D&reserved=0 website : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.koha-community.org%2F&data=05%7C02%7Cm.de.rooy%40rijksmuseum.nl%7Ca8e089486cbd4fc318a008dc3e7f9f78%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638453965085512421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nmEwtwJ50HazqrOpIA2TieLFiqkswStK%2Fc0NHoUFQ80%3D&reserved=0 git : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.koha-community.org%2F&data=05%7C02%7Cm.de.rooy%40rijksmuseum.nl%7Ca8e089486cbd4fc318a008dc3e7f9f78%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638453965085519494%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WapKIWa6JrLuVGeV3r17VMCgkzyIXiDq9HapKTzsRi8%3D&reserved=0 bugs : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.koha-community.org%2F&data=05%7C02%7Cm.de.rooy%40rijksmuseum.nl%7Ca8e089486cbd4fc318a008dc3e7f9f78%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638453965085525429%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Dl8GdvPp4BXK%2BSWzoJSb%2B5pEHhNhMn4NczZt44i4Jn4%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lari.taskula at hypernova.fi Thu Mar 7 09:50:27 2024 From: lari.taskula at hypernova.fi (Lari Taskula) Date: Thu, 07 Mar 2024 10:50:27 +0200 Subject: [Koha-devel] koha SIP" over HTTPS In-Reply-To: References: Message-ID: <25478F6E-13B4-4698-875A-127FC8E5EC80@hypernova.fi> Koha-Suomi, the company maintaining Koha installations for public libraries in Finland, has implemented this as a Koha plugin. See https://github.com/KohaSuomi/koha-plugin-SIPoHTTP -- Lari Taskula CEO, Hypernova Oy PL 16 80101 Joensuu, Finland On March 7, 2024 10:21:33 AM GMT+02:00, Mark Hofstetter via Koha-devel wrote: >Hi, > >we need (at least I think) SIP2 over https. I found some clues googling but no actual code for koha > >Is there something, does somebody do it, does it need implementing? > >thx for hints > >Mark > > >-- >-- >Mag. Mark Hofstetter >2452 Mannersdorf >Zwischen den Weingärten 3 >+43 676 7345660 > >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : https://www.koha-community.org/ >git : https://git.koha-community.org/ >bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at hofstetter.at Thu Mar 7 10:09:45 2024 From: mark at hofstetter.at (Mark Hofstetter) Date: Thu, 7 Mar 2024 10:09:45 +0100 Subject: [Koha-devel] koha SIP" over HTTPS In-Reply-To: References: Message-ID: <48d95e57-0626-493b-98e3-7735f2913851@hofstetter.at> Am 07.03.2024 um 09:36 schrieb Marcel de Rooy: > Look for stunnel. This seems to be the usual way to secure SIP2 traffic. thx, yes I am a aware of stunnel, but it adds a different protocol/port which makes it hard(er) to deploy behind corporate firewalls and https loadbalancers so back to the original question does anybody use sip2 over https - or is it just a stupid idea? cheers Mark > > ------------------------------------------------------------------------ > *Van:* Koha-devel namens > Mark Hofstetter via Koha-devel > *Verzonden:* donderdag 7 maart 2024 09:21 > *Aan:* koha-devel at lists.koha-community.org > > *Onderwerp:* [Koha-devel] koha SIP" over HTTPS > Hi, > > we need (at least I think) SIP2 over https. I found some clues googling > but no actual code for koha > > Is there something, does somebody do it, does it need implementing? > > thx for hints > > Mark > > > -- > -- > Mag. Mark Hofstetter > 2452 Mannersdorf > Zwischen den Weingärten 3 > +43 676 7345660 > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.koha-community.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fkoha-devel&data=05%7C02%7Cm.de.rooy%40rijksmuseum.nl%7Ca8e089486cbd4fc318a008dc3e7f9f78%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638453965085503915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jmSISfnJbsVypUPxk6kDOStt%2B7VmmAdFBMqeUylx670%3D&reserved=0 > > website : > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.koha-community.org%2F&data=05%7C02%7Cm.de.rooy%40rijksmuseum.nl%7Ca8e089486cbd4fc318a008dc3e7f9f78%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638453965085512421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nmEwtwJ50HazqrOpIA2TieLFiqkswStK%2Fc0NHoUFQ80%3D&reserved=0 > > git : > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.koha-community.org%2F&data=05%7C02%7Cm.de.rooy%40rijksmuseum.nl%7Ca8e089486cbd4fc318a008dc3e7f9f78%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638453965085519494%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WapKIWa6JrLuVGeV3r17VMCgkzyIXiDq9HapKTzsRi8%3D&reserved=0 > > bugs : > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.koha-community.org%2F&data=05%7C02%7Cm.de.rooy%40rijksmuseum.nl%7Ca8e089486cbd4fc318a008dc3e7f9f78%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C638453965085525429%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Dl8GdvPp4BXK%2BSWzoJSb%2B5pEHhNhMn4NczZt44i4Jn4%3D&reserved=0 > -- -- Mag. Mark Hofstetter 2452 Mannersdorf Zwischen den Weingärten 3 +43 676 7345660 From alexander.wagner at desy.de Thu Mar 7 14:06:26 2024 From: alexander.wagner at desy.de (Wagner, Alexander) Date: Thu, 7 Mar 2024 14:06:26 +0100 (CET) Subject: [Koha-devel] Ponderings on locations In-Reply-To: References: <1531286618.21167163.1709658532458.JavaMail.zimbra@desy.de> <572377161.21472171.1709712675284.JavaMail.zimbra@desy.de> Message-ID: <120967902.278153.1709816786118.JavaMail.zimbra@desy.de> Hello Emily! > Many of the things you're trying to do can be done in Koha through some other > mechanism. :) >> E.g. if it has been requested and is prepared for some patron >> another one will not find it in the shelves, so IMHO it is a good >> idea to show in OPAC that it is in a different location. > > In Koha we would do this by placing a hold on the item for that patron, and then > check the item in and confirm the hold, right? IOW the _status_ `on hold` describes that the item _is already_ on the shelf of items prepared for our patrons. (What we called `Library Desk HH`). > then Koha will display it as "On hold" in the OPAC and > "Waiting hold for such-and-such patron" on the Staff Intranet. So in Koha Current library: DESY Hamburg Library Location: Main Status: On hold is the same thing as Library: DESY Hamburg Library Location: Library Desk HH I'll just correct my thinking here and adopt Kohas view. :) >> Unfortunately, the strict `not for loan` doesn't work well for us. We [...] >> immediately send a recall letter`. (Current procedure.) > > One way you could do this would be to define a NOTFORLOAN item type, and then > edit the Circulation and Fines Rules to give that item type a loan period of 2 > days with no renewals. This is what I actually did already together with changing all `not for loan` loan periods we have right now. I just mentioned the not for loan feature as it entered this "where is the book right now" game somewhat unexpectedly (for me). What got me confused quite a bit was that there is - `UpdateItemLocationOnCheckin`: Ok, this is plausible. If I check in an item it is in some other place. Especially, if I explicitly treat CART as a location, which is sensible. (That we didn't till now is more a failure in our current system, that I will not fix any more.) - `UpdateNotForLoanStatusOnCheckin`: This however, I found completely unrelated, cause the loan period is independent from the items location. So I played with both of them and noticed that they both also trigger displays in OPAC. Both basically use the same kind of translation tables (if status is x change it to y once an item is checked in) while I noticed that only the `UpdateNotForLoanStatusOnCheckin` managed all stages as described in the translation tables while `UpdateItemLocationOnCheckin` behaved "stange" at first sight as I got this incorrect permanent location set. I think, I now got why the `not for loan`-status entered the game, though it is still a bit strange to me and as mentioned it does not work as a work around for exhibtions, new itmes etc. (But loan periods and not for loan handling in Koha is completely different to our current system anyway, so I'll just have to adopt to Kohas view.) > If you want Koha to automatically send a recall letter > for those that is different than the standard due/overdue notice, that would > take a bit of doing when adjusting the notice template, but off the top of my > head I believe it would be possible. I think if I have a short loan period they'd trigger the first recall, so this should be fine. But I'll double check. (I'll have to dive a bit more into the recall procedures, as I fear not all of our patrons return their items after the 3rd notice, but that's another issue.) > That being said, it certainly would be nice to have more flexibility in defining > temporary locations for items (such as displays or mending) - there is (at > least one) bug for that in Bugzilla if you want to follow and/or comment: > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 Somehow I knew that my thinking isn't too strange. Thanks for the poiner! I think 14962 is indeed pretty spot on. One thing I do not understand is, why CART and PROC have to be special in the first place. If the mapping table just works on `location` and leaves `permanent_location` alone (like it does for PROC and CART) I think things work as expected once in some final steps I map `: _PERM_`. IOW I do not understand why checkin touches a permanent location that was set during cataloguing as some conscious decision: we shelve this item in the special reading room etc. > Our library system is currently in the process of working with ByWater to > sponsor/co-sponsor a feature like that. As mentioned, unless I overlook something deep in some other areas not too much feature may be required, but more removal of magic. 14962 describes yet another location, but I think this is not required as `items.location` is basically the described temp-location. But I am to new to Koha to understand all implications. > Finally, I just want to clarify that Shelving Location does indeed consist of > both a "location" and "permanent location" (separate from homebranch and > holdingbranch), though that's not necessarily obvious depending on where you're > looking, and you're right that the distinction mostly exists for the benefit of > the "magic" values of CART and PROC. So, if all automagic juggling works on `items.location` and the rules somehow know when to clear `items.location`... > I point this out partly because it can be > a stumbling block in custom SQL reports...I learned this the hard way when an [...] > in large numbers of books in the process! I see your point. Noted down. Indeed, I stumbled there as well once I inspected the items-table. -- Kind regards, Alexander Wagner Deutsches Elektronen-Synchrotron DESY Library and Documentation Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg phone: +49-40-8998-1758 e-mail: alexander.wagner at desy.de From alexander.wagner at desy.de Thu Mar 7 14:10:08 2024 From: alexander.wagner at desy.de (Wagner, Alexander) Date: Thu, 7 Mar 2024 14:10:08 +0100 (CET) Subject: [Koha-devel] Ponderings on locations In-Reply-To: References: <1531286618.21167163.1709658532458.JavaMail.zimbra@desy.de> <572377161.21472171.1709712675284.JavaMail.zimbra@desy.de> Message-ID: <1158430405.280197.1709817008782.JavaMail.zimbra@desy.de> Hello! > I was recently looking at Shelving location actually, and this was the > thing the librarian who wanted it mentioned, how to show the shelving > location on the OPAC. I found there are a couple relevant system > preferences. > > OpacLocationOnDetail : controls if shelving location is shown in the same > column as one of the branch fields, or in its own column, or is not shown. I'll check out our settings there. I didn't know this one yet. Thanks! > OpacAdvancedSearchTypes and AdvancedSearchTypes : controls whether the > shelving location is presented in a tab group on the search page with the > item types. The other field that can be in that tab group is Collection. Those are indeed set up already. -- Kind regards, Alexander Wagner Deutsches Elektronen-Synchrotron DESY Library and Documentation Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg phone: +49-40-8998-1758 e-mail: alexander.wagner at desy.de From magnus at libriotech.no Thu Mar 7 15:33:01 2024 From: magnus at libriotech.no (Magnus Enger) Date: Thu, 7 Mar 2024 15:33:01 +0100 Subject: [Koha-devel] Choose your preferred dates for a Gloabl Bug Squashing Day in March Message-ID: <6327d301-66b1-4c88-af08-e6ff1639a1e5@libriotech.no> Kia ora! Trying to get another Gloabl Bug Squashing Day (GBSD) going. Which dates would you prefer? https://terminplaner6.dfn.de/en/p/4939a0075ab483d3d337f955859f824f-633050 Please reply by Wednesday 2024-03-13. What's a GBSD, you say? It's fun, that's what it is! See this old page for an example and some more information: https://wiki.koha-community.org/wiki/2020-02-14_Global_bug_squashing_day TL; DR: Get your name as high up the "Signoffs" list on https://dashboard.koha-community.org/ as you can in a given day. (Or the other lists, if you prefer.) Best regards, Magnus Libriotech/imCode -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Fri Mar 8 03:02:38 2024 From: dcook at prosentient.com.au (David Cook) Date: Fri, 8 Mar 2024 13:02:38 +1100 Subject: [Koha-devel] Random XSLT knowledge Message-ID: <089801da70fc$b7f00180$27d00480$@prosentient.com.au> Hi all, I've been working on performance issues, and in the process I got looking at XSLTs. I just wanted to share that it's possible to pass strings to the XSLT's transform() method: - return $engine->transform($xmlrecord, $xslfilename ); #file or URL + return $engine->transform({ + xml => $xmlrecord, + file => $xslfilename, + parameters => { + test => "'$test_str'", + }, + }); #file or URL It's somewhat limited in that you can only pass strings and I think there's a small limit on the number of parameters you can pass (not sure if it's 32 or 255), but I thought it was interesting. It would allow you to pass some data that you have at hand on a per-XML record basis without having to mangle the XML record (like we do with items and system preferences). In the end, I didn't end up using it though. Instead, I use XML::LibXSLT->register_function() to provide access to Koha functions from the XSLT, and in this case that meets my needs. Anyway, back to it.. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Fri Mar 8 07:00:34 2024 From: dcook at prosentient.com.au (David Cook) Date: Fri, 8 Mar 2024 17:00:34 +1100 Subject: [Koha-devel] SMTP servers requiring XOAUTH2 Message-ID: <08dd01da711d$efdd29d0$cf977d70$@prosentient.com.au> Hey folks, Is anyone using Koha with SMTP servers requiring XOAUTH2? It doesn't look like the Perl libraries used by Koha are anywhere near ready for it, but it looks like Postfix has an experimental plugin available: https://github.com/tarickb/sasl-xoauth2 or https://packages.debian.org/experimental/sasl-xoauth2 I think both Gmail and Microsoft require it these days. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Fri Mar 8 08:13:12 2024 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Fri, 8 Mar 2024 07:13:12 +0000 Subject: [Koha-devel] Random XSLT knowledge In-Reply-To: <089801da70fc$b7f00180$27d00480$@prosentient.com.au> References: <089801da70fc$b7f00180$27d00480$@prosentient.com.au> Message-ID: Hi David, Thanks for sharing. Would you have an example of how you use register_function with Koha functions to share? Marcel ________________________________ Van: Koha-devel namens David Cook via Koha-devel Verzonden: vrijdag 8 maart 2024 03:02 Aan: 'Koha Devel' Onderwerp: [Koha-devel] Random XSLT knowledge Hi all, I’ve been working on performance issues, and in the process I got looking at XSLTs. I just wanted to share that it’s possible to pass strings to the XSLT’s transform() method: - return $engine->transform($xmlrecord, $xslfilename ); #file or URL + return $engine->transform({ + xml => $xmlrecord, + file => $xslfilename, + parameters => { + test => "'$test_str'", + }, + }); #file or URL It’s somewhat limited in that you can only pass strings and I think there’s a small limit on the number of parameters you can pass (not sure if it’s 32 or 255), but I thought it was interesting. It would allow you to pass some data that you have at hand on a per-XML record basis without having to mangle the XML record (like we do with items and system preferences). In the end, I didn’t end up using it though. Instead, I use XML::LibXSLT->register_function() to provide access to Koha functions from the XSLT, and in this case that meets my needs. Anyway, back to it.. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Mar 11 00:27:11 2024 From: dcook at prosentient.com.au (David Cook) Date: Mon, 11 Mar 2024 10:27:11 +1100 Subject: [Koha-devel] Random XSLT knowledge In-Reply-To: References: <089801da70fc$b7f00180$27d00480$@prosentient.com.au> Message-ID: <09e301da7342$8102efa0$8308cee0$@prosentient.com.au> Hi Marcel, Sure! Before Koha started using "http://exslt.org/strings" to encode URIs, I used to use register_function to add my own function to do that. 1. vi C4/XSLT.pm 2. Add a line near the top like: a. XML::LibXSLT->register_function("http://wwww.prosentient.com.au/xsltperl", "uri-escape",\&Koha::Prosentient::Biblio::Urls::xslt_uri_escape); 3. Write a function like this: sub xslt_uri_escape { my ($uri) = @_; #$uri should always be a XML::LibXML::Nodelist, even if that Nodelist just contains 1 URI if (ref $uri eq "XML::LibXML::NodeList"){ $uri->foreach( sub { my ( $node ) = @_; #If the node has child (text) nodes if ($node->hasChildNodes()){ my @childNodes = $node->childNodes(); if (@childNodes){ foreach my $childNode (@childNodes){ if (my $textdata = $childNode->data){ #Trim whitespace $textdata =~ s/^\s+|\s+$//g; my $encoded_url = URI::Encode::uri_encode($textdata, { encode_reserved => 0 }); if ($encoded_url){ #Replace the existing URI data with the encoded URI data $childNode->setData($encoded_url); } } } } } } ); } return $uri; } 4. Add the namespace at the top of your XSLT: a. xmlns:pro="http://wwww.prosentient.com.au/xsltperl" 5. Call the function on some XML: a. -- More recently, I've done more complicated things like looking up item urls for that biblio record, deduplicating them against the 856$u, and adding them to the online access in the search results. I continue to take into account OpacHiddenItems and its associated preferences. Since it's operating at the Perl level, I'm able to check the C4::Context->userenv for the patron details as well. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Marcel de Rooy Sent: Friday, 8 March 2024 6:13 PM To: 'Koha Devel' ; David Cook Subject: Re: [Koha-devel] Random XSLT knowledge Hi David, Thanks for sharing. Would you have an example of how you use register_function with Koha functions to share? Marcel _____ Van: Koha-devel > namens David Cook via Koha-devel > Verzonden: vrijdag 8 maart 2024 03:02 Aan: 'Koha Devel' > Onderwerp: [Koha-devel] Random XSLT knowledge Hi all, I've been working on performance issues, and in the process I got looking at XSLTs. I just wanted to share that it's possible to pass strings to the XSLT's transform() method: - return $engine->transform($xmlrecord, $xslfilename ); #file or URL + return $engine->transform({ + xml => $xmlrecord, + file => $xslfilename, + parameters => { + test => "'$test_str'", + }, + }); #file or URL It's somewhat limited in that you can only pass strings and I think there's a small limit on the number of parameters you can pass (not sure if it's 32 or 255), but I thought it was interesting. It would allow you to pass some data that you have at hand on a per-XML record basis without having to mangle the XML record (like we do with items and system preferences). In the end, I didn't end up using it though. Instead, I use XML::LibXSLT->register_function() to provide access to Koha functions from the XSLT, and in this case that meets my needs. Anyway, back to it.. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Mon Mar 11 08:36:39 2024 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 11 Mar 2024 07:36:39 +0000 Subject: [Koha-devel] Random XSLT knowledge In-Reply-To: <09e301da7342$8102efa0$8308cee0$@prosentient.com.au> References: <089801da70fc$b7f00180$27d00480$@prosentient.com.au> <09e301da7342$8102efa0$8308cee0$@prosentient.com.au> Message-ID: Cool. Nice example. Thanks. From: David Cook Sent: Monday, March 11, 2024 12:27 AM To: Marcel de Rooy ; 'Koha Devel' Subject: RE: [Koha-devel] Random XSLT knowledge Hi Marcel, Sure! Before Koha started using “http://exslt.org/strings” to encode URIs, I used to use register_function to add my own function to do that. 1. vi C4/XSLT.pm 2. Add a line near the top like: * XML::LibXSLT->register_function("http://wwww.prosentient.com.au/xsltperl", "uri-escape",\&Koha::Prosentient::Biblio::Urls::xslt_uri_escape); 3. Write a function like this: sub xslt_uri_escape { my ($uri) = @_; #$uri should always be a XML::LibXML::Nodelist, even if that Nodelist just contains 1 URI if (ref $uri eq "XML::LibXML::NodeList"){ $uri->foreach( sub { my ( $node ) = @_; #If the node has child (text) nodes if ($node->hasChildNodes()){ my @childNodes = $node->childNodes(); if (@childNodes){ foreach my $childNode (@childNodes){ if (my $textdata = $childNode->data){ #Trim whitespace $textdata =~ s/^\s+|\s+$//g; my $encoded_url = URI::Encode::uri_encode($textdata, { encode_reserved => 0 }); if ($encoded_url){ #Replace the existing URI data with the encoded URI data $childNode->setData($encoded_url); } } } } } } ); } return $uri; } 1. Add the namespace at the top of your XSLT: * xmlns:pro="http://wwww.prosentient.com.au/xsltperl" 2. Call the function on some XML: * -- More recently, I’ve done more complicated things like looking up item urls for that biblio record, deduplicating them against the 856$u, and adding them to the online access in the search results. I continue to take into account OpacHiddenItems and its associated preferences. Since it’s operating at the Perl level, I’m able to check the C4::Context->userenv for the patron details as well. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Marcel de Rooy > Sent: Friday, 8 March 2024 6:13 PM To: 'Koha Devel' >; David Cook > Subject: Re: [Koha-devel] Random XSLT knowledge Hi David, Thanks for sharing. Would you have an example of how you use register_function with Koha functions to share? Marcel ________________________________ Van: Koha-devel > namens David Cook via Koha-devel > Verzonden: vrijdag 8 maart 2024 03:02 Aan: 'Koha Devel' > Onderwerp: [Koha-devel] Random XSLT knowledge Hi all, I’ve been working on performance issues, and in the process I got looking at XSLTs. I just wanted to share that it’s possible to pass strings to the XSLT’s transform() method: - return $engine->transform($xmlrecord, $xslfilename ); #file or URL + return $engine->transform({ + xml => $xmlrecord, + file => $xslfilename, + parameters => { + test => "'$test_str'", + }, + }); #file or URL It’s somewhat limited in that you can only pass strings and I think there’s a small limit on the number of parameters you can pass (not sure if it’s 32 or 255), but I thought it was interesting. It would allow you to pass some data that you have at hand on a per-XML record basis without having to mangle the XML record (like we do with items and system preferences). In the end, I didn’t end up using it though. Instead, I use XML::LibXSLT->register_function() to provide access to Koha functions from the XSLT, and in this case that meets my needs. Anyway, back to it.. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohanews at gmail.com Wed Mar 13 10:18:42 2024 From: kohanews at gmail.com (Koha Newsletter) Date: Wed, 13 Mar 2024 10:18:42 +0100 Subject: [Koha-devel] Call for news - Newsletter March 2024 Message-ID: Hi I'm collecting news for the March 2024 Koha Community Newsletter. Please send anything noteworthy to: kohanews (at) gmail (dot) com News criteria: * News items can be of any length. * Images are fine. * Anything and everything Koha. * Submit by the 26th of the month. Text format criteria: * Just structured plain text, or * HTML text to include tables or similar For events: * Consider adding your event to the Koha Community calendar at https://koha-community.org/calendar/ Thank you! Michael Kuhn Editor, Koha Community Newsletter -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at libriotech.no Fri Mar 15 15:50:17 2024 From: magnus at libriotech.no (Magnus Enger) Date: Fri, 15 Mar 2024 15:50:17 +0100 Subject: [Koha-devel] Reserve the date! There will be a GBSD on 2024-03-22! Message-ID: <2a1ff5e8-86cb-4b97-a7f9-4cf25fd5d722@libriotech.no> Kia ora! The poll has spoken, and there will be a GBSD on 2024-03-22, in the timezone of your choice. More information: https://wiki.koha-community.org/wiki/2024-03-22_Global_bug_squashing_day Mark the date in your calendar and come join the fun! How far can we get the numbers on https://dashboard.koha-community.org/ to change, and how far up the lists can you get your own name? Best regards, Magnus Libriotech/imCode From katrin.fischer.83 at web.de Sun Mar 17 10:33:59 2024 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Sun, 17 Mar 2024 10:33:59 +0100 Subject: [Koha-devel] Ponderings on locations In-Reply-To: <1158430405.280197.1709817008782.JavaMail.zimbra@desy.de> References: <1531286618.21167163.1709658532458.JavaMail.zimbra@desy.de> <572377161.21472171.1709712675284.JavaMail.zimbra@desy.de> <1158430405.280197.1709817008782.JavaMail.zimbra@desy.de> Message-ID: <8d2b9423-92f5-48d6-9b63-1b2fe2d9d748@web.de> Hi Alexander, maybe something else that could work for some of your use cases is the course reserves module. It allows you to temporarily change item values while they are in a an active course reserve and automatically changes them back when they aren't. I believe it could be useful for exhibitions or the new items shelf maybe. It also gives a nice indication in the OPAC that an item is currently in a course reserve. Some renaming of things could be achieved with jQuery/OpacUserJs. Hope this helps, Katrin On 07.03.24 14:10, Wagner, Alexander via Koha-devel wrote: > Hello! > >> I was recently looking at Shelving location actually, and this was the >> thing the librarian who wanted it mentioned, how to show the shelving >> location on the OPAC. I found there are a couple relevant system >> preferences. >> >> OpacLocationOnDetail : controls if shelving location is shown in the same >> column as one of the branch fields, or in its own column, or is not shown. > I'll check out our settings there. I didn't know this one yet. Thanks! > >> OpacAdvancedSearchTypes and AdvancedSearchTypes : controls whether the >> shelving location is presented in a tab group on the search page with the >> item types. The other field that can be in that tab group is Collection. > Those are indeed set up already. > From Anke.Bruns at gwdg.de Mon Mar 18 17:37:33 2024 From: Anke.Bruns at gwdg.de (Bruns, Anke) Date: Mon, 18 Mar 2024 16:37:33 +0000 Subject: [Koha-devel] [Koha] Thesis report Message-ID: <93b27f21-d113-43c6-95f2-92736835c9ad@email.android.com> Hi, the SQL for the report depends on where, i.e. in which MARC fields, the information is stored in your Koha. You'll find lots of examples for SQL reports in the SQL Report Library and can choose one that fits well and then adjust the SQL to your needs. The link to the Reports Library can be found in your reports menu (I'm not currently at my desk so cannot quickly look it up for you). If you're not familiar with SQL you'll perhaps need someone with more experience, and it might take a bit of trial and error before you get the desired results. Of course you can ask more specific questions in the list, those are usually easier to answer than very general ones. Best regards, Anke Am 17.03.2024 08:01 schrieb Ruqaiya Said Alfarsi : Dear All, Could someone find to me a specific report for thesis list by following points: (1) For master’s theses related to the University of Nizwa before 2024 (2) Another file for the year 2024 (3) A PDF file is available for master’s theses (4) A file that does not have a pdf file I will be thankful for your help. Best regards -- -- _______________________________________________ Koha mailing list http://koha-community.org Koha at lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer at bsz-bw.de Tue Mar 19 12:59:43 2024 From: katrin.fischer at bsz-bw.de (Fischer, Katrin) Date: Tue, 19 Mar 2024 12:59:43 +0100 Subject: [Koha-devel] REMINDER: Development IRC meeting 20 March 2024 Message-ID: <016701da79f4$ee175aa0$ca460fe0$@bsz-bw.de> Hi all, just a small reminder about our meeting tomorrow: https://wiki.koha-community.org/wiki/Development_IRC_meeting_20_March_2024 Time converter: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IR C+Meeting &iso=20240320T1200 Please add to the agenda if you have any topics you'd like to discuss. We'll also look at roadmap projects and their current status. If you are the lead or a supporter for a roadmap project, it would be nice to hear from you! See you there! Katrin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7253 bytes Desc: not available URL: From fridolin.somers at biblibre.com Wed Mar 20 15:02:51 2024 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Wed, 20 Mar 2024 15:02:51 +0100 Subject: [Koha-devel] REST API : PUT for partial update Message-ID: <5a0ca0a1-dacd-4c4c-8a5c-466e8ba21393@biblibre.com> Hi, I've tried to use API for a PUT on patron. Looks like I can't do a partial update, I get error on mandatory datas like if it where a POST. I found this discussion : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23285#c8 Is this a bug ? Best regards, -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From tomascohen at gmail.com Wed Mar 20 16:45:55 2024 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 20 Mar 2024 12:45:55 -0300 Subject: [Koha-devel] REST API : PUT for partial update In-Reply-To: <5a0ca0a1-dacd-4c4c-8a5c-466e8ba21393@biblibre.com> References: <5a0ca0a1-dacd-4c4c-8a5c-466e8ba21393@biblibre.com> Message-ID: When we decided to implement the RESTful API, we agreed PUT is for 'replacing' resources, and PATCH for updating selected pieces of them. I personally never managed to wrap my mind around PATCH and how to validate what tiny bit is allowed to be patched or not. As OpenAPIv2 is not that flexible. But I'm sure Jonathan has implemented PATCH on the ERM, and those controllers look exactly the same as those for PUT. That said, I think we could just implement PATCH on the spec, pointing to the same controllers (for now) on an as-needed basis. Beware validation of combined parameters, etc. Good luck! El mié, 20 mar 2024 a las 11:03, Fridolin SOMERS via Koha-devel (< koha-devel at lists.koha-community.org>) escribió: > Hi, > > I've tried to use API for a PUT on patron. > > Looks like I can't do a partial update, I get error on mandatory datas > like if it where a POST. > > I found this discussion : > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23285#c8 > > Is this a bug ? > > Best regards, > > -- > Fridolin SOMERS > Software and system maintainer 🦄 > BibLibre, France > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.wagner at desy.de Thu Mar 21 09:54:29 2024 From: alexander.wagner at desy.de (Wagner, Alexander) Date: Thu, 21 Mar 2024 09:54:29 +0100 (CET) Subject: [Koha-devel] Ponderings on locations In-Reply-To: <8d2b9423-92f5-48d6-9b63-1b2fe2d9d748@web.de> References: <1531286618.21167163.1709658532458.JavaMail.zimbra@desy.de> <572377161.21472171.1709712675284.JavaMail.zimbra@desy.de> <1158430405.280197.1709817008782.JavaMail.zimbra@desy.de> <8d2b9423-92f5-48d6-9b63-1b2fe2d9d748@web.de> Message-ID: <1377822833.7062971.1711011269226.JavaMail.zimbra@desy.de> Hello Katrin! > maybe something else that could work for some of your use cases is the > course reserves module. Yepp. I actually set up something along those lines based on your comments in the chat some time ago. > It allows you to temporarily change item values while they are in a an > active course reserve and automatically changes them back when they > aren't. I believe it could be useful for exhibitions or the new items > shelf maybe. I think there might be some issue if the items are actually checked out while they are in such a reserve. (Our exhibitions are not some rare books or illuminated manuscripts, but the idea is to pick some theme people would probably not associate with our library holdings and encourage checkouts.) Anyway, what I did now is to set up some "courses" and I can move the items there. For the new items shelf I give them some special item type (to change the loan period) and for the others I just change location. This seems to work well. Now if an item is checked out and checked in again, it would however, keep this item type and AFAIS it's temporary location, while we'd not see on the item as such that it should go back to said location. (IOW we didn't add special markers to the books, and usually they are dropped into the cart.) In this case it would just be re-shelved to the permanent location. So, in these cases they may display a wrong location and calculate a wrong loan period, till we change the exhibition or move them from the new items shelf to their primary location by removing all items from the course reserve items. I think that this is "within the error margin", so this can work out. Especially, as at some point in time we'd always clear the reserves so items move back to their permanent location anyway. As the time span is not years but weeks and our collection is "slightly smaller than the LoC"... > It also gives a nice indication in the OPAC that an item is > currently in a course reserve. Some renaming of things could be achieved > with jQuery/OpacUserJs. Yes, I was pondering to at least attack the "course reserves" name. I already noticed that I could switch of some (in this context confusing) displays via table column settings. Still, it might be worth pondering how Koha handles temporary locations vs. permanent locations. Right now the course reserves attack this issue, then there are the automatic rules to change locations upon check in (and, I think since 23.11, also at check out). There are some magics like CART and PROC, and I have a gut feeling that all this is modelling special cases around the general theme of temporary locations. Abstracting this could probably reduce magic, simplify procedures and code. Especially the CART/PROC-magic is somewhat confusing for a newbe like me. "Ah, there is _PERM_ so I could do this with _every_ location." Rules like `NEW: _PERM_` and `_BLANK_: _PERM_` didn't really work as expected. Those who can read (the docs) have a clear advantage ;) -- Kind regards, Alexander Wagner Deutsches Elektronen-Synchrotron DESY Library and Documentation Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg phone: +49-40-8998-1758 e-mail: alexander.wagner at desy.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2799 bytes Desc: S/MIME Cryptographic Signature URL: From fridolin.somers at biblibre.com Thu Mar 21 11:18:25 2024 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Thu, 21 Mar 2024 11:18:25 +0100 Subject: [Koha-devel] REST API : PUT for partial update In-Reply-To: References: <5a0ca0a1-dacd-4c4c-8a5c-466e8ba21393@biblibre.com> Message-ID: <04ac791e-17f1-4344-aeb4-683f3a36cf60@biblibre.com> OK But currently this means in PUT you need to add in body the required fields (even when unchanged) and the fields you want to change. Missing fields are kept unchanged right ? So there is no way to blank a field ? The need was updating patron expiration date. So maybe better create a dedicated route with only PUT. Like the one for privacy : /public/patrons/{patron_id}/guarantors/can_see_charges We should add some text to wiki : https://wiki.koha-community.org/wiki/Koha_REST_API_Users_Guide Le 20/03/2024 à 16:45, Tomas Cohen Arazi a écrit : > When we decided to implement the RESTful API, we agreed PUT is for > 'replacing' resources, and PATCH for updating selected pieces of them. > > I personally never managed to wrap my mind around PATCH and how to > validate what tiny bit is allowed to be patched or not. As OpenAPIv2 is > not that flexible. > > But I'm sure Jonathan has implemented PATCH on the ERM, and those > controllers look exactly the same as those for PUT. > > That said, I think we could just implement PATCH on the spec, pointing > to the same controllers (for now) on an as-needed basis. > > Beware validation of combined parameters, etc. > > Good luck! > > El mié, 20 mar 2024 a las 11:03, Fridolin SOMERS via Koha-devel > ( >) escribió: > > Hi, > > I've tried to use API for a PUT on patron. > > Looks like I can't do a partial update, I get error on mandatory datas > like if it where a POST. > > I found this discussion : > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23285#c8 > > > Is this a bug ? > > Best regards, > > -- > Fridolin SOMERS > > Software and system maintainer 🦄 > BibLibre, France > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > > website : https://www.koha-community.org/ > > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > > > > > -- > Tomás Cohen Arazi > Theke Solutions (https://theke.io ) > ✆ +54 9351 3513384 > GPG: B2F3C15F -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From magnus at libriotech.no Thu Mar 21 11:20:19 2024 From: magnus at libriotech.no (Magnus Enger) Date: Thu, 21 Mar 2024 11:20:19 +0100 Subject: [Koha-devel] The Global Bug Squashing Day just started (in Kiribati)! Message-ID: <8fb4e860-3b98-4b78-b6c1-564b3bff117b@libriotech.no> Kia ora, dear Community! If you are in Kiribati (or if you choose Kiribati as your time zone) you are in luck, because the Global Bug Squasing Day just started for you! More information and resources here: https://wiki.koha-community.org/wiki/2024-03-22_Global_bug_squashing_day I just copied some numbers related to different bug statuses into the wiki page, so we can try and see how much progress we made at the end. For more individual stats, you can try and see how far you can get your name up the lists for "March" (and "2024") on the dashboard: https://dashboard.koha-community.org/ But don't get too hung up on those numbers either, *everything* helps and *everything* counts: - Answer a question on IRC or the mail lists - Add a comment in Bugzilla - Tall a friend about Koha :-) And most important: Have fun! Best regards, Magnus Libriotech/imCode From fridolin.somers at biblibre.com Thu Mar 21 14:07:05 2024 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Thu, 21 Mar 2024 14:07:05 +0100 Subject: [Koha-devel] REST API : PUT for partial update In-Reply-To: <04ac791e-17f1-4344-aeb4-683f3a36cf60@biblibre.com> References: <5a0ca0a1-dacd-4c4c-8a5c-466e8ba21393@biblibre.com> <04ac791e-17f1-4344-aeb4-683f3a36cf60@biblibre.com> Message-ID: Le 21/03/2024 à 11:18, Fridolin SOMERS via Koha-devel a écrit : > OK > > But currently this means in PUT you need to add in body the required > fields (even when unchanged) and the fields you want to change. > Missing fields are kept unchanged right ? > So there is no way to blank a field ? Looks like we can use null (unquoted of course) : For example in PUT /libraries/ : --data-raw '{ "name": "toto", "library_id": "ID", "address1": null }' It blanks the address1 Anyone confirm ? > > The need was updating patron expiration date. > So maybe better create a dedicated route with only PUT. > Like the one for privacy : > /public/patrons/{patron_id}/guarantors/can_see_charges > > We should add some text to wiki : > https://wiki.koha-community.org/wiki/Koha_REST_API_Users_Guide > > > Le 20/03/2024 à 16:45, Tomas Cohen Arazi a écrit : >> When we decided to implement the RESTful API, we agreed PUT is for >> 'replacing' resources, and PATCH for updating selected pieces of them. >> >> I personally never managed to wrap my mind around PATCH and how to >> validate what tiny bit is allowed to be patched or not. As OpenAPIv2 >> is not that flexible. >> >> But I'm sure Jonathan has implemented PATCH on the ERM, and those >> controllers look exactly the same as those for PUT. >> >> That said, I think we could just implement PATCH on the spec, pointing >> to the same controllers (for now) on an as-needed basis. >> >> Beware validation of combined parameters, etc. >> >> Good luck! >> >> El mié, 20 mar 2024 a las 11:03, Fridolin SOMERS via Koha-devel >> (> >) escribió: >> >>     Hi, >> >>     I've tried to use API for a PUT on patron. >> >>     Looks like I can't do a partial update, I get error on mandatory >> datas >>     like if it where a POST. >> >>     I found this discussion : >>     https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23285#c8 >>     >> >>     Is this a bug ? >> >>     Best regards, >> >>     --     Fridolin SOMERS >     > >>     Software and system maintainer 🦄 >>     BibLibre, France >>     _______________________________________________ >>     Koha-devel mailing list >>     Koha-devel at lists.koha-community.org >>     >>     https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> >> >>     website : https://www.koha-community.org/ >>     >>     git : https://git.koha-community.org/ >> >>     bugs : https://bugs.koha-community.org/ >>     >> >> >> >> -- >> Tomás Cohen Arazi >> Theke Solutions (https://theke.io ) >> ✆ +54 9351 3513384 >> GPG: B2F3C15F > -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From tomascohen at gmail.com Thu Mar 21 14:15:46 2024 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Thu, 21 Mar 2024 10:15:46 -0300 Subject: [Koha-devel] REST API : PUT for partial update In-Reply-To: References: <5a0ca0a1-dacd-4c4c-8a5c-466e8ba21393@biblibre.com> <04ac791e-17f1-4344-aeb4-683f3a36cf60@biblibre.com> Message-ID: Setting a null value willl set it to null, if nullable. Yes! El jue, 21 mar 2024 a las 10:07, Fridolin SOMERS via Koha-devel (< koha-devel at lists.koha-community.org>) escribió: > > > Le 21/03/2024 à 11:18, Fridolin SOMERS via Koha-devel a écrit : > > OK > > > > But currently this means in PUT you need to add in body the required > > fields (even when unchanged) and the fields you want to change. > > Missing fields are kept unchanged right ? > > So there is no way to blank a field ? > Looks like we can use null (unquoted of course) : > For example in PUT /libraries/ : > --data-raw '{ "name": "toto", "library_id": "ID", "address1": null }' > > It blanks the address1 > > Anyone confirm ? > > > > > The need was updating patron expiration date. > > So maybe better create a dedicated route with only PUT. > > Like the one for privacy : > > /public/patrons/{patron_id}/guarantors/can_see_charges > > > > We should add some text to wiki : > > https://wiki.koha-community.org/wiki/Koha_REST_API_Users_Guide > > > > > > Le 20/03/2024 à 16:45, Tomas Cohen Arazi a écrit : > >> When we decided to implement the RESTful API, we agreed PUT is for > >> 'replacing' resources, and PATCH for updating selected pieces of them. > >> > >> I personally never managed to wrap my mind around PATCH and how to > >> validate what tiny bit is allowed to be patched or not. As OpenAPIv2 > >> is not that flexible. > >> > >> But I'm sure Jonathan has implemented PATCH on the ERM, and those > >> controllers look exactly the same as those for PUT. > >> > >> That said, I think we could just implement PATCH on the spec, pointing > >> to the same controllers (for now) on an as-needed basis. > >> > >> Beware validation of combined parameters, etc. > >> > >> Good luck! > >> > >> El mié, 20 mar 2024 a las 11:03, Fridolin SOMERS via Koha-devel > >> ( >> >) escribió: > >> > >> Hi, > >> > >> I've tried to use API for a PUT on patron. > >> > >> Looks like I can't do a partial update, I get error on mandatory > >> datas > >> like if it where a POST. > >> > >> I found this discussion : > >> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23285#c8 > >> > > >> > >> Is this a bug ? > >> > >> Best regards, > >> > >> -- Fridolin SOMERS >> > > >> Software and system maintainer 🦄 > >> BibLibre, France > >> _______________________________________________ > >> Koha-devel mailing list > >> Koha-devel at lists.koha-community.org > >> > >> > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > >> > >> > >> website : https://www.koha-community.org/ > >> > >> git : https://git.koha-community.org/ > >> > >> bugs : https://bugs.koha-community.org/ > >> > >> > >> > >> > >> -- > >> Tomás Cohen Arazi > >> Theke Solutions (https://theke.io ) > >> ✆ +54 9351 3513384 > >> GPG: B2F3C15F > > > > -- > Fridolin SOMERS > Software and system maintainer 🦄 > BibLibre, France > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -- 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 Mon Mar 25 02:22:38 2024 From: dcook at prosentient.com.au (David Cook) Date: Mon, 25 Mar 2024 12:22:38 +1100 Subject: [Koha-devel] Elasticsearch sans Zebra Message-ID: <002c01da7e52$ecc03b10$c640b130$@prosentient.com.au> Hi all, I have started using Elasticsearch more with Koha, and we're at a point of wanting to use Elasticsearch without Zebra for Koha. I came across "Bug 21820 - Zebraqueue should not be added to when only Elasticsearch is used" and it seems like other people are interested in this too. I imagine it's just a case of getting a patch written? Overall, it's an idea that people support? David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at davidschmidt.at Mon Mar 25 12:29:52 2024 From: mail at davidschmidt.at (David Schmidt) Date: Mon, 25 Mar 2024 12:29:52 +0100 Subject: [Koha-devel] Elasticsearch sans Zebra In-Reply-To: <002c01da7e52$ecc03b10$c640b130$@prosentient.com.au> References: <002c01da7e52$ecc03b10$c640b130$@prosentient.com.au> Message-ID: Hi David the majority of our Koha installations use Elastiscearch and we have a process that deactivates zebra but we would love to see the change you proposed. I vaguely remember a bug where not having zebra running caused a problem (with background jobs i think) even if ES is in charge of indexing. cheers david (HKS3/www.koha-support.eu) On Mon, 25 Mar 2024, at 2:22 AM, David Cook via Koha-devel wrote: > Hi all, > > I have started using Elasticsearch more with Koha, and we’re at a point of wanting to use Elasticsearch without Zebra for Koha. > > I came across “Bug 21820 - Zebraqueue should not be added to when only Elasticsearch is used” and it seems like other people are interested in this too. > > > I imagine it’s just a case of getting a patch written? Overall, it’s an idea that people support? > > David Cook > Senior Software Engineer > Prosentient Systems > Suite 7.03 > 6a Glen St > Milsons Point NSW 2061 > Australia > > Office: 02 9212 0899 > Online: 02 8005 0595 > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolin.somers at biblibre.com Mon Mar 25 13:54:13 2024 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Mon, 25 Mar 2024 13:54:13 +0100 Subject: [Koha-devel] Elasticsearch sans Zebra In-Reply-To: References: <002c01da7e52$ecc03b10$c640b130$@prosentient.com.au> Message-ID: Hi, We have patch since a few years for that because filling zebraqueue is useless and can't be removed with cleanup_database.pl : https://git.biblibre.com/biblibre/kohac/commit/50ae1a44d200c6fa46940107d15bef6d66e55383 It would be nice to have a more official way ;) Best regards Le 25/03/2024 à 12:29, David Schmidt via Koha-devel a écrit : > Hi David > > the majority of our Koha installations use Elastiscearch and we have a > process that deactivates zebra but we would love to see the change you > proposed. > > I vaguely remember a bug where not having zebra running caused a problem > (with background jobs i think) even if ES is in charge of indexing. > > cheers > david (HKS3/www.koha-support.eu) > > On Mon, 25 Mar 2024, at 2:22 AM, David Cook via Koha-devel wrote: >> >> Hi all, >> >> >> I have started using Elasticsearch more with Koha, and we’re at a >> point of wanting to use Elasticsearch without Zebra for Koha. >> >> I came across “Bug 21820 - Zebraqueue should not be added to when only >> Elasticsearch is used” and it seems like other people are interested >> in this too. >> >> >> I imagine it’s just a case of getting a patch written? Overall, it’s >> an idea that people support? >> >> >> David Cook >> >> Senior Software Engineer >> >> Prosentient Systems >> >> Suite 7.03 >> >> 6a Glen St >> >> Milsons Point NSW 2061 >> >> Australia >> >> >> Office: 02 9212 0899 >> >> Online: 02 8005 0595 >> >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> >> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> >> website : https://www.koha-community.org/ >> >> git : https://git.koha-community.org/ >> bugs : https://bugs.koha-community.org/ >> > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From philippe.blouin at inlibro.com Mon Mar 25 13:59:51 2024 From: philippe.blouin at inlibro.com (Philippe Blouin) Date: Mon, 25 Mar 2024 08:59:51 -0400 Subject: [Koha-devel] Elasticsearch sans Zebra In-Reply-To: References: <002c01da7e52$ecc03b10$c640b130$@prosentient.com.au> Message-ID: <1a5922f3-bb33-421a-bdca-a3022b70f1d3@inlibro.com> Hi! We have a scenario (albeit an exception) where both are used, due to the limitation of ES's z3950. So we fill zebraqueue uselessly in 199 Koha, but really really need it in 1. Logo inLibro Philippe Blouin Directeur de la technologie T 833-INLIBRO (465-4276) , poste 230 C philippe.blouin at inLibro.com www.inLibro.com On 2024-03-25 08:54, Fridolin SOMERS via Koha-devel wrote: > Hi, > > We have patch since a few years for that because filling zebraqueue is > useless and can't be removed with cleanup_database.pl : > https://git.biblibre.com/biblibre/kohac/commit/50ae1a44d200c6fa46940107d15bef6d66e55383 > > > It would be nice to have a more official way ;) > > Best regards > > Le 25/03/2024 à 12:29, David Schmidt via Koha-devel a écrit : >> Hi David >> >> the majority of our Koha installations use Elastiscearch and we have >> a process that deactivates zebra but we would love to see the change >> you proposed. >> >> I vaguely remember a bug where not having zebra running caused a >> problem (with background jobs i think) even if ES is in charge of >> indexing. >> >> cheers >> david (HKS3/www.koha-support.eu) >> >> On Mon, 25 Mar 2024, at 2:22 AM, David Cook via Koha-devel wrote: >>> >>> Hi all, >>> >>> >>> I have started using Elasticsearch more with Koha, and we’re at a >>> point of wanting to use Elasticsearch without Zebra for Koha. >>> >>> I came across “Bug 21820 - Zebraqueue should not be added to when >>> only Elasticsearch is used” and it seems like other people are >>> interested in this too. >>> >>> >>> I imagine it’s just a case of getting a patch written? Overall, it’s >>> an idea that people support? >>> >>> >>> David Cook >>> >>> Senior Software Engineer >>> >>> Prosentient Systems >>> >>> Suite 7.03 >>> >>> 6a Glen St >>> >>> Milsons Point NSW 2061 >>> >>> Australia >>> >>> >>> Office: 02 9212 0899 >>> >>> Online: 02 8005 0595 >>> >>> >>> _______________________________________________ >>> Koha-devel mailing list >>> Koha-devel at lists.koha-community.org >>> >>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>> >>> website : https://www.koha-community.org/ >>> >>> git : https://git.koha-community.org/ >>> bugs : https://bugs.koha-community.org/ >>> >>> >> >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : https://www.koha-community.org/ >> git : https://git.koha-community.org/ >> bugs : https://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Wed Mar 27 02:10:01 2024 From: dcook at prosentient.com.au (David Cook) Date: Wed, 27 Mar 2024 12:10:01 +1100 Subject: [Koha-devel] Elasticsearch indexing does not handle exceptions well Message-ID: <01b601da7fe3$7ecf0090$7c6d01b0$@prosentient.com.au> Hi all, I'm re-indexing Elasticsearch and I notice occasionally Elasticsearch will throw an exception when committing (e.g. Elasticsearch exception thrown: Request), and Koha just ignores it. That means that whole commit gets missed, so a default of 5000 records don't get indexed. You can probably find those inconsistencies using /usr/share/koha/bin/maintenance/compare_es_to_db.pl but that doesn't provide you a method for indexing those missed records either. Am I missing something obvious here? I'll need to look at increasing the verbosity to get more of the error message, and I'll play around with some settings to make it so that the Elasticsearch server doesn't thrown an error, but this seems weird to me. Perhaps we should have an automatic re-try, or at least a record of what records failed to be committed, so that they can be manually retried via a different mechanism? David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolin.somers at biblibre.com Wed Mar 27 11:21:50 2024 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Wed, 27 Mar 2024 11:21:50 +0100 Subject: [Koha-devel] Elasticsearch sans Zebra In-Reply-To: <1a5922f3-bb33-421a-bdca-a3022b70f1d3@inlibro.com> References: <002c01da7e52$ecc03b10$c640b130$@prosentient.com.au> <1a5922f3-bb33-421a-bdca-a3022b70f1d3@inlibro.com> Message-ID: <67c64095-4074-41f7-ac46-754c72b4d374@biblibre.com> Ah nope, z39.50 can be handled by misc/z3950_responder.pl https://wiki.koha-community.org/wiki/Setting_up_the_Z39.50_and_SRU_Server Le 25/03/2024 à 13:59, Philippe Blouin a écrit : > Hi! > > We have a scenario (albeit an exception) where both are used, due to the > limitation of ES's z3950. > > So we fill zebraqueue uselessly in 199 Koha, but really really need it in 1. > > Logo inLibro Philippe Blouin > Directeur de la technologie > > T 833-INLIBRO (465-4276) , poste 230 > C philippe.blouin at inLibro.com > > www.inLibro.com > > On 2024-03-25 08:54, Fridolin SOMERS via Koha-devel wrote: >> Hi, >> >> We have patch since a few years for that because filling zebraqueue is >> useless and can't be removed with cleanup_database.pl : >> https://git.biblibre.com/biblibre/kohac/commit/50ae1a44d200c6fa46940107d15bef6d66e55383 >> >> It would be nice to have a more official way ;) >> >> Best regards >> >> Le 25/03/2024 à 12:29, David Schmidt via Koha-devel a écrit : >>> Hi David >>> >>> the majority of our Koha installations use Elastiscearch and we have >>> a process that deactivates zebra but we would love to see the change >>> you proposed. >>> >>> I vaguely remember a bug where not having zebra running caused a >>> problem (with background jobs i think) even if ES is in charge of >>> indexing. >>> >>> cheers >>> david (HKS3/www.koha-support.eu) >>> >>> On Mon, 25 Mar 2024, at 2:22 AM, David Cook via Koha-devel wrote: >>>> >>>> Hi all, >>>> >>>> >>>> I have started using Elasticsearch more with Koha, and we’re at a >>>> point of wanting to use Elasticsearch without Zebra for Koha. >>>> >>>> I came across “Bug 21820 - Zebraqueue should not be added to when >>>> only Elasticsearch is used” and it seems like other people are >>>> interested in this too. >>>> >>>> >>>> I imagine it’s just a case of getting a patch written? Overall, it’s >>>> an idea that people support? >>>> >>>> >>>> David Cook >>>> >>>> Senior Software Engineer >>>> >>>> Prosentient Systems >>>> >>>> Suite 7.03 >>>> >>>> 6a Glen St >>>> >>>> Milsons Point NSW 2061 >>>> >>>> Australia >>>> >>>> >>>> Office: 02 9212 0899 >>>> >>>> Online: 02 8005 0595 >>>> >>>> >>>> _______________________________________________ >>>> Koha-devel mailing list >>>> Koha-devel at lists.koha-community.org >>>> >>>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>>> >>>> website : https://www.koha-community.org/ >>>> >>>> git : https://git.koha-community.org/ >>>> bugs : https://bugs.koha-community.org/ >>>> >>>> >>> >>> >>> _______________________________________________ >>> Koha-devel mailing list >>> Koha-devel at lists.koha-community.org >>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>> website : https://www.koha-community.org/ >>> git : https://git.koha-community.org/ >>> bugs : https://bugs.koha-community.org/ >> -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From philippe.blouin at inlibro.com Wed Mar 27 13:29:45 2024 From: philippe.blouin at inlibro.com (Philippe Blouin) Date: Wed, 27 Mar 2024 08:29:45 -0400 Subject: [Koha-devel] Elasticsearch sans Zebra In-Reply-To: <67c64095-4074-41f7-ac46-754c72b4d374@biblibre.com> References: <002c01da7e52$ecc03b10$c640b130$@prosentient.com.au> <1a5922f3-bb33-421a-bdca-a3022b70f1d3@inlibro.com> <67c64095-4074-41f7-ac46-754c72b4d374@biblibre.com> Message-ID: <30c657f7-6a20-4f14-ab23-8edfd1baedb4@inlibro.com> Well, not really.  Hammat asked about limitations on Feb 28 on this very list, because attributes are not well handled. Logo inLibro Philippe Blouin Directeur de la technologie T 833-INLIBRO (465-4276) , poste 230 C philippe.blouin at inLibro.com www.inLibro.com On 2024-03-27 06:21, Fridolin SOMERS via Koha-devel wrote: > Ah nope, z39.50 can be handled by misc/z3950_responder.pl > https://wiki.koha-community.org/wiki/Setting_up_the_Z39.50_and_SRU_Server > > Le 25/03/2024 à 13:59, Philippe Blouin a écrit : >> Hi! >> >> We have a scenario (albeit an exception) where both are used, due to >> the limitation of ES's z3950. >> >> So we fill zebraqueue uselessly in 199 Koha, but really really need >> it in 1. >> >> Logo inLibro      Philippe Blouin >> Directeur de la technologie >> >> T 833-INLIBRO (465-4276) , poste 230 >> C philippe.blouin at inLibro.com >> >> www.inLibro.com >> >> On 2024-03-25 08:54, Fridolin SOMERS via Koha-devel wrote: >>> Hi, >>> >>> We have patch since a few years for that because filling zebraqueue >>> is useless and can't be removed with cleanup_database.pl : >>> https://git.biblibre.com/biblibre/kohac/commit/50ae1a44d200c6fa46940107d15bef6d66e55383 >>> >>> >>> It would be nice to have a more official way ;) >>> >>> Best regards >>> >>> Le 25/03/2024 à 12:29, David Schmidt via Koha-devel a écrit : >>>> Hi David >>>> >>>> the majority of our Koha installations use Elastiscearch and we >>>> have a process that deactivates zebra but we would love to see the >>>> change you proposed. >>>> >>>> I vaguely remember a bug where not having zebra running caused a >>>> problem (with background jobs i think) even if ES is in charge of >>>> indexing. >>>> >>>> cheers >>>> david (HKS3/www.koha-support.eu) >>>> >>>> On Mon, 25 Mar 2024, at 2:22 AM, David Cook via Koha-devel wrote: >>>>> >>>>> Hi all, >>>>> >>>>> >>>>> I have started using Elasticsearch more with Koha, and we’re at a >>>>> point of wanting to use Elasticsearch without Zebra for Koha. >>>>> >>>>> I came across “Bug 21820 - Zebraqueue should not be added to when >>>>> only Elasticsearch is used” and it seems like other people are >>>>> interested in this too. >>>>> >>>>> >>>>> I imagine it’s just a case of getting a patch written? Overall, >>>>> it’s an idea that people support? >>>>> >>>>> >>>>> David Cook >>>>> >>>>> Senior Software Engineer >>>>> >>>>> Prosentient Systems >>>>> >>>>> Suite 7.03 >>>>> >>>>> 6a Glen St >>>>> >>>>> Milsons Point NSW 2061 >>>>> >>>>> Australia >>>>> >>>>> >>>>> Office: 02 9212 0899 >>>>> >>>>> Online: 02 8005 0595 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Koha-devel mailing list >>>>> Koha-devel at lists.koha-community.org >>>>> >>>>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>>>> >>>>> website : https://www.koha-community.org/ >>>>> >>>>> git : https://git.koha-community.org/ >>>>> >>>>> bugs : https://bugs.koha-community.org/ >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Koha-devel mailing list >>>> Koha-devel at lists.koha-community.org >>>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>>> website : https://www.koha-community.org/ >>>> git : https://git.koha-community.org/ >>>> bugs : https://bugs.koha-community.org/ >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu Mar 28 03:45:27 2024 From: dcook at prosentient.com.au (David Cook) Date: Thu, 28 Mar 2024 13:45:27 +1100 Subject: [Koha-devel] Elasticsearch sans Zebra In-Reply-To: <30c657f7-6a20-4f14-ab23-8edfd1baedb4@inlibro.com> References: <002c01da7e52$ecc03b10$c640b130$@prosentient.com.au> <1a5922f3-bb33-421a-bdca-a3022b70f1d3@inlibro.com> <67c64095-4074-41f7-ac46-754c72b4d374@biblibre.com> <30c657f7-6a20-4f14-ab23-8edfd1baedb4@inlibro.com> Message-ID: <023401da80ba$021872c0$06495840$@prosentient.com.au> Can you be more specific? If there’s a problem, a ticket should be raised. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel On Behalf Of Philippe Blouin via Koha-devel Sent: Wednesday, 27 March 2024 11:30 PM To: Fridolin SOMERS ; koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Elasticsearch sans Zebra Well, not really. Hammat asked about limitations on Feb 28 on this very list, because attributes are not well handled. Philippe Blouin Directeur de la technologie T 833-INLIBRO (465-4276), poste 230 C philippe.blouin at inLibro.com www.inLibro.com On 2024-03-27 06:21, Fridolin SOMERS via Koha-devel wrote: Ah nope, z39.50 can be handled by misc/z3950_responder.pl https://wiki.koha-community.org/wiki/Setting_up_the_Z39.50_and_SRU_Server Le 25/03/2024 à 13:59, Philippe Blouin a écrit : Hi! We have a scenario (albeit an exception) where both are used, due to the limitation of ES's z3950. So we fill zebraqueue uselessly in 199 Koha, but really really need it in 1. Logo inLibro Philippe Blouin Directeur de la technologie T 833-INLIBRO (465-4276) , poste 230 C philippe.blouin at inLibro.com www.inLibro.com On 2024-03-25 08:54, Fridolin SOMERS via Koha-devel wrote: Hi, We have patch since a few years for that because filling zebraqueue is useless and can't be removed with cleanup_database.pl : https://git.biblibre.com/biblibre/kohac/commit/50ae1a44d200c6fa46940107d15bef6d66e55383 It would be nice to have a more official way ;) Best regards Le 25/03/2024 à 12:29, David Schmidt via Koha-devel a écrit : Hi David the majority of our Koha installations use Elastiscearch and we have a process that deactivates zebra but we would love to see the change you proposed. I vaguely remember a bug where not having zebra running caused a problem (with background jobs i think) even if ES is in charge of indexing. cheers david (HKS3/www.koha-support.eu) On Mon, 25 Mar 2024, at 2:22 AM, David Cook via Koha-devel wrote: Hi all, I have started using Elasticsearch more with Koha, and we’re at a point of wanting to use Elasticsearch without Zebra for Koha. I came across “Bug 21820 - Zebraqueue should not be added to when only Elasticsearch is used” and it seems like other people are interested in this too. I imagine it’s just a case of getting a patch written? Overall, it’s an idea that people support? David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohanews at gmail.com Thu Mar 28 10:46:30 2024 From: kohanews at gmail.com (Koha Newsletter) Date: Thu, 28 Mar 2024 10:46:30 +0100 Subject: [Koha-devel] Koha Community Newsletter: March 2024 Message-ID: The Koha Community Newsletter for March 2024 is here: https://koha-community.org/koha-community-newsletter-march-2024/ Many thanks to everyone who submitted articles and news to this newsletter! Please feel free to email me with any corrections or suggestions. -- Michael Kuhn Editor, Koha Community Newsletter -------------- next part -------------- An HTML attachment was scrubbed... URL: