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

[Bug 23998] New: Messages REST API
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23998 Bug ID: 23998 Summary: Messages REST API 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: lari.taskula(a)hypernova.fi Expose messages table via REST API. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 41768] New: OPAC pickup location selector doesn't reflect available pickup location if you select a specific item
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Bug ID: 41768 Summary: OPAC pickup location selector doesn't reflect available pickup location if you select a specific item Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org As of now, if I go on the OPAC to place a hold, I'm presented a list of available pickup locations for that biblio. However, If I click on "more options" and select a specific item with limited transfers, I can still select any pickup location available for the biblio. This leads to a user being able to select a pickup location and be denied the hold request only after confirmation, and then have to restart again (without knowing which libraries will work). I think that can lead to some frustration for users. This is quite similar to BZ33302 or BZ10993 but I will provide a new patch with the use of Koha's api and make the OPAC more similar to the intranet interface. -- You are receiving this mail because: You are watching all bug changes.

1 54

[Bug 22707] New: Allow manual definition of AutoMemberNum range
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22707 Bug ID: 22707 Summary: Allow manual definition of AutoMemberNum range Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Target Milestone: --- It'd be great to have a way to tell Koha where to start when assigning card numbers via AutoMemberNum and to see what the next number will be. Bug 19263 introduced a feature that uses an authorized value to set up ranges of auto-incremented control numbers in bib records. Could something similar be used for card numbers? Ideally, this could also allow the definition of separate card number ranges for different branches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 42294] New: Tidy all script tags - patron searches
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42294 Bug ID: 42294 Summary: Tidy all script tags - patron searches Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 42094 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42094 [Bug 42094] Tidy all script tags (except value_builder) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 42295] New: Tidy all script tags - includes staff
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42295 Bug ID: 42295 Summary: Tidy all script tags - includes staff Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 42094 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42094 [Bug 42094] Tidy all script tags (except value_builder) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 81

[Bug 42358] New: Add support to Plack::Middleware::SizeLimit
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42358 Bug ID: 42358 Summary: Add support to Plack::Middleware::SizeLimit 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It seems like Plack::Middleware::SizeLimit would be useful to allow higher max requests while keeping memory usage down. It should be implemented in an optional manner. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 42055] New: Real time holds queue doesn't rebuild when hold from group hold is filled
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42055 Bug ID: 42055 Summary: Real time holds queue doesn't rebuild when hold from group hold is filled Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com If a library is using the real-time holds queue and a hold that is part of a group hold/hyperhold is filled, the queue isn't rebuilt to remove the other titles. To replicate: -Make sure library is using the real-time holds queue. -Create a group hold with multiple items available at one or more libraries. -Note that all available titles show on the holds queue(s) (see bug 42054). -Check an item in to satisfy the hold group. -Re-run the holds queue(s), and note that the other items from the group hold still show. The queue only appears to rebuild once the item that filled the hold is checked out. If a library checks one of the other items from the group in after the hold has been filled, the later item(s) won't trigger. This is correct behavior, but the fact that the other titles from the group still show on the queue is likely to cause significant frustration and confusion for libraries. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 23909] New: SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Bug ID: 23909 Summary: SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org Currently SCO module allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO is enabeld. Waiting items should not be able to be checked out unless librarian overrides because the notifications of an item available for pickup might have already been sent. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 73

[Bug 35934] New: Items in transit show as both in-transit and Available on holdings list
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35934 Bug ID: 35934 Summary: Items in transit show as both in-transit and Available on holdings list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 35696 Like bug 35696, this is another missed case where items.transfer should have been switched to transfer in the template. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35696 [Bug 35696] Transit status not properly updated for items advanced in Stock Rotation tool -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 41903] New: Overdues reports in circulation module are too resource intensive
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41903 Bug ID: 41903 Summary: Overdues reports in circulation module are too resource intensive Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle(a)bywatersolutions.com The circ module includes reports "Overdues" and "Overdues with fines." Both are sufficiently resources intensive as to cause noticeable slowdowns on large systems when used during business hours. They should be rewritten using APIs and VUE to improve performance. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 111