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

[Bug 42681] New: (Bug 34971 follow-up) serials/serials-collection.pl generates error 500
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42681 Bug ID: 42681 Summary: (Bug 34971 follow-up) serials/serials-collection.pl generates error 500 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: baptiste.wojtkowski(a)biblibre.com Depends on: 34971 When working with subscription without superlibrarian permissions the page /cgi-bin/koha/serials/serials-collection.pl?subscriptionid=NNN generates error 500 with an entry: Can't use string ("NNN") as a HASH ref while "strict refs" in use at /usr/share/koha/lib/C4/Serials.pm line 2792. in plack-error.log. This is because can_edit_subscription called in serials/serials-collection.pl (line ~234) requires a hash reference containing data from the subscription table (or an unblessed Koha::Subscription object), and not subscriptionid. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34971 [Bug 34971] Closing a subscription should require edit_subscription permission -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 42055] New: Real time holds queue doesn't rebuild when hold from group hold is filled
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42055 Bug ID: 42055 Summary: Real time holds queue doesn't rebuild when hold from group hold is filled Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com If a library is using the real-time holds queue and a hold that is part of a group hold/hyperhold is filled, the queue isn't rebuilt to remove the other titles. To replicate: -Make sure library is using the real-time holds queue. -Create a group hold with multiple items available at one or more libraries. -Note that all available titles show on the holds queue(s) (see bug 42054). -Check an item in to satisfy the hold group. -Re-run the holds queue(s), and note that the other items from the group hold still show. The queue only appears to rebuild once the item that filled the hold is checked out. If a library checks one of the other items from the group in after the hold has been filled, the later item(s) won't trigger. This is correct behavior, but the fact that the other titles from the group still show on the queue is likely to cause significant frustration and confusion for libraries. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 42897] New: FilterSearchResultsByLoggedInBranch display should expand and collapse
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42897 Bug ID: 42897 Summary: FilterSearchResultsByLoggedInBranch display should expand and collapse Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- With the new system preference FilterSearchResultsByLoggedInBranch, it would be nice to be able to expand and collapse the view of all holdings at all locations without needing to keep toggling between show items in all libraries and show local items only. When defaulting to show items in all libraries, a popular title with many copies or a magazine like People with many issues and copies can take up most of the screen of search results. Having an expand/collapse display of holdings across the system per bib record in the results would be ideal. For example, A court of thorns and roses large print edition has 2 copies available at the logged in branch, which show in the location column. There are 27 other copies, which show when clicking on an expand button for that bib in the search results. Clicking the button again collapses the results back to the two at the logged in branch. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 35934] New: Items in transit show as both in-transit and Available on holdings list
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35934 Bug ID: 35934 Summary: Items in transit show as both in-transit and Available on holdings list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 35696 Like bug 35696, this is another missed case where items.transfer should have been switched to transfer in the template. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35696 [Bug 35696] Transit status not properly updated for items advanced in Stock Rotation tool -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 36713] New: Show bibliographic information of deleted records in acquisition invoices
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36713 Bug ID: 36713 Summary: Show bibliographic information of deleted records in acquisition invoices Change sponsored?: --- 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Similar to bug 10758, but for acquisition invoices. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 22322] New: Self-checkin module should provide for automatic logins (like self-checkout)
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '26

07 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22322 Bug ID: 22322 Summary: Self-checkin module should provide for automatic logins (like self-checkout) 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: oliver.behnke(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- The self-checkin (SCI) module currently requires to set up a dedicated kiosk terminal for its purpose. The reason being that you can't provide user/password system preferences for an automatic login, like you can for the self-checkout (SCO) counterpart. Our use case is the following: we are already using the SCO module with automatic login of the dedicated SCO patron, and our actual patrons identify themselves via their cardnumber. While they can obviously check in their books via the SCO module, we'd like to streamline the process such that they don't have to login with their cardnumber in order to simply return a book. The SCI module would be ideal for this but, effectively, it can't be used on the same terminal as switching between the modules currently requires a manual login of the dedicated SCI patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 59

[Bug 37201] New: Add a syspref to allow or not a checkout if a expired booking exists for the same patron
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '26

07 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37201 Bug ID: 37201 Summary: Add a syspref to allow or not a checkout if a expired booking exists for the same patron Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hello :) I've worked on a way to prevent checkout to patron if this same patron has a booking expired for the same item.. I think it's a setting that might not suit everyone, so I've introduced a new system preference. I'll put my patch in place and await your comments. Thanks ^^ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 37363] New: Booking dates should respect closed days
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '26

07 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37363 Bug ID: 37363 Summary: Booking dates should respect closed days Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The bookings datepicker is not aware of open/closed days at present and as such a booking may be made that would expect fulfilment or return on a closed day. We should update the flatpickr to disable such dates for direct selection, but allow spanning them. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 28633] New: Add a preferred_name field and an effective_name method to patrons
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '26

07 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28633 Bug ID: 28633 Summary: Add a preferred_name field and an effective_name method to patrons Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some institutions store legal names in their directories and for patron imports, but would also like to be able to record 'preferred' names in the patro records. It would be nice to have a field for preferred_name and a method to select the preferred name when it exists, and the firstname when it doesn't Following the item we would suggest 'effective_name' - the additional method can be used in patron-title.inc and in notices to simplify name choice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 195

[Bug 40284] New: MARC21: Adjust maxlength for 005, 006 and 007
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '26

07 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40284 Bug ID: 40284 Summary: MARC21: Adjust maxlength for 005, 006 and 007 Change sponsored?: --- Product: Koha Version: Main 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Field 000 (leader) and 008 are controlled with maxlength. This should be since version 3.07.00.037, although my production database somehow did not have 40 for field 008.. We can easily add the same check for 005, 006 and 007. Note that 007 does not always have the same length, depends on position 0. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23