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

[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

[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 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 40650] New: Identity providers lack support for extended patron attribute type mapping
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40650 Bug ID: 40650 Summary: Identity providers lack support for extended patron attribute type mapping Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: oliver.behnke(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Hi, so far we've been using LDAP authentication and with extended attribute type mapping (on register and login/update) but we have to move to OIDC. Thankfully there's an identity provider (IdP) for that. Great! However, testing and code inspection indicate that extended patron attributes can't be used for IdP mapping. When I try that I get: > There was an error authenticating to external identity provider > No property <ATTRIBUTE> for Koha::Patron At first glance, the code seems to support that assessment. For instance, the "update_on_auth" feature [1] calls set() which isn't overridden in Koha::Patron so Koha::Object.set() is being called [2], which of course isn't aware of those patron-specific extended attributes, eventually triggering the error above. To me that omission is a regression as existing auth methods like LDAP do support mapping extended patron attributes. Without that we can't rely on using identity providers since we'd lose required functionality. Thanks [1] https://github.com/Koha-Community/Koha/blob/8d31c2e06733fbc0f599ea99fe46df5… [2] https://github.com/Koha-Community/Koha/blob/8d31c2e06733fbc0f599ea99fe46df5… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[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 39589] New: Search returns 'No results found' despite existing matching records
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39589 Bug ID: 39589 Summary: Search returns 'No results found' despite existing matching records Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org This issue occurs when the records on the first page of results are not displayed. The message "No results found" is shown, and it is not possible to access records on other pages. To test 1. Set the following system preferences: OPACnumSearchResults to 5 OpacHiddenItemsHidesRecord to Hide OpacHiddenItems to withdrawn: [1] 2. Create 6 bibliographic records with the following titles: "notice test 1" "notice test 2" "notice test 3" "notice test 4" "notice test 5" "notice test 6" 3. For the first 5 records, add an item with Withdrawn status. 4. For "notice test 6", add an item with Available status. 5. In the OPAC interface, search for "notice test". ---> The message "No results found!" appears, and "notice test 6" is not visible. -- You are receiving this mail because: You are watching all bug changes.

1 66