February 2026 - Koha-bugs - lists.koha-community.org

[Bug 40076] New: Add --skip-no-email parameter to borrowers-force-messaging-defaults.pl
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40076 Bug ID: 40076 Summary: Add --skip-no-email parameter to borrowers-force-messaging-defaults.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz I use this script a lot during migrations to set the default preferences from the categories to all the patrons. However, recently I've had cases where about half the patrons did not have email addresses in their accounts. This means that I either set everyone's preferences and the library has to go back and remove the preferences from the patrons without email addresses, or I don't do it, and the library has to set the preferences for those with email addresses. (I think I've had back-to-back cases like this because in their old system it was set up as if the patron has an email address, they get the email notices, and if they want to opt-out, they remove their email address from their account.) It would be great if the script could skip the patrons without email addresses. (Note : we never set SMS messages by default, only email; I don't know if someone does this, but it is not a requirement for us to manage sms messaging with this script.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 41822] New: Add --skip-no-sms parameter to borrowers-force-messaging-defaults.pl
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41822 Bug ID: 41822 Summary: Add --skip-no-sms parameter to borrowers-force-messaging-defaults.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz It would be great to have a special treatment for patrons without any SMS number to avoid setting SMS message preferences when the patron doesn't have a number. Use case : Already in production, we what to use this script to update/unify messaging preferences. Around half the patrons have an SMS number, all have an email address. We want to be able to set SMS notification for those with an SMS number but not for those without any SMS number. Currently, - if we check the SMS checkbox in the patron category then use the script, it will add SMS for every patron, which is not what we want. - But if we uncheck the SMS checkbox in the patron category, it will be removed for patrons that have an SMS number, which is still not what we want. It would be great to not set the SMS preference if the patron have no SMS number, but still set the email preference for this patron. This behavior could be tied to a parameter given to the script. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39579] New: Add Ability to restrict patron date of birth on self registration
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39579 Bug ID: 39579 Summary: Add Ability to restrict patron date of birth on self registration Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexander.blanchard(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries are getting dates of birth from the self-registration form that make patrons impossible ages e.g. year of birth 1900. Add a system preference to allow libraries to add a maximum age when patrons self register so that they receive an error message if their date of birth exceeds this age, prompting them to make a correction. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 33204] New: Add the ability to filter on patron library for borrowers-force-messaging-defaults.pl
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33204 Bug ID: 33204 Summary: Add the ability to filter on patron library for borrowers-force-messaging-defaults.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Like filter on category Bug 19454, it would be helpful to filter on a specified library for misc/maintenance/borrowers-force-messaging-defaults.pl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 36734] New: Add --branchcode option to borrowers_force_messaging_defaults.pl
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36734 Bug ID: 36734 Summary: Add --branchcode option to borrowers_force_messaging_defaults.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz I use this script a lot during migrations, to give all imported patrons the default messaging preferences. However, in some cases, I'd like to give the preferences only to the patrons from one branch. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 41808] New: Don't trigger value builder plugins in batch item modification
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41808 Bug ID: 41808 Summary: Don't trigger value builder plugins in batch item modification Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: philip.orr(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Value builder plugins such as e.g. stocknumberam123.pl can be triggered while in batch item modification. This is a problem because it will cause the batch of items to take the new value, overwriting previously saved values in the items. We should try to not trigger value builder plugins while in batch item modification, only in normal item modification / item creation. To reproduce: 1. Find an example biblio and note which framework it was catalogued in (Edit -> Edit Record -> Check which framework is selected in the "Settings" dropdown at the top of the editing page) 2. Go to Administration -> MARC bibliographic framework -> on that framework, "Actions -> MARC Structure" 3. Find MARC fields 952$ -> "Actions -> Edit subfields" 4. Edit subfield 952$i 5. Select the value builder plugin stocknumberam123.pl 6. save 7. Go back to your example biblio, add an item, add a new stock number to field 952$i, save 8. Find barcodes of other items of biblios from your chosen framework and add them to a batch item modification 9. in the batch item modification template, click into the "Inventory number" field and then click somewhere else - the field will be incremented. At this point, there is no way to stop the field from incrementing. Even if you delete the value from the field, if you save the modification, it will still save the incremented value for all items in the batch. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 39314] New: RabbitMQ can't upgrade from 3.x to 4.x without running a data migration on 3.13
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39314 Bug ID: 39314 Summary: RabbitMQ can't upgrade from 3.x to 4.x without running a data migration on 3.13 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Reported to Debian as it affects their next release which will do a jump from 3.10 to 4.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100165#10 Which can't work: https://www.rabbitmq.com/docs/upgrade «You can only upgrade to RabbitMQ 4.0 from RabbitMQ 3.13.» «stable feature flags have to be enabled before the upgrade. The upgrade will fail if you miss this step.» See there more more details. ----- For us: is there still data in RabbitMQ when stopping a Koha instance and upgrading it? I recall reading that the DB was basically mirroring the message queue data during a discussion about the actual need for a dedicated message queue. Does it mean the koha-common package can wipe the RabbitMQ data which will allow it to start without issue? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 41817] New: REST API: CRUD endpoints for vendor edi accounts
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41817 Bug ID: 41817 Summary: REST API: CRUD endpoints for vendor edi accounts Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Add api endpoints for handling vendor edi accounts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 21303] New: XSLT should look in LDR/18 to know whether to add punctuation or not
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21303 Bug ID: 21303 Summary: XSLT should look in LDR/18 to know whether to add punctuation or not Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I noticed the XSLT sometimes adds or removes punctuation. If the cataloguers already add the punctuation while cataloguing, this causes double punctuation or no punctuation at all where there should be. For instance, I have a record where there is a period (.) at the end of 100$e. So in MARC, it looks like 100 1# a Goscinny, René, d 1926-1977-, e author. In intranet details, it looks like Goscinny, René, 1926-1977- [author.]. There are two periods (and no comma after the date). In the 260 field, the opposite happens. There is a period at the end of 260$c in MARC, but nothing is appearing in intranet results. 260 ## a Paris : b Gallimard jeunesse, c [2014]. In the intranet details, it looks like Paris : Gallimard jeunesse, [2014] There is no period after the date. MARC21 has a code in LDR/18 to indicate whether or not punctuation has been included in the cataloguing. XSLT should obey this code to determine if it should add punctuation or not. LDR/18 possible codes # - Non-ISBD a - AACR2 c - ISBD punctuation omitted i - ISBD punctuation included n - Non-ISBD punctuation omitted u - Unknown -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 41816] New: Wrong additional fields base class in Koha::Acquisition::Booksellers;
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '26

11 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41816 Bug ID: 41816 Summary: Wrong additional fields base class in Koha::Acquisition::Booksellers; Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It seems like the wrong additional fields mixin was used for Koha::Acquisition::Booksellers in bug 38262, Koha::Object::Mixin::AdditionalFields when it should have been Koha::Objects::Mixin::AdditionalFields. Here is a fix for that. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1