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

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

[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 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 35573] New: Koha is no correctly warning of overridden items when placing a hold if AllowHoldPolicyOverride
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35573 Bug ID: 35573 Summary: Koha is no correctly warning of overridden items when placing a hold if AllowHoldPolicyOverride 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If AllowHoldPolicyOverride is enabled we are not warning that items require override if there are valid pickup locations. Regressions caused by (me on) bug 30687 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 42999] New: $valid_items flag contamination in reserve/request.pl causes non-holdable items to appear as available after the first holdable item in the loop
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42999 Bug ID: 42999 Summary: $valid_items flag contamination in reserve/request.pl causes non-holdable items to appear as available after the first holdable item in the loop Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- Bug 38412 (commit 1900effc9b) introduced $valid_items as a flag to track whether any item passes all availability conditions. However, the flag is also used as a per-item gate in the same loop without being reset between iterations. Once any item sets $valid_items = 1, all subsequent items — regardless of their individual availability — enter the if ($valid_items) branch and are assigned $item->{available} = 1. Root cause (reserve/request.pl): The commit split what was a single if block into two consecutive, separate blocks: # Line 455 — initialized once, outside the loop my $valid_items = 0; for my $item_object (@items) { ... # Block 1 (line 570): per-item condition check if ( !$item->{cantreserve} && !$exceeded_maxreserves && $can_item_be_reserved eq 'OK' && IsAvailableForItemLevelRequest( $item_object, $patron, undef ) ) { $valid_items = 1; # set but never reset between iterations } # Block 2 (line 583): uses $valid_items as per-item gate — BUG if ($valid_items) { # true for ALL items after the first valid one $num_items_available++; $item->{available} = 1; ... } elsif ( C4::Context->preference('AllowHoldPolicyOverride') ) { ... } else { $item->{available} = 0; # never reached after first valid item } } # Line 661 — post-loop: this use of $valid_items is correct if ( $valid_items == 0 ) { $template->param( none_available_override => 1 ); } The variable serves two conflicting roles: Global accumulator (correct, line 661): "did any item pass all checks?" Per-item gate (incorrect, line 583): "does this item pass all checks?" — but it carries over from previous iterations. Steps to reproduce: Create a biblio with at least two items: one with a holdable item type (e.g. Books) and one with a not-for-loan item type (e.g. Reference, itemtypes.notforloan = 1). The not-for-loan item must have a higher itemnumber than at least one holdable item (i.e., it is processed later in the loop). Open the place-hold staff form: reserve/request.pl?biblionumber=X&borrowernumber=Y Expected: The not-for-loan item shows no radio button / is not selectable for holds. Actual: The not-for-loan item has a radio button and available = 1, despite the Information column correctly showing "Not for loan (Itemtype not for loan)". This is reproducible with AllowHoldPolicyOverride either on or off. Diagnostic trace on a local instance running main (as of 2026-07-06, biblionumber 47160, patron borrowernumber 2): AllowHoldPolicyOverride: NO itemno barcode itype ifl can_reserve cond_passes valid_items available branch_taken --------------------------------------------------------------------------------------------------- 27924 FFL24040002 BK 0 OK YES 0->1 1 if($valid_items) 27926 CPL24040004 BK 0 OK YES 1->1 1 if($valid_items) 27936 CPL24050001 BK 0 OK YES 1->1 1 if($valid_items) 28043 CPL24110003 REF 1 OK NO 1->1 1 if($valid_items) <-- BUG 28046 CPL25030002 BK 0 OK YES 1->1 1 if($valid_items) ... Legend: ifl = itemtype notforloan flag cond_passes = item individually passes all availability conditions valid_items = flag value before->after this iteration <-- BUG = actual result differs from correct result Note: in this test case CanItemBeReserved returns OK for the REF item (depending on circulation rules, it may also return notforloan); either way, IsAvailableForItemLevelRequest returns false due to the itemtype flag, so cond_passes = NO. The bug manifests regardless. Proposed fix: Merge the two if blocks back into one, so the pickup-location logic and $item->{available} assignment only execute when the current item individually passes all conditions. The global $valid_items accumulator for the post-loop check at line 661 is preserved: if ( !$item->{cantreserve} && !$exceeded_maxreserves && $can_item_be_reserved eq 'OK' && IsAvailableForItemLevelRequest( $item_object, $patron, undef ) ) { $valid_items = 1; my $pickup_locations = $item_object->pickup_locations( { patron => $patron } ); $item->{pickup_locations_count} = $pickup_locations->count; if ( $item->{pickup_locations_count} > 0 || C4::Context->preference('AllowHoldPolicyOverride') ) { $num_items_available++; $item->{available} = 1; ... } else { $item->{available} = 0; $item->{not_holdable} = "no_valid_pickup_location"; } } elsif ( C4::Context->preference('AllowHoldPolicyOverride') ) { ... } else { $item->{available} = 0; } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 42074] New: [Omnibus] Migrate auth mechanisms to Identity Providers
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42074 Bug ID: 42074 Summary: [Omnibus] Migrate auth mechanisms to Identity Providers Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Depends on: 24880, 39924, 40596, 41908 Blocks: 37248 We've been working on improvements to the Identity Providers management interface; We should migrate existing authentication mechanisms to this UI and synchronise the feature sets. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37248 [Bug 37248] [Omnibus] Power to the user https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39924 [Bug 39924] Improve language search option in advanced search https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40596 [Bug 40596] Migrate CAS configuration into Identity Providers https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41908 [Bug 41908] Migrate LDAP configuration into Identity Providers -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 33538] New: Allow for independent shibboleth autocreate and sync mapping
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33538 Bug ID: 33538 Summary: Allow for independent shibboleth autocreate and sync mapping Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: pgsengstock(a)wisc.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Shibboleth auth's autocreate and sync functions both rely on the same //shibboleth/mapping block in koha-conf.xml. Because autocreate requires mapping and/or defaults for branchcode and categorycode, this has the undesired affect of overwriting manual edits to borrowers on later syncs if the those fields are not delivered via shibboleth and explicitly mapped. Example: 1) Patron signs in for first time and borrower account is autocreated with a default branch and categorycode. 2) Staff update patron to set new branch and category codes as needed (e.g. from "SSOAUTH" to "MAINLIB"). 3) On next sign-in, patron's mapped data is synced, but branch and category codes are overwritten with the defaults. Suggested workaround is to differentiate //shibboleth/autocreatemapping vs //shibboleth/syncmapping. This allows greater control over which fields are mapped for autocreate vs sync. This schema change would not be backward compatible, though. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 75

[Bug 39818] New: Add TT notices to serial issues claim
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39818 Bug ID: 39818 Summary: Add TT notices to serial issues claim Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org It would be great to be able to use TT syntax in notices to claim serial issues. It seems that there is no community default for this module, but librarians can create their one by going to Tools > Notices and slips > New notice and selecting the module "Claim serial issue". It looks like the serial list is not available in TT in this notices. Currently, it is inserted with the help of <item></items> For example : <item><<biblio.title>><<serial.serialseq>></item> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2