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

[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 42559] New: OpacFavicon double-encodes custom favicon URLs
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '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 12

[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

[Bug 33092] New: Add ability to search within a list
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33092 Bug ID: 33092 Summary: Add ability to search within a list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be really helpful to be able to search within a list in both the OPAC and the staff interface. For instance, in both the staff interface, if you are viewing a public list with a lot of items on it, you do not have the ability to see if a specific item appears on the list. This is a needed functionality with larger lists. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 18062] New: Damaged Status shows unavilable in results
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18062 Bug ID: 18062 Summary: Damaged Status shows unavilable in results Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When performing a search in the OPAC or staff client and the results include an item that is marked "Damaged" the status shows unavailable on the results page. When you view the detailed view of the record, the item appears as available. Although the item can still be checked out, it is confusing for the patron when they see the unavailable status. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 39417] New: Allow for editing/deletion of default SUGGEST_STATUS authorized values
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39417 Bug ID: 39417 Summary: Allow for editing/deletion of default SUGGEST_STATUS authorized values Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: heather(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are libraries who do not use the default SUGGEST_STATUS authorized values for indicating the status of a purchase suggestion in the staff interface/OPAC. For example, libraries would rather use terminology like "Declined" as opposed to "Rejected". While it is possible to add more authorized values to this auth value category, it would be nice if those default values could be Edited or Deleted by staff, if desired. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 43354] New: ILL request table search returns a 500 error
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43354 Bug ID: 43354 Summary: ILL request table search returns a 500 error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 33544 Target Milestone: --- The global Search field above the ILL requests table returns a 500 error after the request detail fields were combined into one display column. Steps to reproduce: 1. Enable the ILLModule system preference. 2. Open a patron record. 3. Click "ILL requests history" in the menu on the left. 4. Enter any text in the Search field above the table. Expected result: The table is filtered without an error. Actual result: Koha displays a 500 Internal Server Error and the table does not refresh. Technical note: The combined Request details column has an empty DataTables data source and no related-object search mapping. Global search therefore generates a query for "me." instead of the ILL request extended attributes. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33544 [Bug 33544] Squash some ILL fields to alleviate request table overflow -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 43259] New: Add to group does not add to group
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43259 Bug ID: 43259 Summary: Add to group does not add to group Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Steps to reproduce: 1 - Create a basket 2 - Create a group basket. At this step or the process : /cgi-bin/koha/acqui/basketgroup.pl clicking on "Add to group" does not add the basket to the group It is broken since 25.11.00. In 24.11, in basketgroups.tt there was an array named "grouped", to which the row containing the chosen element was added. It was created using : grouped = $("#grouped").DataTable($.extend(true, {}, dataTablesDefaults, { and row was added using grouped.row.add( row ).draw(); On main : $("#grouped").kohaTable(dt_params); row is added the same way : grouped.row.add( row ).draw(); This results in a JS error : "Uncaught TypeError: grouped.row is not a function" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10