January 2022 - Koha-bugs - lists.koha-community.org

[Bug 23269] New: Long hold queues are slowing the service
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23269 Bug ID: 23269 Summary: Long hold queues are slowing the service Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: emmi.takkinen(a)outlook.com QA Contact: testopia(a)bugs.koha-community.org In Finlands public libraries hold queues can be huge due popular records having a lot of holds at the same time. Most popular records may even have over 1000 holds. This leads the service slowing significantly when browsing their holds page. There should be pagination in the holds table for efficient page loading. -- You are receiving this mail because: You are watching all bug changes.

1 124

[Bug 19838] New: Add system preference for adding text to self registration form
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '26

03 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19838 Bug ID: 19838 Summary: Add system preference for adding text to self registration form 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Some libraries would like to add some explanations to the self registration form. At the moment there is only a system preference for the page that shows after submitting the registration form. It would be helpful to have another that shows on the self registration form itself. -- You are receiving this mail because: You are watching all bug changes.

1 53

[Bug 21052] New: New patron card printer profile won't save if paper bin is empty
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '26

03 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21052 Bug ID: 21052 Summary: New patron card printer profile won't save if paper bin is empty Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When adding a new printer profile in the patron card creator tool, you can save without entering a paper bin, but it will not create a new entry in the database. There is no error, the field is not marked as required. To test: - Add a new printer profile - Fill in description, leave other fields unchanged - Save - Verify that the new printer profile doesn't appear in the list and hasn't been created -- You are receiving this mail because: You are watching all bug changes.

1 38

[Bug 23894] New: accountlines.payment_type and accountlines.credit_type should be merged
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '26

03 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23894 Bug ID: 23894 Summary: accountlines.payment_type and accountlines.credit_type should be merged 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com During the implementation of bug 23805 and bug 23049 it became apparent to me that the introduction of payment_type appeared to be a workaround for the lack of distinct credit and debit categories. Now we have a distinct credit_type field in accountlines which is properly governed by foreign key relationships I believe we could merge the payment_type field with this credit_type field and expose a purpose build UI for managing such types. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 27340] New: We should introduce Koha::PickupLocation(s)
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '26

03 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27340 Bug ID: 27340 Summary: We should introduce Koha::PickupLocation(s) 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Looking at the codebase, a pickup location is a combination of a branch/library, and now also a 'desk'. So it would make sense to have a special class for them. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 24067] New: Refactor REST API allow-owner authorization logic
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '26

03 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24067 Bug ID: 24067 Summary: Refactor REST API allow-owner authorization logic Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi It is possible to authorize patron an access to their own resources by defining "allow-owner" under x-koha-authorization block in endpoint's OpenAPI specification. Currently the logic for this type of authorization is centralized under Koha::REST::V1::Auth::check_object_ownership with some messy, hard to understand and possibly at some point in future even insecure logic. A better and more flexible solution is to have each REST API controller handle the "allow-owner" authorization on their own. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[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 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 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