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

[Bug 37344] New: Patrons with cancelled discharge are seen as discharged when suspended due to overdue
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37344 Bug ID: 37344 Summary: Patrons with cancelled discharge are seen as discharged when suspended due to overdue Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org GIVEN: 1 - A library with overdue suspension 2 - A user with a cancelled discharge 3 - The same user has an issue whose date_due is gone WHEN: 1 - The book is checked in 2 - The user connects to the OPAC THEN: The user can see they are suspended due to a discharge EXPECTED: The user can see they are suspended due to an overdue -- You are receiving this mail because: You are watching all bug changes.

1 73

[Bug 42736] SQL Injection in reports/cat_issues_top.pl via Criteria / Filter request parameters (unvalidated string context, no placeholders)
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42736 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Needs documenting -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42800] Potential XSS in shelf list in the erm module
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42800 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Needs documenting -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42904] Prevent XSS in patron restriction comments
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42904 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Needs documenting -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42264] New: Ungrouping holds or grouping existing holds requires top-line reserveforothers permission
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42264 Bug ID: 42264 Summary: Ungrouping holds or grouping existing holds requires top-line reserveforothers permission Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: minor 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 While staff with the place_holds permission (and no other permissions from reserveforothers) *can* create a hold group by selecting multiple bibs in search results and choosing the 'Treat as hold group' option on the 'Place holds' screen, they cannot create a hold group from existing 'standard' holds or ungroup a hold group. Grouping existing holds and ungrouping holds requires the top-line reserveforothers permission, but it should either be part of place_holds or be a separate permission so that staff needn't also have alter_hold_targets and modify_holds_priority in order to use hold groups. To replicate the error with creation: -Use a staff patron account with only the place_holds permission from the reserveforothers group -Create 2 or more standard holds for another patron -In the regular patron's account, select the standard holds and click 'Group holds' -On the modal, click 'Group' -Note the error message: "Authorization failure. Missing required permission(s)." To replicate the problem with ungrouping: -Find/create a patron with a group hold using a staff account with top-line reserveforothers permission -Sign in using a staff patron account with only the place_holds permission from reserveforothers -Go to the regular patron account where the group hold was placed -Click the number in the 'Hold group' column, then select 'Ungroup holds' from the modal -Note that the modal disappears with no error message, but the hold has not been ungrouped -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43468] New: script tags in additional-contents should be scrubbed/disallowed
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43468 Bug ID: 43468 Summary: script tags in additional-contents should be scrubbed/disallowed Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- to recreate: 1. add a news item like: <script> console.log('hello world') </script> 2. go to the main page and see in the console, hello world Is there a reason to allow this? Shouldn't all JS go in via the UserJS system prefs? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 34867] New: Select multiple libraries in Tools (News, HTML customizations and Pages)
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34867 Bug ID: 34867 Summary: Select multiple libraries in Tools (News, HTML customizations and Pages) 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: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In Tools (News, HTML customizations, and Pages) staff can select all libraries or an individual branch. It would be nice if staff could select multiple libraries. Similar to what we do with library limitations in patron categories, authorized values, etc. This would make the creation of News, HTML customizations, and/or Pages easier for large systems, multi-branch, or campuses. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 16207] New: Incorporate circulation and fine rules for library groups
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16207 Bug ID: 16207 Summary: Incorporate circulation and fine rules for library groups Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I think we could simplify circulation and fine rules by incorporating library groups into the mix. For example, I have 27 libraries, and 8 of them follow the same set of rules that are different from the defaults. So, what if instead of cloning these special rules to 8 different libraries (and who knows how many other duplicated sets of rules there are), we defined a set of rules for a library group. If the library is part of that group, it goes by those rules. I don't know if we want to use the same library groups that are already defined in the libraries and groups, or if we want to create a unique Circ rule group. Because, there is always the chance that one or more of the libraries in the 8 that are grouped together by affiliation or region could have a slightly different set of rules. However, I think rules by groups would make managing rules far less complicated than managing groups of cloned rules. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 43341] New: Facets are appearing for items hidden via OpacHiddenItems
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43341 Bug ID: 43341 Summary: Facets are appearing for items hidden via OpacHiddenItems 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: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 14007 fixed the issue of values listed in OpacHiddenItems appearing in OPAC facets. However, there is still the issue of facet values appearing even when all items are hidden by another value being listed in OpacHiddenItems. To replicate on KTD (and to explain better): - Create a new LOC authorised value, e.g. R1 with the description Room 1. - Configure OpacHiddenItems with: "withdrawn: [1]" to hide all items with Withdrawn status 1 (labelled Withdrawn). - On a bib record, create two items. Set one of them to Shelving location = Room 1 and Withdrawn status = Withdrawn. Choose a different Shelving location and no Withdrawn status for the other. - Do the same on a second bib record. - Run a blank search on the OPAC. Notice that Room 1 appears in the Shelving location facet. - Filter by Room 1 facet and check the results. Notice that the Room 1 items are hidden, because they are withdrawn. So there are no Room 1 items visible in the OPAC and the value should not appear in the facet. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 37707] New: Lead/Trail times should work in combination
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37707 Bug ID: 37707 Summary: Lead/Trail times should work in combination 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 Depends on: 34440 Whilst working on the lead/trail time addition to bookings we discussed how they should affect things. In the end we decided that they should work in combination when placing bookings so the window of unbookable time before a bookings should be the previous bookings 'trail' period + the current bookings 'lead' period. I've run out of capacity to make that change in the aforementioned bug, so I'm splitting it out here to work on that as a expedient follow-up. Lets get the core functionality in and then continue to polish it. A- | TA >|< LB | -B- | TB >|< LC | -C Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34440 [Bug 34440] Add warm-up and cool-down periods to bookings -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 115