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

[Bug 42385] New: Extract _GetCircControlBranch into Koha::Policy::Circulation
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42385 Bug ID: 42385 Summary: Extract _GetCircControlBranch into Koha::Policy::Circulation Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 41728 _GetCircControlBranch is a private function in C4::Circulation that is exported (the code itself comments "This is wrong!") and used from Koha::Item, Koha::Recall, and multiple places in C4::Circulation. It resolves which library controls circulation rules given the CircControl and HomeOrHoldingBranch system preferences. This is the exact same pattern as Koha::Policy::Holds->holds_control_library, which resolves the controlling library for hold rules based on ReservesControlBranch. This bug proposes: - Add Koha::Policy::Circulation with a circ_control_library($item, $patron) class method - Replace all _GetCircControlBranch calls with the new method - Remove the exported private function from C4::Circulation - Add unit tests This is a prerequisite for the checkout availability work, as the future Koha::Item::Checkout::Availability class would need to resolve the controlling library. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41728 [Bug 41728] Add `Koha::Item::Checkin::Availability` to centralize logic -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 43

[Bug 43139] New: ILL requests Widget should sort desc to display newest records
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43139 Bug ID: 43139 Summary: ILL requests Widget should sort desc to display newest records 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: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- Test plan: Prerequisites Ensure that there are more than 5 ill requests (borrowing) in the system. Steps to Reproduce Go to koha/ill/home Actual Result The first five records are displayed in the results list, the list is ordered by ID asc Expected Result The newest records should be displayed, list should be ordered by ID desc -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 34756] New: Cancelling a hold does not cancel the related transfer
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34756 Bug ID: 34756 Summary: Cancelling a hold does not cancel the related transfer Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a hold is confirmed and its pickup location is different from the item's location, a transfer is initiated. If the hold is cancelled, the item remains in transfer whereas it is no longer needed at the transfer destination. Is this normal behaviour ? It seems that staff users should at least see a message about the transfer and maybe have the ability to cancel it. Steps to reproduce: 1. Create an item at library A 2. Place a hold on this item with a pickup location at library B 3. Check in the item at library A 4. Confirm the hold. The item should now be in transit to library B 5. Cancel the hold. There is no message about the probably useless transfer. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 42862] New: bookingsModalDatePicker_spec.ts is failing
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42862 Bug ID: 42862 Summary: bookingsModalDatePicker_spec.ts is failing Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The file bookingsModalDatePicker_spec.ts has a test that checks a booking calendar using hardcoded June 2026 dates, faking "today" as 2026-06-01 so those dates look like the future. That fake date is lost when the test reloads the page midway through, so the real date takes over causing it to fail. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 42928] New: In viewlog.tt #actionRETURN should be Retrun, not Check-in
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42928 Bug ID: 42928 Summary: In viewlog.tt #actionRETURN should be Retrun, not Check-in Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 42131 updated the terminology in the table. We should also update the label for the #actionRETURN checkbox to be "Retrun". -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 43846] New: Patron search only matches authorised value codes instead of displayed descriptions
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43846 Bug ID: 43846 Summary: Patron search only matches authorised value codes instead of displayed descriptions Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: gehim+kohabugzilla(a)posteo.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Description When searching for patrons using an extended patron attribute linked to an authorised value category, the search only matches the internal authorised value code instead of the description displayed to staff users. This makes searching confusing, as staff members normally only see and select the description, while the internal code is not readily visible after configuration. Steps to reproduce: Create an authorised value category named SCHOOLCLASS with the following entries: Authorised value - Description 1A - 1a 1B - 1b 99 - Unknown Create a patron attribute type: Code: SCHOOL_CLASS Description: School class Authorised value category: SCHOOLCLASS Edit a patron record and select Unknown as the value for School class. Open the patron search in the staff interface and search using the School class attribute. Search for Unknown. Repeat the search using 99. Actual result: Searching for Unknown returns no matching patrons. Searching for 99 returns the expected patrons. Expected result: Searching for Unknown should return all patrons whose School class attribute displays Unknown. Ideally, searching by either the authorised value code or its description should return matching patrons. Why this is a problem: Staff members select and see the description (Unknown) when editing or viewing patron records. However, the search requires the underlying authorised value code (99), which is not readily visible in normal patron workflows. This behaviour is unintuitive and makes the search difficult to use without knowledge of the internal configuration. Related issue: See also Bug 15337 and Bug 21026 for similar issues involving internal codes versus displayed descriptions in other parts of Koha. Environment: Koha version: 26.05.03 MariaDB version: 11.8.6 Interface: Staff client -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42577] New: Gettext.js incorrectly located and tidied
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42577 Bug ID: 42577 Summary: Gettext.js incorrectly located and tidied Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you look at opac-tmpl/bootstrap/js/Gettext.js or its intranet-tmpl equivalent, you'll notice that it's actually a third-party script and not a Koha script, so it should be in the "lib" folder and the license for it should be added to about.tt We've also tidied the file because it wasn't in "lib"... so we might want to undo that. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 13326] Add possibilty to edit purchase suggestion in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13326 --- Comment #7 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Oh, I see David has already filed the bug: Bug 43845 - Suggestions - Add ability to control deletion of purchase suggestions from a patron's OPAC account -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 13326] Add possibilty to edit purchase suggestion in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13326 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=43845 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43845] New: Suggestions - Add ability to control deletion of purchase suggestions from a patron's OPAC account
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43845 Bug ID: 43845 Summary: Suggestions - Add ability to control deletion of purchase suggestions from a patron's OPAC account Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Some libraries use the MaxTotalSuggestions + NumberOfSuggestionDays system preferences to manage the number of suggestions patrons can submit. However, patrons can delete a suggestion that is rejected using their OPAC account, and then submit a new suggestion. The deleted suggestion is not taken into account for these system preferences. The purpose of this bug is for options to manage patrons ability to delete their own suggestions, to avoid the above scenario. To reproduce (using KTD): 1. Edit a patron's account so you can log into the OPAC as them, for example Mary Burton: - Username: mary - Password/confirm password fields: enter a valid password 2. Log into the OPAC as that patron. 3. From the OPAC make a purchase suggestion: - Search for a term, for example: perl - At the end of the search results, select "Make a purchase suggestion" - Enter the required details: . Title: My suggestion - Click "Submit your suggestion" 4. In the staff interface, change the suggestion status to "Rejected" - Go to the staff interface home page - In the notice saying "Suggestions pending approval", click "All libraries: 1" - Select the suggestion from the list - From the "Mark selected as" dropdown list, select "Rejected" - Submit 5. In the OPAC under Your account > Purchase suggestions - Note that: . The suggestion status is shown as "Suggestion declined" . You can select and delete the selected suggestion . You can add new suggestions (as there is no limit) 6. In the staff interface, set these system preference values: - MaxTotalSuggestions = 1 - NumberOfSuggestionDays = 90 7. Reload/refresh the patron's purchase suggestion page. 8. Note that there is no "New purchase suggestion" link 9. Select and delete the selected suggestion. 10. Now you can make a new purchase suggestion. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2