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

[Bug 43036] New: Prevent GetItemsForInventory from over-taxing resources
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43036 Bug ID: 43036 Summary: Prevent GetItemsForInventory from over-taxing resources Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 43016 Target Milestone: 26.11 GetItemsForInventory can eat up a lot of resources when called against a large collection. We should improve how we fetch and display this data. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43016 [Bug 43016] [OMNIBUS] Server resource protection -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 23333] New: Course Reserves: Instuctor search box positioning
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23333 Bug ID: 23333 Summary: Course Reserves: Instuctor search box positioning Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: claire_gravely(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 91567 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=91567&action=ed… Screenshot When creating a new course in the course reserves module the "Instructor search" box is oddly positioned. Perhaps it could be moved more in line with 'Instructors'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 8214] Create a bound with function
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8214 Michaela Sieber <michaela.sieber(a)kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clemens.tubach(a)kit.edu, | |katrin.fischer(a)bsz-bw.de, | |michaela.sieber(a)kit.edu -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42945] New: When a waiting hold is filled by another item it should have a status that can be seen in the interface
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42945 Bug ID: 42945 Summary: When a waiting hold is filled by another item it should have a status that can be seen in the interface Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- When a hold is filled by a different item, it can leave another item waiting on the hold shelf, with no way for staff to check. We should add a status to these holds/items that cleared on checkin, and offer a way for staff to view these - on the holds over tab, or somewhere obvious -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 41282] New: We should alert staff when a checked out item fills a different hold for a patron
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41282 Bug ID: 41282 Summary: We should alert staff when a checked out item fills a different hold for a patron Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com When an item is checked out and the patron has a hold on the biblio we will fill thart hold with the item in hand Sometimes the hold this item fills has another copy that is already in transit or waiting on the shelf. We need to alert staff when this happens -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 22456] New: Customers Cancelling their Pending Holds
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22456 Bug ID: 22456 Summary: Customers Cancelling their Pending Holds Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: christofer.zorn(a)ajaxlibrary.ca QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Good morning! I'm not sure if I should have piggybacked this off of the previous ticket, but I'd like to open the discussion on bug 18856 again. We'd like the ability to have patrons cancel their holds once they have been pulled by staff and are awaiting pick up. Our previous catalogue (Bibliocommons) allowed the cancellation of holds once it as captured. This feature was well like and used by our patrons who had determined they didn't need/want the item any longer. This gave the perception that they were freeing up the item for the next person. We have fielded a number of grumpy comments since our migration about the inability to perform this functionality. >From my perspective, if we're allowing patrons to place holds and cancel them before they're captured, we should offer the ability to cancel them up until they're picked up. At the very least, this should be a system option to allow the Library to choose whether they'd like to enable this functionality. Even if the implemented functionality is a placebo for the user ... offer them the ability to cancel the hold and have it remove from their account. As long as optically it appears they've cancelled the hold, there is no harm. If desired, a report could be run to allow staff to pull those items from the shelf if needed. I'm more than happy to elaborate if needed on this, but I feel that this is a feature that is currently missing from Koha that would be a boon to customer service. Thanks Christofer -- You are receiving this mail because: You are watching all bug changes.

1 166

[Bug 39820] New: Items with hold cancellation requests should have the hold cancelled when checked in via SIP
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39820 Bug ID: 39820 Summary: Items with hold cancellation requests should have the hold cancelled when checked in via SIP Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. In circ rules set a Default waiting hold cancellation policy to allow hold cancellation requests. 2. Add a hold for a patron and create a hold cancellation request. 3. Check the item in via SIP, I used the SIP emulator: kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l MPL -su term1 -sp term1 -m checkin --patron 23529000035676 --item 39999000001310 4. The hold remains. In the staff client if I check in an item with a hold cancellation request the hold is cancelled -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 6921] Alert librarian that a waiting reserve has been filled by another item
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6921 Andrii Nugged <nugged(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41809 -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 38650] New: We should only fill title level or specific item holds when a patron checks out an item
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38650 Bug ID: 38650 Summary: We should only fill title level or specific item holds when a patron checks out an item Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Follow up to bug 14549 - we handled the case here to fill a patron's reserve when they get another copy, however, we didn't cover the case where their reserve is title level. To recreate: 1 - Place a hold for patron A on item #1 of a record 2 - Place a hold for patron B on item #2 of a record 3 - Issue item #2 to patron A - their hold on item #1 is filled incorrectly -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 36024] New: Cancellation requests for waiting holds - errors caused by duplicate requests
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36024 Bug ID: 36024 Summary: Cancellation requests for waiting holds - errors caused by duplicate requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The Koha OPAC prevents duplicate waiting hold cancellation requests at the interface level, but if a duplicate request is sent through the API (e.g. from a discovery layer), it is not prevented. This causes the cancellation request to display twice on the Holds With Cancellation Requests table on the staff interface. When the item is checked in, the cancellation request and checkin logic are (at least partially) processed, but the page displays a 500 error, which is confusing to staff and prevents any modals from displaying. To reproduce on KTD: 1. Circulation Rules: add a Default waiting hold cancellation policy of all / all / yes (i.e. cancellation allowed for all patron categories and item types) 2. System preferences: Enable RESTBasicAuth 3. Place a hold and check the item in to set the hold to Waiting 4. In a kshell, send an API hold cancellation request from the command line: curl -u koha:koha --request DELETE 'http://127.0.0.1:8081/api/v1/holds/1' --header "Content-type: application/json" --header "x-koha-override: cancellation-request-flow" (if the hold ID is not 1, change the hold ID at the end of the request path accordingly) 5. Repeat step 4 6. Go to the Holds Waiting page and view the Holds With Cancellation Requests tab --> Note that two identical cancellation requests appear for that hold 7. Check in the item --> Note the error message 8. Confirm that the item state has been modified: --> Hold is gone from the Holds Waiting page --> Hold is gone from the bib record --> Item shows as available on the bib record and last seen date has been updated --> If RecordLocalUseOnReturn is enabled, a local use entry has been added to the statistics table -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8