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

[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

[Bug 5276] subscription end date shouldn't be required / allow indefinite subscriptions
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5276 Adam Harris <aharris(a)capecod.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aharris(a)capecod.edu -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41512] New: ILLCheckAvailability stage table doesn't render
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41512 Bug ID: 41512 Summary: ILLCheckAvailability stage table doesn't render Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[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