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

[Bug 33302] New: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33302 Bug ID: 33302 Summary: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com, tomascohen(a)gmail.com A bit much to put in the description, but the problem is about item level holds failing to be placed silently in the OPAC. To test: With the sample data in ktd or sandboxes: 1) Enforce library transfer limits (UseBranchTransferLimits) on itemtypes (BranchTransferLimitsType). 2) In administration > branch transfer rules: disallow transfer from Midway to any other library for item type BK (Books) 3) Search for a record with at least one item in Midway in staff 4) Try to place an item level hold on a Midway item. I used: Intermediate Perl, biblionumber 126 For the Midway item, only Midway will show as possible pickup-location This is correct. 5) Switch to the OPAC 6) Try to place an item level hold there on the Midway item, for pick-up at Centerville. 7) Place a hold on the Midway item for pick-up at any non-Midway location 8) Verify the page saves without error, but the hold was not placed. - The basic issue here is that item specific pickup locations != record-specific pickup locations. In the staff interface we have a separate pull down "allowed pick-up locations" for each item in the list. I think we should implement the same in the OPAC to help the users see what is allowed and what not. And deacticate the pull down on top when an item is selected. But: At least we should give proper feedback that a hold could not be placed because of the pick-up location instead of failing silently! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 33179] New: Allow for libraries to automatically suppress a bibliographic record from OPAC if no items are attached
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33179 Bug ID: 33179 Summary: Allow for libraries to automatically suppress a bibliographic record from OPAC if no items are attached 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice for Koha to allow libraries to automatically suppress a bibliographic record from OPAC if no items are attached. Currently, the library would need to manually add a 942$n = 1 to suppress records. But if the record has no items and can automatically be suppressed until items are attached, this would be a nice efficient workflow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 42150] New: Allow plugins to register Vue islands via registerIsland()
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42150 Bug ID: 42150 Summary: Allow plugins to register Vue islands via registerIsland() Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: me(a)paulderscheid.xyz QA Contact: testopia(a)bugs.koha-community.org The islands module provides Koha's Vue component architecture but does not expose a public API for external registration. This enhancement enables plugins to contribute Vue islands to the staff interface. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 74

[Bug 42189] New: Allow plugins to inject dashboard widgets via a shared Vue widget registry
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42189 Bug ID: 42189 Summary: Allow plugins to inject dashboard widgets via a shared Vue widget registry Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org Koha's Vue module dashboards (ERM, Preservation, etc.) currently have a hardcoded set of widgets. There is no mechanism for plugins to contribute their own widgets that integrate with the existing dashboard infrastructure (WidgetWrapper, WidgetPicker, drag-and-drop, localStorage persistence). This patch set introduces a widget registry that plugins can extend from their intranet_js() hook, along with the build infrastructure needed to make it work correctly across bundle boundaries. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 109

[Bug 13687] ILS-DI services HoldItem and HoldTitle don't consider hold policy by item type
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13687 Akhdan Arif <akhdanarif456(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |akhdanarif456(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43284] New: ILS-DI: patron data/circulation services lack authentication
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43284 Bug ID: 43284 Summary: ILS-DI: patron data/circulation services lack authentication Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: akhdanarif456(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 203573 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203573&action=e… Proof of concept in local deployment of 26.05.02 with ILS-DI enabled and allowlist ip in ILS-DI:AuthorizedIPs The ILS-DI services (opac/ilsdi.pl) expose patron data and circulation operations (renew loan, place hold) with no authentication and no per-user authorization. The only access control is the ILS-DI:AuthorizedIPs IP allowlist. Once a request passes that IP check, anyone can read any patron's personal data and perform actions on behalf of any patron, using only predictable numeric IDs. Exploitable when: ILS-DI is enabled and the client IP is in ILS-DI:AuthorizedIPs . Where those hold, authentication is entirely absent. Reproduce: 1. Setup: enable ILS-DI = 1, add attacker IP to ILS-DI:AuthorizedIPs. 2. Read + enumerate patron data (no auth): GET /cgi-bin/koha/ilsdi.pl?service=GetPatronInfo&patron_id=2&show_contact=1 3. State-changing (no auth): GET /cgi-bin/koha/ilsdi.pl?service=RenewLoan&patron_id=2&item_id=1 & GET /cgi-bin/koha/ilsdi.pl?service=HoldTitle&patron_id=2&bib_id=1&request_location=127.0.0.1 Actual Results: 1. GetPatronInfo returns full PII (address, phone, cardnumber, city) for any patron; enumeration dumps the whole patron database. 2. RenewLoan extends the loan: date_due changed 2026-08-26 → 2026-08-31 ( <success>1</success>). 3. HoldTitle creates a hold on behalf of the victim: reserves count 0 → 1. All verified on a live local deployment of 26.05.02. Expected Results: Patron-facing services should require the caller to authenticate as that patron (via AuthenticatePatron, which already exists) or as staff with permission. the IP allowlist should not be the only control. Security Hardening Gap: 1. IP allowlist is single-factor, and IPs can be spoofed/shared (VPN, NAT, shared server). If a discovery layer is used by many people or its IP is shareable, anyone on that IP can access all patron data. 2. No per-user audit trail. All requests are anonymous, hard to forensically trace. 3. CSRF exemption for /ilsdi.pl remains a problem for state-changing services if the IP gate is bypassed. Root cause: opac/ilsdi.pl never calls checkauth(); it sets an anonymous userenv and relies solely on the IP allowlist. C4/ILSDI/Services.pm looks up objects purely by numeric ID with no ownership check (GetPatronInfo, RenewLoan, HoldTitle, HoldItem, GetPatronStatus, GetServices, LookupPatron). Contrast: CancelHold does contain an ownership check — so the missing checks elsewhere are an inconsistency/oversight, not uniform design. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43283] Can't print patron cards from list unless list is on the first page of results
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43283 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Trivial patch -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43283] Can't print patron cards from list unless list is on the first page of results
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43283 --- Comment #3 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- Created attachment 203572 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203572&action=e… Bug 43283: Change event handler to work on all dT pages To test: 1. Have 25+ patron lists w/ at least 1 borrower 2. On the list of patron lists page ( lists.tt ) use the Actions button to choose 'Print patron cards' 3. On the first dT page it should open in modal ( good ) 4. On any subsquent pages it will not open in a modal and you cannot export the file ( bad ) 5. APPLY PATCH 6. Try again. The 'Print patron cards' should open in a modal on every page -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43283] Can't print patron cards from list unless list is on the first page of results
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43283 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs(a)lists.koha-commun |lucas(a)bywatersolutions.com |ity.org | Status|NEW |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43283] Can't print patron cards from list unless list is on the first page of results
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43283 --- Comment #2 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- Attaching the event handler directly to the element only works when you don't paginate with dataTables: $(".print_cards").on("click", function (e) { -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0