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

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

[Bug 37680] New: inconsistencies with the search results when selecting the "Limit to records with available items" option
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37680 Bug ID: 37680 Summary: inconsistencies with the search results when selecting the "Limit to records with available items" option Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org There seem to be inconsistencies with the search results when selecting the "Limit to records with available items" option, when we have a notice with two items if the first item is «notforloan» and the second is «notforloan» too or «withdrawn» the notice is still available. And these conditions also are showing : Case : 1- Record with first item as «notforloan» - The second is «notforloan» 2- Record with first item as «notforloan» - The second is «withdrawn» 3- Record with first item as «itemlost» - The second is «notforloan» 4- Record with first item as «itemlost» - The second is «withdrawn» 5- Record with first item «onloan» - The second is «notforloan» 6- Record with first item «onloan» - The second is «withdrawn» To reproduce: 1. Catalog a new record (record test 1) 1.1. Go to Cataloging 1.2. Click New record 1.3. Fill out the mandatory fields (000, 003, 005, 008, 040$c, 245$a, 942$c) 1.4. Click Save (No need to add an item) 1.5. Add two items, set a negative notforloan (ordered) for the two items 2. Repeat step 1, by creating a record (record test 2) with two items one negative notforloan item and the second as «withdrawn» item 3. Repeat step 1, and creating all the record in «Case» section 4. Go to the Opac and search for the created record 5. Click on «Limit to records with available items» ----> All the created items is still showing -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 43093] New: Allow biblioitems.totalissues to keep correct numbers on merged records
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43093 Bug ID: 43093 Summary: Allow biblioitems.totalissues to keep correct numbers on merged records Initiative type: --- Sponsorship --- status: 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: michael.adamyk(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Currently, the 942$0 is used to store biblioitems.totalissues. When merging bibliographic records, Koha allows merging holds and items, but not this field, which means any totals on the non-primary bib records are lost during the merge. Due to bug 42504, it appears that biblioitems.totalissues will be moved out of the MARC record and directly into the database. If that bug passes, would it be possible to add together the totals of all merged records' totalissues for a new total on the merged record? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 34488] New: Import default framework
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34488 Bug ID: 34488 Summary: Import default framework Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: viliam.polonec(a)snk.sk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I am testing 23.05.01 version, so we can update our production ILS. I found that I can't import default framework for bibliographic records. I tried export it and import. But with no success. KOHA shows MARC Framework for default MARC framework Create framework for () using selector with frameworks After that nothings changed I test it on two different instalations. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 24807] New: Add "year" type to improve sorting by publication date
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24807 Bug ID: 24807 Summary: Add "year" type to improve sorting by publication date Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com When sorting on date-of-publication (a year, field 008, positions 7-10), the current behavior when the field contains an invalid year (containing word characters like "uuuu" or just whitespace), these results appear first when sorting in descending order. Invalid values like these should really not be indexed at all. If so (having null values instead) they will always appear last when sorting, regardless of sort order. This fix adds a "year" search field type, that will reject any non-year values, resulting in a more user friendly sorting behavior. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 70

[Bug 43036] New: Prevent GetItemsForInventory from over-taxing resources
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43036 Bug ID: 43036 Summary: Prevent GetItemsForInventory from over-taxing resources 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 43016 Target Milestone: 26.11 GetItemsForInventory can eat up a lot of resources when called against a large collection. We should improve how we fetch and display this data. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43016 [Bug 43016] [OMNIBUS] Server resource protection -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 23333] New: Course Reserves: Instuctor search box positioning
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23333 Bug ID: 23333 Summary: Course Reserves: Instuctor search box positioning Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: claire_gravely(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 91567 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=91567&action=ed… Screenshot When creating a new course in the course reserves module the "Instructor search" box is oddly positioned. Perhaps it could be moved more in line with 'Instructors'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 42945] New: When a waiting hold is filled by another item it should have a status that can be seen in the interface
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42945 Bug ID: 42945 Summary: When a waiting hold is filled by another item it should have a status that can be seen in the interface 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- When a hold is filled by a different item, it can leave another item waiting on the hold shelf, with no way for staff to check. We should add a status to these holds/items that cleared on checkin, and offer a way for staff to view these - on the holds over tab, or somewhere obvious -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5