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

[Bug 28527] New: Transfers that are cancelled whilst in transit should still appear as 'in transit' until they are received
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Bug ID: 28527 Summary: Transfers that are cancelled whilst in transit should still appear as 'in transit' until they are received Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a transfer is cancelled whilst it is in transit (datesent set, but datearrived not) then we should still return it as in transit. Bug 27993 added a condition to the 'in_transit' boolean which should be reverted. We should also update the get_transfer (and get_transfers) methods to catch such cases and return those still active transfers and deal with them appropriately at check-in. (i.e. invoke the reverse transfer or pick the next transfer from the queue and notify the librarian of what subsequent actions they should take). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 33302] New: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33302 Bug ID: 33302 Summary: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com, tomascohen(a)gmail.com A bit much to put in the description, but the problem is about item level holds failing to be placed silently in the OPAC. To test: With the sample data in ktd or sandboxes: 1) Enforce library transfer limits (UseBranchTransferLimits) on itemtypes (BranchTransferLimitsType). 2) In administration > branch transfer rules: disallow transfer from Midway to any other library for item type BK (Books) 3) Search for a record with at least one item in Midway in staff 4) Try to place an item level hold on a Midway item. I used: Intermediate Perl, biblionumber 126 For the Midway item, only Midway will show as possible pickup-location This is correct. 5) Switch to the OPAC 6) Try to place an item level hold there on the Midway item, for pick-up at Centerville. 7) Place a hold on the Midway item for pick-up at any non-Midway location 8) Verify the page saves without error, but the hold was not placed. - The basic issue here is that item specific pickup locations != record-specific pickup locations. In the staff interface we have a separate pull down "allowed pick-up locations" for each item in the list. I think we should implement the same in the OPAC to help the users see what is allowed and what not. And deacticate the pull down on top when an item is selected. But: At least we should give proper feedback that a hold could not be placed because of the pick-up location instead of failing silently! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 33179] New: Allow for libraries to automatically suppress a bibliographic record from OPAC if no items are attached
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33179 Bug ID: 33179 Summary: Allow for libraries to automatically suppress a bibliographic record from OPAC if no items are attached Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice for Koha to allow libraries to automatically suppress a bibliographic record from OPAC if no items are attached. Currently, the library would need to manually add a 942$n = 1 to suppress records. But if the record has no items and can automatically be suppressed until items are attached, this would be a nice efficient workflow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 30777] New: stockrotationitems table could store additional information
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '26

12 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30777 Bug ID: 30777 Summary: stockrotationitems table could store additional information Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be very helpful if stockrotationitems had more information, especially when it was added to the rota. It might also be helpful to have when the last time it was moved by the stock rotation cron. If we could also have the remaining duration that would be great, but I also think would be trickier. Lisette -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 40393] New: Stock Rotation: Items returned to unexpected branch after ownership change do not trigger correct transfer
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '26

12 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40393 Bug ID: 40393 Summary: Stock Rotation: Items returned to unexpected branch after ownership change do not trigger correct transfer Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: michael.adamyk(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When the stock rotation cronjob updates an item's owning library and creates a pending transfer, Koha doesn't properly handle cases where the item is checked out or waiting on a holdshelf when the cron runs to change the branch, and then the item is checked in at a different branch than the one listed in branchtransfers.frombranch. When checked in at an unexpected branch, Koha doesn't prompt a transfer at all, which leaves an open transfer request that staff are unaware of. If the item is checked in a second time, Koha will properly prompt the transfer. Steps to reproduce: 1. Set up stock rotation and add a test item to the rotation schedule. 2. Check the item out before the cronjob runs to change the item's branch. 3. Run the stock rotation cronjob to move all items to the next branch. 4. Check in the item at a different branch (neither the old or new owning branch). 5. Note that Koha does not prompt a transfer on the item. 6. The item should have a pending transfer that was not triggered. 7. Check the item in again to trigger the transfer. Note: Is it possible this issue relates or overlaps with the following bugs? * Bug 40331 * Bug 36658 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 31016] New: Highlight item in holdings when searching by barcode
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '26

12 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31016 Bug ID: 31016 Summary: Highlight item in holdings when searching by barcode Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org When one searches by barcode for an item from a bib with multiple items, one is taken straight to the bib record details page, where one must then find that specific item in the holdings table. The more items on the bib, the harder that becomes. It would be helpful if the item with the barcode one searched by could be highlighted in the holdings table for easy identification. Ideally this would work whether one has done a specific barcode search or if one has put a barcode in as a keyword. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 38924] New: Introduce a loan 'Quota' system for Koha
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '26

12 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38924 Bug ID: 38924 Summary: Introduce a loan 'Quota' system for Koha Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.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 Some libraries work based on the number of allowed issues in a time period as opposed to the number of simultaneous issues. This enhancement intends to add a per-user, including guarantee/guarantor relations, quota option for setting a fixed number of issues a user is allowed within a specified period. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 320

[Bug 36988] New: PUT for patrons requires full borrowers permission, but should only require 'edit_borrowers'
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36988 Bug ID: 36988 Summary: PUT for patrons requires full borrowers permission, but should only require 'edit_borrowers' Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com CC: tomascohen(a)gmail.com On the staff side, a user with only edit_borrowers can make changes to a patron account - for PUT access we require borrowers=>1 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 35705] New: Add option to force patrons to receive digested notices
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35705 Bug ID: 35705 Summary: Add option to force patrons to receive digested notices Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org We'd like to require all of our patrons who elect to receive due, pre-due, or hold available notices to receive the digested versions of those notices. It's currently possible to use jQuery to force the "Digest Only" box to be checked on patron edits, but it'd be better to have this defined in a system preference or something more formal. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 22160] New: OMNIBUS: Transfers enhancements
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22160 Bug ID: 22160 Summary: OMNIBUS: Transfers enhancements 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: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 90