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

[Bug 27066] New: Implement Hooks for patron's updates
by bugzilla-daemon＠bugs.koha-community.org 22 May '26

22 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27066 Bug ID: 27066 Summary: Implement Hooks for patron's updates Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: eric.begin(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org Some of our clients use external systems to populate Koha's patron information. They can use Koha's API to update patron info, however, we don't have any way (that I know of) to notify an external system when a patron info is changed in Koha. In order to allow bidirectional communications, we are planning to add hooks. This will allow creating plugins to send messages to external systems in order to fulfil the following requirements : - Update patron information stored in the borrowers table (name, address, email, etc.) - Notify an external system when a restriction is placed on a user (fines, manual restrictions, overdues, etc.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 28259] New: Checking at branch B an item in waiting hold state at branch A kill koha
by bugzilla-daemon＠bugs.koha-community.org 22 May '26

22 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28259 Bug ID: 28259 Summary: Checking at branch B an item in waiting hold state at branch A kill koha Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: didier.gautheron(a)biblibre.com Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 21944 To Test: 1) Set HoldsAutoFill 2) double check hold rules are on next available item. 3) At midway check out barcode 39999000010831 to 23529000035676 patron ( Henry Acevedo) 4) hold next available to Ronnie Ballard (23529000139858) 5) check in 39999000010831, item is in waiting hold state 6) At Centerville check in 39999000010831 --> internal server error Regression introduce by Bug 21944 'Improve efficiency of code' patch, item number is lost in reserve table. Root cause for https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27196 ? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21944 [Bug 21944] Fix waiting holds at wrong location bug -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 33738] New: Add bookings to the OPAC
by bugzilla-daemon＠bugs.koha-community.org 22 May '26

22 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33738 Bug ID: 33738 Summary: Add bookings to the OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, testopia(a)bugs.koha-community.org Depends on: 29002 As part of the bookings workflow, we should add support for making bookings from the OPAC as a patron. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29002 [Bug 29002] Add ability to book items ahead of time -- You are receiving this mail because: You are watching all bug changes.

1 50

[Bug 38922] New: auth_header.origincode probably never used -- shouldn't it be removed?
by bugzilla-daemon＠bugs.koha-community.org 22 May '26

22 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38922 Bug ID: 38922 Summary: auth_header.origincode probably never used -- shouldn't it be removed? Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It seems that the column auth_header.origincode is never used in the code. This column exists from the beginning of auth_header table. BTW, a similar column was present also in marc_biblio in ancient times (e.g. in R_2_2_5), but disappeared in 3.00.00. Shouldn't this column be removed? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 48

[Bug 35972] New: Using Course reserves module for Research table reserves
by bugzilla-daemon＠bugs.koha-community.org 22 May '26

22 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35972 Bug ID: 35972 Summary: Using Course reserves module for Research table reserves Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: mirjam.vantieghem(a)etf.edu QA Contact: testopia(a)bugs.koha-community.org Created attachment 161714 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=161714&action=e… Screenshot of example Research tables on OPAC Our library has research tables and lets patrons (mainly master students working on their thesis) keep items for a longer period on these tables. In order for both library staff and patrons to be able to quickly track down items, we are using the Course reserves module to set a certain research table as temporary location for a certain item. Because tables are not courses, we use a custom patch to have the research tables appear as a separate module on the OPAC. We use the authorized value category DEPARTMENT to distinguish courses from tables. The tables have a separate value "Research tables". Because some of the columns used for the course reserves are not relevant for the tables, we also change the display of these on the OPAC. The following columns are renamed: “Course #” => “Table #” “Instructors” => “Researcher” “Notes” => “Topic” And these columns are hidden: “Dept.”, “Section”, “Term”. Notes: 1) Because of possible privacy issues, we are no longer displaying the name of the researcher, so this column might also be hidden. 2) The topic is optional. Some like to see what others are doing research on. It also helps to know where to look for a book on a certain topic if it is not on the shelf, because keeping the 'table reserves' up to date is a bit of a challenge sometimes, depending on the cooperation of the patron. Ideally this should be a separate module on both the Staff client and the OPAC. It might be called 'Table reserves' if 'Research tables' is too specific. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 72

[Bug 32117] New: "Items with no checkouts" report (catalogue_out.pl) broken with SQL strict mode enabled
by bugzilla-daemon＠bugs.koha-community.org 22 May '26

22 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32117 Bug ID: 32117 Summary: "Items with no checkouts" report (catalogue_out.pl) broken with SQL strict mode enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org This report (Reports > Inactive > Items with no checkouts) does not work when the database is in strict mode. Error trace: CGI::Compile::ROOT::kohadevbox_koha_reports_catalogue_out_2epl::calculate(): DBI Exception: DBD::mysql::st execute failed: 'koha_kohadev.items.barcode' isn't in GROUP BY at /kohadevbox/koha/reports/catalogue_out.pl line 51 at /usr/share/perl5/DBIx/Class/Exception.pm line 77 .... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 19690] New: Smart rules: Term "If any unavailable" is confusing and just means No
by bugzilla-daemon＠bugs.koha-community.org 22 May '26

22 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19690 Bug ID: 19690 Summary: Smart rules: Term "If any unavailable" is confusing and just means No Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Pertains to Allow on shelf holds. Triggered by looking at bug 4319. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 39199] New: REST API: Add POST route for updating notices/message queue
by bugzilla-daemon＠bugs.koha-community.org 22 May '26

22 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39199 Bug ID: 39199 Summary: REST API: Add POST route for updating notices/message queue Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com It would be nice to have an 'addNotice' route. This would be useful for libraries that use a 3rd party for sending notices so that those sent notices could be included in the patron notice tab. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 20813] New: Revamp user permissions system
by bugzilla-daemon＠bugs.koha-community.org 22 May '26

22 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20813 Bug ID: 20813 Summary: Revamp user permissions system Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Koha's current user permissions system is a bit convoluted and limited due to it's legacy where the permissions system was a simple set of flags. A second layer of sub-permissions were later added complication and obfuscation to the system. We should revamp the permissions system to be a more modern system and open the path to having unlimited nesting of sub-permissions instead of shoe-horning sub-permissions into the limited system we have. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 100

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

21 May '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 7