- 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 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

[Bug 42779] New: Editing suggestion Fund defaults to None when field previously set.
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42779 Bug ID: 42779 Summary: Editing suggestion Fund defaults to None when field previously set. Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: sam.sowanick(a)corvallisoregon.gov QA Contact: testopia(a)bugs.koha-community.org When editing an existing suggestion the Fund field defaults to none even if fund was previously set. This can lead to removing fund information from the suggestion if not reset by the Staff Member. Testing 1) create suggestion and set fund. Save and note fund is set in Suggestions list page. 2) edit suggestion. Note fund field is defaulted away from the previously set fund. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 41736] New: Move IntranetNav to HTML customizations
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41736 Bug ID: 41736 Summary: Move IntranetNav to HTML customizations Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org It would be nice if IntranetNav system preference was moved to HTML customizations. It would allow for example translations to different languages. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1