December 2025 - Koha-bugs - lists.koha-community.org

[Bug 34874] New: Patron card creator: When creating a new batch, input box and label overlap
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34874 Bug ID: 34874 Summary: Patron card creator: When creating a new batch, input box and label overlap Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: oleonard(a)myacpl.org When creating a new patron card batch, the label of the input box for cardnumbers overlaps with the input box itself. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 34777] New: koha-restore could use a db-only option
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34777 Bug ID: 34777 Summary: koha-restore could use a db-only option Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz It might be nice for some users to have a koha-restore that doesn't try to restore everything in /var/lib/koha and /etc/koha/ and only does the database. While I realise that it is very easy to zcat backup.sql | sudo koha-mysql site, it's an elegant thing to wrap that in koha-restore as an option. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 36558] New: The placement of the Select button in Search for patron pop up window (while adding a guarantor)
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36558 Bug ID: 36558 Summary: The placement of the Select button in Search for patron pop up window (while adding a guarantor) Change sponsored?: --- Product: Koha Version: 22.11 Hardware: PC OS: Windows Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: irina.halminen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org Created attachment 164570 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=164570&action=e… Screenshot of the search results showing the Select button When searching for a guarantor in the Search for patron pop up window the Select (a patron) button is on the far right. Depending on the screen resolution/browser zoom level, the button is some cases out of view (requires scrolling to the right). If it was moved to the far left (before the Card column), there wouldn't be issues with different displays or browser zoom levels, and it would be more accessible to use. Url: cgi-bin/koha/members/search.pl?columns=cardnumber,name,category,branch,dateofbirth,address-library,action The information shown in the screenshot is from an anonymized version of Koha. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 36893] New: Shibboleth Login not honouring branch selector
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36893 Bug ID: 36893 Summary: Shibboleth Login not honouring branch selector Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: ryan.henderson(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org A client of ours has recently installed Shibboleth SSO into their staff client. They have asked us to help honour the branch selector on the staff login screen but Shibboleth is ignoring this from what we can see and is only logging staff into their default branches. We think this would be a nice enhancement to the authentication module, to help people login to their requested branches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 40307] New: Use GET in form of value_builder/unimarc_field_210c.tt
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40307 Bug ID: 40307 Summary: Use GET in form of value_builder/unimarc_field_210c.tt Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Since CSRF procetion form without CUD action must use GET instead of POST Fix value_builder/unimarc_field_210c.tt -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 30303] New: Add ability to select which values to retain when merging patrons
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30303 Bug ID: 30303 Summary: Add ability to select which values to retain when merging 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When merging two patron records, one simply picks one record to retain values from. It would be helpful to have an interface more like what we see when merging biblio records, where one can select values from either pre-merge record to be retained post-merge. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 61

[Bug 28530] New: Allow configuration of floating limits by item type
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28530 Bug ID: 28530 Summary: Allow configuration of floating limits by item type 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When return policy is set to Item Floats, it's possible for patron usage patterns to result in an imbalance in the collection -- more DVDs end up at Branch A and more books at Branch B. This can be especially troublesome when a given branch has limited shelving for a specific item type. I'd like to see a mechanism by which libraries can define a maximum count of items per item type to be allowed to float at a given branch. So, following my example above, Branch A could say that DVDs float when checked in but only up to 1000 items. If a DVD is checked in at Branch A and would be the 1001st DVD there, it instead transfers away. When some DVDs get checked out or transferred away, new returns will again be allowed to remain at Branch A. Setting the float limit to zero for a given item type and branch would make that item type always transfer away from that branch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 242

[Bug 40518] New: Add examples of leader fields to Advanced Editor section
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40518 Bug ID: 40518 Summary: Add examples of leader fields to Advanced Editor section Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: philip.orr(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de In the Koha Manual, for Macros in the Advanced Editor in this section: https://koha-community.org/manual/latest/en/html/cataloging.html#advanced-e… All the examples show updating specific subfields, so you have to just guess that you can update the contents of a control field (MARC 00x$) by just leaving out the subfield codes. (Like 000$, 001$... etc.) We should add an example of one of these leader fields. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 40856] New: Improve Standard backend metadata retrieval
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40856 Bug ID: 40856 Summary: Improve Standard backend metadata retrieval Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com The metadata() method in the Standard ILL backend uses an inefficient pattern for filtering attributes, performing a linear search through an ignore list for every attribute using grep inside a while loop. This approach becomes increasingly slow as the number of attributes grows, and manually iterates through all attributes instead of leveraging database-level filtering. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 40855] New: Standard backend uses plain SQL
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40855 Bug ID: 40855 Summary: Standard backend uses plain SQL Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com The edititem() method in the Standard ILL backend uses raw SQL queries with manual delete-all-and-recreate patterns instead of leveraging Koha's ORM. This approach creates several problems: it bypasses ORM validation and relationships, uses inefficient delete-all-then-insert operations that update unchanged attributes, includes complex conditional SQL based on column existence checks [1], and makes the code harder to maintain and debug. The method contains over 40 lines of raw SQL that could be replaced with a single call to add_or_update_attributes() (from bug 40850), which would be more efficient (only updating changed values), safer (using ORM validation), more maintainable (no raw SQL). [1] For backwards compatibility with older Koha versions? Inherited from the time it was an external backend. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17