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

[Bug 17656] New: Irregularities in serial prediction pattern are planned only for the current year
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '26

06 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17656 Bug ID: 17656 Summary: Irregularities in serial prediction pattern are planned only for the current year Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P2 Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com When you se, through test prediction pattern, a serial pattern including planned irregularities (for example a 1/month serial that you know there's no issue on july), this is only valid fot the current subscription. Over the next renewal, you will have to set it again which is very tedious. We should be able to configure this in the long run (as it was possible in previous version of Koha before 3.14, I think) Olivier Crouzet -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 391

[Bug 7464] Add ability to automatically add ISBD punctuation
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '26

05 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7464 Miranda Nero <mnero(a)oslri.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mnero(a)oslri.net -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 27734] New: OpacHiddenItems produces a 404 from borrower holds list
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '26

05 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27734 Bug ID: 27734 Summary: OpacHiddenItems produces a 404 from borrower holds list Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: mfuerst(a)hmcpl.org QA Contact: testopia(a)bugs.koha-community.org When a borrower clicks on a hold in their holds list they have placed on a title that was subsequently hidden with OpacHiddenItems, it results in a 404 error instead of the "This record is blocked" error page. It seems like OpacHiddenItems should work the same as individually suppressed records and how they are handled in OpacSuppressionRedirect. This would make more sense from the user's perspective. -- You are receiving this mail because: You are watching all bug changes.

1 46

[Bug 42776] New: Item modifications by age rule displays error message when it should not
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '26

05 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42776 Bug ID: 42776 Summary: Item modifications by age rule displays error message when it should not Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 200028 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200028&action=e… A field name is required message To replicate: 1. Add a rule to update a lost item to withdrawn. Notice the Substitution part of the rule contains red text that says "A field name is required". The message seems to imply a field name is missing for the substitution, even when the field contains a name. This is confusing because it implies the user needs to take an action before saving. The rule can be saved regardless of the messaging. See the screenshot. It would be nice if the message appeared if a field name was not selected, but otherwise not appear if the field name has been selected. It also appears the message only appears for the substitution and not the condition. It should probably appear for both. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42775] New: Self-checkout userid should automatically have focus on the self-checkout page
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '26

05 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42775 Bug ID: 42775 Summary: Self-checkout userid should automatically have focus on the self-checkout page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org When using the Self-checkout module, staff need to log in with the SCO User before patrons can log in with their card number. During this first step, it would be nice if the username field for the SCO User gained focus when the page loaded. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 40171] New: ILL Patron Has No Email Address on File message upon "Send Notice To Patron"
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '26

05 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40171 Bug ID: 40171 Summary: ILL Patron Has No Email Address on File message upon "Send Notice To Patron" Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: tech(a)bethlehemlibraryct.org QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com In using the ILL module, I noticed that when using the "Send Notice to Patron" button, I get no feedback as to whether the notification was sent successfully. Specifically, I had an ILL request from a patron with no email address on file. I assumed that an email was sent to the patron after clicking the button, but since he had no email address on file, he wasn't notified. It would be really helpful to have a message pop up saying "Patron has no email address on file. Please call XXX-XXX-XXXX to let them know that their ILL request has arrived." (or something similar) so that the staff member knows they need to call the patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 42774] New: "sip2" permission missing on upgraded Koha if SIPconfig.xml file doesn't exist
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '26

05 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42774 Bug ID: 42774 Summary: "sip2" permission missing on upgraded Koha if SIPconfig.xml file doesn't exist Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Bug 37893 is a really cool feature and I wanted to use it for a Koha instance I've upgraded to 25.11 where I'm setting up SIP2 for the first time. ...and I notice that I can't access the functionality in Administration. And the reason is because in 25.11, 26.05, and main installer/data/mysql/db_revs/250600035.pl skips the end of the db_revs if the SIPconfig.xml is missing. This makes sense, because there's no point trying to do a SIPconfig.xml to database migration if there is no SIPconfig.xml file. However... the oopsie is that at the very bottom of the script there are the following lines: $dbh->do( q{INSERT IGNORE INTO userflags (bit, flag, flagdesc, defaulton) VALUES (31, 'sip2', 'Manage SIP2 module', 0) } ); And if you don't have those lines... you don't have any sip2 permission... which means you can't *see* the link text "Self-service circulation (SIP2)" to take you to /cgi-bin/koha/sip2/sip2.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 42761] New: Error when switching to Advanced editor after importing Z39.50
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '26

05 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42761 Bug ID: 42761 Summary: Error when switching to Advanced editor after importing Z39.50 Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: sam.young(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When we import using Z39.50 it opens in the basic editor. When we try to switch to advanced a javascript alert pops up saying "The record cannot be transferred to the advanced editor. Continue?". If we click on continue the record is actually transferred to the advanced editor. This happens ONLY when you click on the import from the z39.50 screen. Looking at the code it is happening in addbiblio.tt on line 41-43 where var breedingid = [% breedingid || "null" | html %]; if ( !confirm( breedingid ? _("This record cannot be transferred to the advanced editor. Continue?") : _("Any changes will not be saved. Continue?") ) ) return false; the breedingid exists here BUT will still transfer to the editor can we get this logic fixed? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 35292] New: Define itemtype specific rules in the UpdateNotForLoanStatusOnCheckOut system preference
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '26

05 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35292 Bug ID: 35292 Summary: Define itemtype specific rules in the UpdateNotForLoanStatusOnCheckOut system preference Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com For parity and more workflow options, adding the same option to the new status that updates not for loan on checkout should also have the ability to limit by item type like Bug 25560 did for check in. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 80

[Bug 39944] New: Metadata should be trimmed before creating an ILL request
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '26

05 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39944 Bug ID: 39944 Summary: Metadata should be trimmed before creating an ILL request Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: pedro.amorim(a)openfifth.co.uk Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com When creating an ILL request, if the form data contains leading or trailing whitespaces, this may cause issues for backends. Example: A DOI is entered as ' 123', instead of '123'. If the backend needs to use that data entry, it'll need to first trim and/or sanitize it. It's better if core Koha does this trimming before delegating the creation of the request to the backend, so it's maintained in a single place. -- You are receiving this mail because: You are watching all bug changes.

1 17