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

[Bug 43359] New: Migrate opac-search.pl to use the new /search architecture (Bug 43355)
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43359 Bug ID: 43359 Summary: Migrate opac-search.pl to use the new /search architecture (Bug 43355) 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 43355 Target Milestone: --- OPAC web search (opac-search.pl) and the new /search REST endpoint (Bug 43355) currently run on separate code paths. Left unaddressed, this risks exactly the divergence flagged by David Cook on Bug 25870 (comment #52): third-party apps and discovery layers using the API can return different results than the OPAC's own web search, which library users notice and dislike. This bug migrates opac-search.pl's query building and execution onto the same architecture Bug 43355 establishes, so OPAC web search and the REST search API are guaranteed to return consistent results, and so future search improvements only need to be made once. Test plan: 1. To be written once Bug 43355 has landed and this bug's approach is scoped. This bug is part of a staged program building on Bug 43355; see that bug for the overall plan. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43355 [Bug 43355] Add a /search API endpoint for biblios -- You are receiving this mail because: You are watching all bug changes.

1 1

[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 42577] New: Gettext.js incorrectly located and tidied
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42577 Bug ID: 42577 Summary: Gettext.js incorrectly located and tidied Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you look at opac-tmpl/bootstrap/js/Gettext.js or its intranet-tmpl equivalent, you'll notice that it's actually a third-party script and not a Koha script, so it should be in the "lib" folder and the license for it should be added to about.tt We've also tidied the file because it wasn't in "lib"... so we might want to undo that. -- You are receiving this mail because: You are watching all bug changes.

1 5

[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 35142] New: Koha::Util::oclc_number should be removed in favor of Koha::Biblio::Metadata::Extractor
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35142 Bug ID: 35142 Summary: Koha::Util::oclc_number should be removed in favor of Koha::Biblio::Metadata::Extractor Change sponsored?: --- 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: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 30678, 34828 See bug 34828. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30678 [Bug 30678] Add OCLC_NO as option to OPACSearchForTitleIn https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34828 [Bug 34828] Add Koha::Biblio::Metadata::Extractor* classes -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44

[Bug 42975] New: Patron category filters broken in Record overlay rules
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42975 Bug ID: 42975 Summary: Patron category filters broken in Record overlay rules Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- On main, if you turn on MARCOverlayRules and go to Admin > Record overlay rules the rules are broken for Module = Patron category. If you select Patron category, the "filter" dropdown menu lists 14 entries of "[object Object]". Some piece of patron data is unsuccessfully being cast to a string in the page's JavaScript. We are on 25.11 so our overlay rules are broken in a different way, but I think this should list several patron category properties. I'm guessing this originates right at the top of the JS <script> at the bottom of koha-tmpl/intranet-tmpl/prog/en/modules/admin/marc-overlay-rules.tt: var categories = [% To.json( categories ) | $raw %]; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[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