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

[Bug 41674] New: Add template plugin for linking to system preferences based on user permission
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41674 Bug ID: 41674 Summary: Add template plugin for linking to system preferences based on user permission 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: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org There are many places in templates where we link to a system preference and we are inconsistent about whether these links are dependent on the permission of the logged-in user. I propose to add a template plugin which handles the permission check. [% "RequireChoosingExistingAuthority" | html | $LinkPref %] For a user with 'CAN_user_parameters_manage_sysprefs' permission it outputs: <a class="link_preference" href="admin/preferences.pl?op=search&ok=Search&searchfield=RequireChoosingExistingAuthority">RequireChoosingExistingAuthority</a> For a user without permission it outputs: <span class="link_preference">RequireChoosingExistingAuthority</span> -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 41253] New: Item Modification by Age should have its own permission
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41253 Bug ID: 41253 Summary: Item Modification by Age should have its own permission Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex(a)rcls.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, access to the Item Modification by Age tool is determined by the items_batchmod permission. In a Consortium setting, a common scenario is to restrict item editing, including batch item editing, to staff users of the item owning library. This is done via Library Groups and the standard edit_items permission. However, the Item Modification by Age tool does not restrict the items.homebranch condition, allowing users of any library to define a new rule for a library they don't belong to and whose items they don't own. Breaking the tool permissions into two separate permissions would solve this issue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 40934] New: process_message_queue.pl add ability to exclude some letter code
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40934 Bug ID: 40934 Summary: process_message_queue.pl add ability to exclude some letter code Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz It would help to add an argument to process_message_queue.pl to exclude some letter-code (like a blacklist, send all letter-code except these ones) Use case : Some library would like to send digest once per day (say at 20:05) but all others message every hour. It is currently possible to do that by having 2 lines process_message_queue.pl that way : ``` 00 */1 * * * process_message_queue.pl --code ACQ_NOTIF_ON_RECEIV --code CART ... # list all message except digest 05 20 * * * process_message_queue.pl #send all message including digest ``` The problem with this method is that we have to list almost all letter-code in the first line (around 85), there is a high chance that we forget some notification in the every hour line (thus these notifications will not be sent every hour as wanted) It would be great to be able to do it by excluding some letter code example: ``` 00 */1 * * * process_message_queue.pl --xcode DUEDGST --xcode PREDUEDGST --xcode HOLDDGST --xcode AUTO_RENEWALS_DGST # send all exepct digest 05 20 * * * process_message_queue.pl # send all including digest ``` (In this example, argument is xcode for exclude code but I'm not sure about the name) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 52

[Bug 42310] New: Move calendar CRUD to Koha::Calendar::* with normalized schema
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42310 Bug ID: 42310 Summary: Move calendar CRUD to Koha::Calendar::* with normalized schema 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The calendar system currently relies on C4::Calendar for all write operations using raw DBI, and two overloaded tables where column values determine the type of closure (repeatable_holidays.weekday IS NOT NULL = weekly, IS NULL = annual; special_holidays.isexception = closure vs exception). Single dates are stored as separate day/month/year smallints instead of a DATE column. The goal is to replace this with proper Koha::Object classes under the Koha::Calendar::* namespace backed by normalized, purpose-specific tables, and refactor Koha::Calendar to consume them. This unblocks REST API CRUD endpoints and a Vue-based rewrite of the holidays admin page in the future. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 162

[Bug 42997] New: Keep booking end dates in sync with checkout due dates at issue and renewal
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42997 Bug ID: 42997 Summary: Keep booking end dates in sync with checkout due dates at issue and renewal Initiative type: --- Sponsorship --- status: 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)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Depends on bug 41898 (booking status lifecycle). With the 'issued' booking status in place, the booking and its linked checkout can drift apart whenever the due date differs from the booking end date - at issue time (staff due date overrides) and at renewal. This patchset makes the checkout due date authoritative and keeps the booking in step with it: - AddIssue syncs any due date override back to booking.end_date the moment the booking transitions to 'issued'; if the override would clash with a subsequent booking the checkout proceeds with the booking's original end date - CanBookBeIssued raises a new BOOKED_DUE_DATE_CLASH confirmation on the checkout screen when an explicitly requested due date runs into the next booking for the item, so staff are warned before continuing - circulation.pl now honours an explicit due date override for booked items instead of silently clamping it to the booking end date - CanBookBeRenewed no longer allows a renewal to run straight through the start of the next booking: the patron's own booking previously hid subsequent bookings from the clash lookup. Requested due dates (checkouts screen renewal date, circ/renew.pl hard due date) are now validated against bookings too - AddRenewal pulls the linked booking's end_date along with the renewed due date, mirroring the AddIssue behaviour Test plan: 1. Run t/db_dependent/Circulation.t and t/db_dependent/Koha/Item.t 2. Create two consecutive bookings on one item for two patrons; check the item out to the first patron with a due date beyond the second booking's start; confirm the warning appears and, on confirming, the checkout uses the requested date whilst the booking keeps its original end date 3. Check out a booked item with a non-clashing due date override and confirm the booking end date follows it 4. Renew a booked checkout and confirm the booking end date follows the new due date; attempt to renew past the next booking's start and confirm the renewal is refused -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 37471] New: Add permissions for managing Catalog Concerns
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37471 Bug ID: 37471 Summary: Add permissions for managing Catalog Concerns 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: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Similar to bug 33363 for purchase suggestions, it would be great if there were more specific permissions for catalog concerns. It would be nice if the ability to manage these were limited to those with assigned permissions on the catalog staff. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 43202] New: Improve discoverability of ERM system preferences
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43202 Bug ID: 43202 Summary: Improve discoverability of ERM system preferences 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- I typically search and then browse when I'm looking for a system preference, and it drives me crazy that searching "ERM" does not bring up the system preference "ERMModule". I think there are some small improvements we can make to the erm.pref file to enhance discoverability. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 42344] New: Remove CircSidebar
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42344 Bug ID: 42344 Summary: Remove CircSidebar Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 42330, 16530, 31403 Now that we can collapse the sidebar on all views (see bug 42330) we can remove the pref CircSidebar. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16530 [Bug 16530] Add a circ sidebar navigation menu https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31403 [Bug 31403] Activate circulation sidebar (CircSidebar system preference) on default in new installations https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42330 [Bug 42330] Use main-container.inc from all the templates -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 42330] New: Use main-container.inc from all the templates
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42330 Bug ID: 42330 Summary: Use main-container.inc from all the templates Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We can now use main-container.inc with a custom aside (see bug 42322). Now we need to use it for all our templates. -- You are receiving this mail because: You are watching all bug changes.

1 88

[Bug 32419] New: Show availability in list view in staff interface
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32419 Bug ID: 32419 Summary: Show availability in list view in staff interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When viewing a list on the OPAC, you can see the item's availability. But in the staff interface, this information is not visible. To test : 1. In the staff interface, add an item to a list 2. View the list --> No availability is visible 3. Go to the OPAC and view the list --> You can see the availability of the item -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32