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

[Bug 38666] New: New feature: closed stack requests
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38666 Bug ID: 38666 Summary: New feature: closed stack requests Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: julian.maurice(a)biblibre.com 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 A closed stack request is a special kind of hold that can only be placed on a closed stack item. A closed stack item is an item that is not available publicly in the library but can be made available on demand. When a request is made, a librarian will print a slip then will go retrieve the document and place the slip in place of the document. -- You are receiving this mail because: You are watching all bug changes.

1 111

[Bug 35052] New: OpacHiddenItemsHidesRecord system preference should be considered on index time instead
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35052 Bug ID: 35052 Summary: OpacHiddenItemsHidesRecord system preference should be considered on index time instead 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: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: alexander.blanchard(a)ptfs-europe.com, dcook(a)prosentient.com.au, jacob.omara(a)ptfs-europe.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com Currently, results are being skipped after the search has been processed in C4/Search.pm. This may cause several unintended scenarios: 1) The first page has all the results skipped, even thought there are more results in 2nd page and so on, this will will result in a "No search results" page 2) The total search results number still shows 80 (for example), even if it has skipped 70 and is only showing 10. To reproduce we need to use both OpacHiddenItems and OpacHiddenItemsHidesRecord Use OpacHiddenItems and put some rules that hide some items Use OpacHiddenItemsHidesRecord = 'hide' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 43798] New: Username is not selectable in MARC overlay rules
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43798 Bug ID: 43798 Summary: Username is not selectable in MARC overlay rules Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- When adding or editing MARC overlay rules, selecting Username as the module does not provide a way to select an existing Koha username. Instead, the Filter field requires the username to be entered manually. The wildcard (*) can be used, but there is no option to search for or select a specific user. Adding username autocomplete would allow staff to search for and select an existing username, making it easier to configure user-specific MARC overlay rules while retaining support for manual entry and wildcards. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43568] New: Add ability to user a specific SMTP server for Email to SMS feature
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43568 Bug ID: 43568 Summary: Add ability to user a specific SMTP server for Email to SMS feature Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- There are places that offer their own Email to SMS service ( https://www.oplin.ohio.gov/sms is the one I'm aware of ). If a library wants to use such a service right now, it means all email must go through this email service. It would be good and useful to be able to specify a single SMTP server for Email to SMS to use specifically with all other email going through the standard channels. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 43671] New: Holds impair SCO module load time
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43671 Bug ID: 43671 Summary: Holds impair SCO module load time Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Self checkout Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In a large system, holds can have a significant impact on the amount of time it takes for the main page to load in the SCO module. In our system during busy times, patrons with many holds see load times of 20 seconds or more after logging into the SCO Module and after each checkout. We can already avoid the impact of existing checkouts on SCO Module load times, because the system preference SCOLoadCheckoutsByDefault allows the patron's existing checkouts to be loaded on-demand. We should have the option to delay the loading of holds as well. -- You are receiving this mail because: You are watching all bug changes.

1 23

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

13 Oct '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 62

[Bug 43796] New: Report share action should have option to email to someone
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43796 Bug ID: 43796 Summary: Report share action should have option to email to someone Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- It would be helpful if the report action "Share" would give the option to share via email. The report name could be pre-loaded in the subject, and the link put in the body with the description. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43624] New: Update some acquisitions pages to use grid layout for forms - Part 3
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43624 Bug ID: 43624 Summary: Update some acquisitions pages to use grid layout for forms - Part 3 Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 43609 Target Milestone: --- - acqui/orderreceive.tt - acqui/uncertainprice.tt - acqui/vendor_issues.tt - acqui/z3950_search.tt Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43609 [Bug 43609] Update some acquisitions pages to use grid layout for forms - Part 2 -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 43313] New: Item's permanent location not shown when item's location is set to CART
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43313 Bug ID: 43313 Summary: Item's permanent location not shown when item's location is set to CART Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: regression Severity: normal Priority: P5 - low Component: Staff interface 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 Target Milestone: --- In 25.11 and previous, when items.location and items.permanent_location do not match, Koha shows the permanent_location value followed by the location value in parentheses. This is most often due to the library using UpdateItemLocationOnCheckin to set the location to CART at checkin. In 26.05 and later, the permanent_location value is not displayed. Instead, one is shown only the location in parentheses. So where we would have seen Adult fiction (Shelving cart) We now see (Shelving cart) We should show both values. Inserting a line break between them while we're at it would be nice: Adult fiction (Shelving cart) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 42809] New: Notification falls to print back when two messaging preferences are set but only one is valid.
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 Bug ID: 42809 Summary: Notification falls to print back when two messaging preferences are set but only one is valid. Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- See https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40960#c18 This [Bug 40960] causes problem for patrons with their messaging preferences set to receive both sms and mail and one of the transport types fails. For example when the patron does not have a mail registered but both message types are checked on their account they will receive both sms and printed notices. When using standard/pre-filled messaging preferences based on patron category this can create a large number of unwanted print notices. When a notice is sent with sms OR mail you don't want to create a print notice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28