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

[Bug 41869] New: Change /holds POST and PATCH permission to place_holds
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '26

03 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41869 Bug ID: 41869 Summary: Change /holds POST and PATCH permission to place_holds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: johanna.raisa(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com At the moment librarians with place_holds permission can add and modify holds on request.pl page. This is not possible via REST API, the POST and PATCH endpoints need reserveforothers permission to work. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 30221] New: Make the tables on opac-user.tt column configurable
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '26

03 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30221 Bug ID: 30221 Summary: Make the tables on opac-user.tt column configurable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org There are several tables on opac-user.tt that would benefit from being column configurable. ( check-outs, overdues, charges, holds, article requests ) -- You are receiving this mail because: You are watching all bug changes.

1 103

[Bug 28071] New: Ability to batch remove titles from a list
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '26

03 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28071 Bug ID: 28071 Summary: Ability to batch remove titles from a list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Sometimes, lists can have a quite large number of titles. With the export option, it's easy to work on this corpus, and, sometimes, find some titles we finally don't want in that list. If they are numerous, it's for now quite painful to find and delete them. A useful option could be, as it exists with the button "Add items", to be able to remove several titles at a time using barcode or biblionumber. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 23728] New: Rounding code should be moved to a Koha module so code can be centralised
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '26

03 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23728 Bug ID: 23728 Summary: Rounding code should be moved to a Koha module so code can be centralised Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When OrderPriceRounding was added the code was all Acquisitions related. Bug 17140 faces a similar issue. Ideally the code would be available in a Koha module for reuse in all areas involving funds. It would also allow for specifiying different rounds for diferent vendors which is needed by some -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 42164] New: Add bibliographic search via database (maybe to replace Zebra)
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '26

03 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42164 Bug ID: 42164 Summary: Add bibliographic search via database (maybe to replace Zebra) Initiative type: --- Sponsorship --- status: 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: mark(a)hofstetter.at QA Contact: testopia(a)bugs.koha-community.org create a prototype "to search" for bibliographic records using only the database search is implemented here https://github.com/HKS3/koha-nm2db-keyword-search using (which has to be installed first!) https://github.com/HKS3/koha-normalize-marc2db work in progress / prove of concept -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 16631] New: Show groups/categories of reports to authorized staff
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '26

03 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16631 Bug ID: 16631 Summary: Show groups/categories of reports to authorized staff Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be helpful to have reports that are specific groups/categories to be authorized under the reports permissions in a patron account. Not everyone wants to see everyone else's reports, some are similar but are not. Some are for superlibrarians to test, and are not ready for use. It would be great if we could specify groups and even subgroups in the permissions that the staff could access, or specify all groups. All groups should be the norm for a superlibrarian. Christopher -- You are receiving this mail because: You are watching all bug changes.

1 301

[Bug 42621] New: Extend report limitations by library to use library groups
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '26

03 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42621 Bug ID: 42621 Summary: Extend report limitations by library to use library groups Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Depends on: 16631 Bug 16631 implements limitations on report access based on library. We'd like to make that also work with library groups. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16631 [Bug 16631] Limit listing of reports using patron library -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 173

[Bug 42559] New: OpacFavicon double-encodes custom favicon URLs
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42559 Bug ID: 42559 Summary: OpacFavicon double-encodes custom favicon URLs Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The OpacFavicon system preference is documented as accepting a complete URL to an image for the OPAC favicon. However, the OPAC template outputs the value using the url filter. If the URL contains an already-encoded character, such as %20 for a space in a filename, the % is encoded again and the rendered URL becomes %2520. This causes the browser to request an invalid favicon URL. The staff interface does not have this issue because IntranetFavicon is output with the html filter instead. The OPAC should handle custom favicon URLs consistently with the staff client. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 39909] New: Batch modification with regex does not work with control fields
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39909 Bug ID: 39909 Summary: Batch modification with regex does not work with control fields 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: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In MARC modification templates if you define a copy of a control field into another control field. The regexp part does not work. Because of : https://git.koha-community.org/Koha-community/Koha/src/commit/83f8ba4eeed5c… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 28205] New: Less important hold trapped before or no hold trapped in some cases (race condition)
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28205 Bug ID: 28205 Summary: Less important hold trapped before or no hold trapped in some cases (race condition) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com So our libraries ran into a strange hold problem which turned out to be a race condition: if you change priority of holds and return an item and build_holds_queue.pl cron is not yet run again the priority is not updated and you fill hold with less importance! After build_holds_queue.pl the priorities are OK because hold_fill_targets gets updated according to the right hold priority. Similar race condition also happens when you have already some items for the biblio in hold_fill_targets and add a new item to the biblio and try to return it it doesn't attach to any waiting holds until the build_holds_queue.pl is ran. To better understand the issue I think it is easier to look the code in C4::Reserves::_Findgroupreserve(). Explaining with words is bit difficult... Basically in that function the SQL selects > my $title_level_target_query = qq{ > my $query = qq{ should be UNION'ed to fix the case when adding new item which could potentially fill the hold. This might cause unoptimal logistic route to be used but still would follow the hold priority. To fix the issue of changing hold priorities we need to update hold_fill_targets table by calling C4::HoldsQueue::CreateQueue() every time staff member updates hold priorities in a biblio. But even with these improvements wouldn't this be buggy when deleting items from the biblio record? Not sure how to solve that case. Added major bug priority for this but if you feel like it doesn't deserve it feel free to change to normal. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3