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

[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 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 30557] New: Add ability to create Item lists
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30557 Bug ID: 30557 Summary: Add ability to create Item lists Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This is relevant for multi-branch installations. Lists currently appear to be primarily bibliographic lists. This creates a problem when sorting lists by call number. In this scenario there may be multiple items from different libraries using different call number schema attached to a single bibliographic record. The list cannot be sorted accurately by call number. It would be helpful if there was an option for an item based list. In this scenario items are added to a list for a specific branch. The call number sort will then sort correctly because the call number schema will be consistent for the branch. An item list would display the same information as a bibliographic list with the exception of additional branches which may also have the item. A typical use case would a library creating an item list, sort by call number, and then use that list to go to the shelf to pull the items in order. This is currently not possible in a multi-branch installation without a bit of work. It would require downloading the list and then cleaning up the list to be useful for this kind of work. It may be possible to create a report that will do this, but it would be a nice added functionality in the List tool. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 117

[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 30319] New: Patron self-modification values not retained if field blocked in PatronSelfRegistrationBorrowerUnwantedField
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30319 Bug ID: 30319 Summary: Patron self-modification values not retained if field blocked in PatronSelfRegistrationBorrowerUnwantedField Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When a field is hidden for self-registration, Koha is mistakenly discarding values for that field in self-modification. Somehow these two sysprefs are not being enforced distinctly. To test: 1 - turn on OPACPatronDetails 2 - confirm PatronSelfModificationBorrowerUnwantedField is blank, all fields allowed 3 - set PatronSelfRegistrationBorrowerUnwantedField to hide Title 4 - log into the opac, go to self mod (/cgi-bin/koha/opac-memberentry.pl), set a title (it is not hidden, which is correct), and save your updates 5 - go to the patron modification page in the staff interface (/cgi-bin/koha/members/members-update.pl), confirm your modification request is there but shows no changes 6 - update PatronSelfRegistrationBorrowerUnwantedField to allow title 7 - repeat step 4 8 - your new modification request shows a change to title -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 23817] New: Searching by patron phone number is contingent on how it was entered
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23817 Bug ID: 23817 Summary: Searching by patron phone number is contingent on how it was entered Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If a library chooses to enter their patron phone numbers in as xxx-xxx-xxxx when creating the patron record; then when the phone number is searched with the filters, the library must always use hyphens when searching or the search will not work. It would be nice that the number could be searched in the filters with either hyphens or no hyphens and the library would get the same results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 65

[Bug 17921] New: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17921 Bug ID: 17921 Summary: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Items that shouldn't be displayed in the OPAC are displayed in the shelf browser The links work as expected (redirect to opac-blocked or 404) but we should not display them in the first place -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 26866] New: Items table on additem should sort by cn_sort
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26866 Bug ID: 26866 Summary: Items table on additem should sort by cn_sort Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: - create a bib - add three items with source of classification LCC, call numbers: -- JC43 .G6 1890 -- JC330 .F74 2000 -- JC480 .R63 2006 - on additem.pl, sort the items table by "Full call number" - notice items are order incorrectly, going 330, 43, 480 - use a report to pull the cn_sort values for your 3 items, confirm that ordering by cn_sort in your report correctly orders them 43, 330, 480 We should use cn_sort here to get them in the correct order. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18