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

[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 34000] Don't allow auto-generated cardnumbers to be re-used, it may give access of services to the next patron created
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34000 Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|release-notes-needed | Text to go in the| |This bug prevents release notes| |cardnumber re-use by | |implementing a centralised | |counter for AutoMemberNum. -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 koha-US bug tracker <bugzilla(a)koha-us.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla(a)koha-us.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 42767] New: ERM eUsage Data Providers Import Logs uses contains match for usage_data_provider_id
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42767 Bug ID: 42767 Summary: ERM eUsage Data Providers Import Logs uses contains match for usage_data_provider_id Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk This should be an exact match, currently we see results for ids 1,10,14 when searching for provider 1 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2244] RFID Cataloguing - Programming RFID tags from Koha
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2244 Myranda Fuentes <myranda.fuentes(a)groveforlibraries.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |myranda.fuentes@groveforlib | |raries.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 42765] New: Add pagination to the checkouts table
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42765 Bug ID: 42765 Summary: Add pagination to the checkouts table Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The checkouts table on circulation.pl and moremember.pl works fine for most patrons, but causes issues for patrons with hundreds of checkouts, especially if the table is set to load automatically. In practice, we've seen a patron with 200ish checkouts take about 10 seconds to load the table. If the patron is then checking out another stack of items ( let's say 20 ) it's possible to lock up the entire server. This happens because those svc/checkouts continue to stack up and use up workers. A fast enough librarian will be able to get to the point where most if not all workers are calling svc/checkouts. If it takes 10 seconds to resolve the api call, and 3 seconds to check out an item, the process will plateau at 4 workers being dedicated to just calling svc/checkouts for just that patron. Setting LoadCheckoutsTableDelay to a non-zero value works around the symptom, since the next scan's page reload cancels the pending request before it fires, but the real fix is to make the table server-side so it only fetches the recent subset of checkouts by default. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1