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

[Bug 26288] New: Update the Select2 JS lib to version 4.1.0
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26288 Bug ID: 26288 Summary: Update the Select2 JS lib to version 4.1.0 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Bug 25727 updated Select2 to the latest stable release (4.0.13). We found some glitches about the width (see bug 25727 comment 19 for instance). It seems that the next 4.1 is going to fix it, but still beta. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 39142] New: Add debug permission to allow user to toggle JS and CSS customizations on/off
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39142 Bug ID: 39142 Summary: Add debug permission to allow user to toggle JS and CSS customizations on/off Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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 Depends on: 14004 We all love bug 14004 and its fun tools for loading pages without JS or CSS from sysprefs. We'd like to extend that idea to toggles that would appear on every page to turn UserJS and UserCSS on and off. We'd tie those toggles to a new "debug" permission, so only users with that permission will be shown those toggles. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14004 [Bug 14004] Add ability to temporarily disable added CSS and Javascript in OPAC and interface -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 63

[Bug 43235] New: Update some serials pages to use grid layout for forms - Part 2
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43235 Bug ID: 43235 Summary: Update some serials pages to use grid layout for forms - Part 2 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: 39780 Target Milestone: --- - serials/subscription-batchedit.tt - serials/subscription-frequencies.tt - serials/subscription-numberpatterns.tt Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39780 [Bug 39780] Update library groups form to use grid layout -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 43264] New: Update some circulation pages to use grid layout for forms
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43264 Bug ID: 43264 Summary: Update some circulation pages to use grid layout for forms Initiative type: --- Sponsorship --- 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 Depends on: 39780 Target Milestone: --- - circ/request-article.tt - circ/set-library.tt Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39780 [Bug 39780] Update library groups form to use grid layout -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 39780] New: Update library groups form to use grid layout
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39780 Bug ID: 39780 Summary: Update library groups form to use grid layout Change sponsored?: --- 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 Depends on: 39483 Building on Bug 39483, I'm working to convert the library groups forms to the new grid layout. This will include some changes to the .fg form grid to allow for defining a couple of different widths for the input grid item and to convert the grid-related media queries to be container queries instead. This allows the form grid to be responsive based on width of the the container (<fieldset) rather than the width of the page. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39483 [Bug 39483] Update staff interface forms to use grid layout -- You are receiving this mail because: You are watching all bug changes.

1 55

[Bug 41017] New: Show if item is on hold even if OverduesBlockRenewing is on
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41017 Bug ID: 41017 Summary: Show if item is on hold even if OverduesBlockRenewing is on 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com I've had a comment by a library that uses OverduesBlockRenewing as well as AllowRenewalLimitOverride (and AllowRenewalOnHoldOverride) that when the item is overdue, the fact that it's on hold is not displayed in the patron's checkouts. Their issue is that while they don't want patrons renewing overdue items from the OPAC, they sometimes override the renewal in the staff interface, but end up unknowingly renewing something that is on hold... To recreate in main: 1. Go to a patron's account and checkout with a past date to create an overdue checkout 2. Place a hold for the same item for another patron 3. View the first patron's checkouts --> In the "Renew" column, it says "On hold" 4. Enable AllowRenewalOnHoldOverride 5. Go back to the patron's checkouts --> The "Renew" column should still say "On hold" 6. Check the "Override renewal restrictions" box --> A check box appears in the "Renew" column, which still displays "On hold" nonetheless 7. Enable OverduesBlockRenewing ("block renewing for all the patron's items") (I think both blocks should work in this scenario, but the library has it set to all) 8. Enable AllowRenewalLimitOverride 9. Go back to the patron's checkouts --> The "Renew" column displays "Not allowed: overdue" (OK) No mention of on hold (NOT OK?) 10. Check the "Override renewal restrictions" box --> A check box appears in the "Renew" column (OK), still no mention of on hold (NOT OK?) The "On hold" mention should be displayed whether or not the item is overdue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 43263] New: Public biblio ratings API does not check OpacSuppression
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43263 Bug ID: 43263 Summary: Public biblio ratings API does not check OpacSuppression Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 Depends on: 43258 Target Milestone: --- POST /api/v1/public/biblios/:id/ratings (Koha::REST::V1::Biblios::set_rating) does not check whether the biblio is suppressed. A logged-in patron can rate a suppressed record if they know its biblio_id, confirming the existence of a record that should be hidden. Impact: information disclosure - the existence of suppressed bibliographic records can be confirmed via the public API (a successful rating confirms the record exists). Affected endpoints: - POST /api/v1/public/biblios/:id/ratings (Koha::REST::V1::Biblios::set_rating) Related: bug 43258 introduces Koha::IP and Koha::REST::Plugin::Restrictions which provide the fix mechanism. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43258 [Bug 43258] Add a centralized IP range matching helper -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43262] New: Public biblio items API does not check OpacSuppression
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43262 Bug ID: 43262 Summary: Public biblio items API does not check OpacSuppression Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major 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 Depends on: 43258 Target Milestone: --- GET /api/v1/public/biblios/:id/items (Koha::REST::V1::Biblios::get_items_public) does not check whether the parent biblio is suppressed. If a client knows the biblio_id of a suppressed record, they can enumerate its items via the public API. The endpoint uses filter_by_visible_in_opac() which handles OpacHiddenItems at the item level, but does not check biblio-level suppression (OpacSuppression / OpacSuppressionByIPRange). Impact: information disclosure - items belonging to suppressed bibliographic records are accessible via the public API. Affected endpoints: - GET /api/v1/public/biblios/:id/items (Koha::REST::V1::Biblios::get_items_public) Related: bug 43258 introduces Koha::IP and Koha::REST::Plugin::Restrictions which provide the fix mechanism. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43258 [Bug 43258] Add a centralized IP range matching helper -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 20570] New: Add script to complete scanned article requests
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20570 Bug ID: 20570 Summary: Add script to complete scanned article requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 24910] New: Make it possible to choose see also-authorities in authority finder
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24910 Bug ID: 24910 Summary: Make it possible to choose see also-authorities in authority finder Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When searching for authorities, sometimes you may see the result you want to select in a see also, but it is not possible to *choose* that one. You have to do another search to get it into the results list of auth finder. Wouldnt it be nice if we could somehow add a link to choose them too? The current link allows you to open them, but this seems less useful at least in our case. Would a preference be useful to switch between choosing or opening ? Or should we add a small link? How could we address that best in terms of styling etc? Your feedback is appreciated ! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2