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

[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 42868] New: Bookings are storing incorrect timezone values
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42868 Bug ID: 42868 Summary: Bookings are storing incorrect timezone values Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Somehow, between the date picker and the DB, the bookings module is converting dates incorrectly and setting the wrong dates. To recreate: 1 - Edit koha-conf.xml 2 - Set timezone: <timezone>America/New_York</timezone> 3 - In Koha, enable bookings syspref 4 - Find a record, click the items tab, make an item bookable 5 - Place new booking, choose a date range 6 - View the bookings tab - note the booking extends into the date before 7- Check the DB: MariaDB [koha_kohadev]> select * from bookings WHERE booking_id=2; +------------+-----------+-----------+---------+-------------------+---------------------+---------------------+---------------------+---------------------+--------+---------------------+ | booking_id | patron_id | biblio_id | item_id | pickup_library_id | start_date | end_date | creation_date | modification_date | status | cancellation_reason | +------------+-----------+-----------+---------+-------------------+---------------------+---------------------+---------------------+---------------------+--------+---------------------+ | 2 | 12 | 437 | 971 | FPL | 2026-06-23 20:00:00 | 2026-06-26 19:59:59 | 2026-06-17 15:00:40 | 2026-06-17 15:00:40 | new | NULL | +------------+-----------+-----------+---------+-------------------+---------------------+---------------------+---------------------+---------------------+--------+---------------------+ 1 row in set (0.000 sec) Start date time is 20:00 - really 00:00 minus 4 - New York is UTC minus 4 - it seems we shouldn't subtract more -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[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

[Bug 40134] New: Fix and optimise 'Any item' functionality of bookings
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40134 Bug ID: 40134 Summary: Fix and optimise 'Any item' functionality of bookings Change sponsored?: --- Product: Koha Version: unspecified 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)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 29002 The 'Any item' option in the bookings modal is currently not correctly calculating maximum available booking window correctly and we have older code left behind that attempted to allow any item at a biblio level without taking into account item type limitations. This bug acts to correct that by implementing an optimized algorithm for picking the item at booking time to try and maximize the pool of available items for future bookings. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29002 [Bug 29002] Add ability to book items ahead of time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 69

[Bug 39584] New: Booking post-processing time cuts into circulation period
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39584 Bug ID: 39584 Summary: Booking post-processing time cuts into circulation period Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Enforcing max circ rule loan periods on bookings (37354), cuts into the circ period of a booking when post-processing days are added. To replicate: 1. Set up two days of post-processing time in the circ rules for an item type. 2. Make that item type bookable. 3. Place a booking for an item from that item type. Note that the 2-days of post-processing time are factored into the total number of days allowed for the booking. For a 7-day circ period, the booking cannot be set for 7 days; it is enforced to end at 5. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 81

[Bug 39916] New: The 'Place booking' modal should have cypress tests
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39916 Bug ID: 39916 Summary: The 'Place booking' modal should have cypress tests Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org The bookings modal is one of the more complex modal forms we have, with a lot of logic involved. We should add cypress tests to ensure we don't see regressions here. -- You are receiving this mail because: You are watching all bug changes.

1 89