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

[Bug 39879] New: Add 'localuse' transactions to pseudonymization
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39879 Bug ID: 39879 Summary: Add 'localuse' transactions to pseudonymization Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: sspohn(a)oslri.net QA Contact: testopia(a)bugs.koha-community.org Currently, it appears that pseudonymization only captures checkouts, renewals and returns. I'd like to suggest that 'localuse' transactions be captured as well. Since pseudonymization is a pathway to retaining anonymized data on a journey to patron privacy which would include using the clean-up cron, we'd want to be sure not to lose this data. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 37334] New: Cannot order/sort holdings table by status
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37334 Bug ID: 37334 Summary: Cannot order/sort holdings table by status Change sponsored?: --- 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently one is not able to sort the holdings table by status. IN catalogue_detail.inc I see the following: 451 data: "me.lost_status", 452 className: "status", 453 searchable: false, // FIXME We are losing the ability to search on the status 454 orderable: false, 455 render: function (data, type, row, meta) { Setting orderable to true brings back the icons, but I am assuming since this wasn't fixed initially that it is not trivial. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 388

[Bug 36920] New: Greater/less than search option on item search page to Barcode-drop-down menu
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36920 Bug ID: 36920 Summary: Greater/less than search option on item search page to Barcode-drop-down menu Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: tuomas.kunttu(a)kouvola.fi QA Contact: testopia(a)bugs.koha-community.org Created attachment 167017 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167017&action=e… Barcode search section on item search page In the search section on the item search page, where the drop-down menu has a barcode search by default (see attachment image), it would be useful to have the option to do greater/less than searches as well. Now there are only is/is not options. When searching publication year in this menu, this functionality would be useful. This way you could search for works that have been published before/after a certain year. In addition, custom search fields can be added to the menu. These can be, for example, acquisition date or lastseen date. Also with these fields greater/less than searches would be useful. In fields containing letters, greater/less than searches are not necessarily very useful, but not harmful either. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 41126] New: Move shelving location into a separate column in inventory
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41126 Bug ID: 41126 Summary: Move shelving location into a separate column in inventory Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org For consistency with other similar displays I think we should add a separate column for shelving location in the inventory results table. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 41131] New: Branch Transfer Limits basic editor allows one to prevent transfers from a library to itself and block related holds
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41131 Bug ID: 41131 Summary: Branch Transfer Limits basic editor allows one to prevent transfers from a library to itself and block related holds 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The branch transfer limits basic editor will always indicate that transfers from a branch to itself are allowed -- when the page loads, it always puts a checkmark under "Allow transfer" for the branch for which one is defining limits. But this checkmark is not reflected in the database. To recreate: - disable AllowHoldPolicyOverride - set UseBranchTransferLimits to Enforce; set BranchTransferLimitsType to itemtype (the also exists when enforcing by collection code, but its impact on holds is easier to see with itemtypes) - go to the branch transfer limits page, see that Allow Transfers is checked for all branches and all itemtypes - in a report, SELECT * FROM branch_transfer_limits, confirm no results -- we put a row in this table for every transfer that's blocked - back on the branch transfer limits, uncheck "Allow transfer" for Books going from Centerville to Centerville, click Save - On save, the page reloads and shows a checkmark under "Allow transfer" for Books going from Centerville to Centerville - back in reports, run your query again, see there is a row in branch_transfer_limits to block the transfer of Books from Centerville to Centerville - Attempt to place a hold on an item currently at Centerville for pickup at Centerville, confirm Koha will not allow this hold This cannot be recreated in the advanced editor. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 41097] New: Deduping authorities script (dedup_authorities.pl) can die on duplicated ids
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41097 Bug ID: 41097 Summary: Deduping authorities script (dedup_authorities.pl) can die on duplicated ids Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When running the script it seems to generate duplicate ids: Processing authority 1660 (531/650 81.69%) Merging 1660,1662 into 1660. Updated 0 biblios Deleting 1662 Merge done. This seems to be a product of _choose_records which gets all the candidates, but then adds the original record twice 318 my @records = map { C4::AuthoritiesMarc::GetAuthority($_) } @recordids; 319 my @candidate_auths = @records; and later: $choose_subs[2] ? $choose_subs[2]->($_) : 0 ] => ( $records[0], @candidate_auths ); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 40711] New: Fix valuebuilder for 181 and 182 in UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40711 Bug ID: 40711 Summary: Fix valuebuilder for 181 and 182 in UNIMARC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl There are some little issues with valuebuilder that need a fix -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 39749] New: RestrictPatronsWithFailedNotices should not trigger for DUPLICATE_MESSAGE failures
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39749 Bug ID: 39749 Summary: RestrictPatronsWithFailedNotices should not trigger for DUPLICATE_MESSAGE failures Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Koha is built to prevent sending duplicate notices. Notices with static language ( e.g. "You have one or more holds ready to pick up" ) will easily trigger this filter. RestrictPatronsWithFailedNotices should ignore these notices because they do not indicate any problem with contacting the patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 28528] New: bulkmarcimport delete option doesn't delete biblio_metadata
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28528 Bug ID: 28528 Summary: bulkmarcimport delete option doesn't delete biblio_metadata Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When using bulkmarcimport with the -d switch should not only delete biblio, biblioitems and items, but also biblio_metadata. I haven't checked if a FK takes care of the data, but if it does, we should still also reset the AUTO_INCREMENT: https://git.koha-community.org/Koha-community/Koha/src/branch/master/misc/m… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 31795] New: REST API: POST endpoint for Authorities
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31795 Bug ID: 31795 Summary: REST API: POST endpoint for Authorities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44