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

[Bug 41291] New: Add ability to have multiple self registration forms
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41291 Bug ID: 41291 Summary: Add ability to have multiple self registration forms 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries require multiple self registration forms with different visible fields and different required fields. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 40713] New: cookieConsent: key should have an expiration date
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40713 Bug ID: 40713 Summary: cookieConsent: key should have an expiration date Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Currently, the created localStorage key cookieConsent does not expire. This needs adjustment in view of following information: "The GDPR does not specify a fixed time limit for cookie expiry; instead, the duration must be proportionate to the cookie's purpose and never exceed 12 months according to the ePrivacy Directive, which requires consent renewal at least annually, and potentially more frequently based on your local Data Protection Authority's (DPA) guidelines, like the six-month recommendations from the Irish DPC and French CNIL." -- See e.g. https://gdpr.eu/cookies/ "If you use a cookie to store a record that a user has given consent to the use of cookies, you should ask the user to reaffirm their consent no longer than six months [*] after you have stored this consent state. (Footnote: While the legislation does not prescribe a specific lifespan for such cookies, based on a first-principles analysis by the DPC, we consider this to be the appropriate default outer timeframe for storing the user’s consent state. A controller would need to objectively and on a case-by-case basis justify storage for a longer period.)" -- Data Protection Commission [Ireland] Since localStorage has no expiration mechanism itself, we could simply add e.g. a unix timestamp as value here. Since the key now contains empty string and is tested for null to check status. This check would become: does the key exist and is its value still in future? A reject removes the key or clears it. Would it be possible to add the expiry period to a preference or enclosed in CookieConsentedJS somehow? -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 40712] New: cookieConsent: Accepting essential cookies is unneeded/misleading
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40712 Bug ID: 40712 Summary: cookieConsent: Accepting essential cookies is unneeded/misleading Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org It feels a bit strange to Accept essential cookies. If you dont accept, they work anyway. And if you can accept, you would expect a reject either. But you cant reject them: they are essential and the code just uses them. If there are no additional non-essential cookies, it feels like the bar just needs a OK button to dismiss a message that there are only essential cookies. (This dismissal is not an accept.) "Under GDPR, essential (or strictly necessary) cookies are exempt from requiring user consent because they are fundamental for basic website functionality." -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 42854] New: OPAC self-checkout does not handle items that are in transit
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42854 Bug ID: 42854 Summary: OPAC self-checkout does not handle items that are in transit Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 42851 Target Milestone: --- Split off from bug 42851. opac/sco/sco-main.pl:180 calls AddReturn and only inspects $success; it does not consider that the item may be in transit. The transfer-on-checkout logic in C4/Circulation.pm:1754-1771 force-closes a transfer when an item is issued via the staff client, but the SCO path needs explicit, considered handling. Open questions to resolve on this bug: - Should we BLOCK self-checkout of an item that is in transit? - If we allow the checkout, we must still do something sensible with the transfer, because there is still an expectation the item eventually reaches the original destination branch. Test plan: 1. Transfer an item from A to B (in transit). 2. Attempt to self-check-out the item at branch C via OPAC SCO. 3. Define and verify the agreed behaviour (block, or allow + handle the open transfer). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42851 [Bug 42851] [OMNIBUS] Items left stuck in transit when checked in outside the staff returns page -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 38196] New: Filter out concerns by specific status does not include concern without status
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 Bug ID: 38196 Summary: Filter out concerns by specific status does not include concern without status Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 35628 You can filter out concerns by status (ie. linked with TICKET_STATUS AV). But if you use this "Filter" link on top of the page to remove the concerns with this specific status, it will also remove the concerns without a specific status. concern 1 | Open concern 2 | Resolved concern 3 | status_1 concern 4 | status_2 "Filter status_1" should remove concern 3 only. However it will only show concern 4. This is because the query is ([-and => {status => { '!=' => "status_1" }}]) And does not include status that are NULL in DB. use Koha::Tickets; my $t = Koha::Tickets->search; say $_->status // "undefined" for $t->as_list; say "==="; $t = Koha::Tickets->search([-and => {status => { '!=' => "status_1" }}]); say $_->status for $t->as_list; undefined undefined status_1 status_2 === status_2 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 [Bug 35628] Add optional statuses to catalog concerns -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 42541] New: Add order and serial controls before moving items
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42541 Bug ID: 42541 Summary: Add order and serial controls before moving items 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: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Hello, Following on from patch 6532, I have added checks for orders and serials to confirm the move after a modal has been displayed if an order or serial number is linked. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 39829] New: SIP2 title field does not include subtitle, part or number
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39829 Bug ID: 39829 Summary: SIP2 title field does not include subtitle, part or number Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When returning item info we only include the main 'title' field - for check-in machines this can be unclear when a patron is returning multiple volumes of a series or other items that may share parts of a title. It would be nice to have the option to return full title info -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 43127] New: Vue holds module: scaffolding and Express bib-level hold workflow
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43127 Bug ID: 43127 Summary: Vue holds module: scaffolding and Express bib-level hold workflow Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 43126 Blocks: 43123 Target Milestone: --- Add a new Vue 3 module for hold placement, following the existing ERM / Preservation / Acquisitions pattern: - modules/holds.ts entry point, registered in rspack.config.js. - Pinia store (stores/holds.js) with session scoped holdability and pickup location caches. - Vue Router routes for the hold placement workflow. - A HoldsAPIClient wrapping the endpoints added in bug 43126. - Shared components: HoldabilityShield, HoldabilityBadge, PickupBranchPicker, HoldDateRange, HoldFeeNotice, OverrideWarning. - The Express Bib-Level Hold workflow: a single API call to GET /biblios/{id}/holdability drives a form covering pickup location, hold dates and notes, covering the common case of placing a bib level hold for a known patron and title. Add a new system preference, UseNewHoldsInterface (Yes/No, default No). When enabled, Place hold links in the staff interface point at the new Vue module instead of reserve/request.pl. reserve/request.pl and its existing behaviour are unchanged regardless of the preference value. Test plan 1. With UseNewHoldsInterface disabled (default), confirm reserve/request.pl works exactly as before. 2. Enable UseNewHoldsInterface and confirm Place hold links route to the new Vue interface. 3. Place a bib level hold through the Express workflow for a holdable title and confirm it appears correctly in the patron's account and the holds queue. 4. Confirm an ineligible patron (for example over their hold limit) is shown the correct blocker, with an override option when AllowHoldPolicyOverride is enabled. 5. Run axe-core (or equivalent) against the new components and confirm no critical or serious accessibility violations. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43123 [Bug 43123] Hold placement workflow: Vue modernisation (epic) https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43126 [Bug 43126] REST API: add holdability endpoints for biblios, items and patrons -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 43436] New: Elasticsearch doesn't order publication dates with 'u' correctly
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43436 Bug ID: 43436 Summary: Elasticsearch doesn't order publication dates with 'u' correctly Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In MARC21, but also in UNIMARC as was mentioned on Mattermost, sorting by publication date doesn't work correctly. We use date-of-publication for sorting. In MARC21 this contains the information from 008, 4-10 (Date 1). These dates are fixed on 4 characters and can contain u for unknown parts of the date: 0201 1999 07uu We noticed this while working on a project that has a lot of manuscripts that can date back to before 1000 and have some uncertainty. The 07uu will sort as 7, which puts it off by a few hundred years. I experimented with the "Call number" type in the configuration as that has a sort configuration of "numerical: false". The results appear to be much better then. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 43393] Batch patron modification only saves the changes for showed entries
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43393 Anneli Österman <anneli.osterman(a)koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anneli.osterman@koha-suomi. | |fi --- Comment #1 from Anneli Österman <anneli.osterman(a)koha-suomi.fi> --- This is probably a dublicate to bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41913 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0