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

[Bug 35729] New: Coce Should Account for New ISBN 979*
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35729 Bug ID: 35729 Summary: Coce Should Account for New ISBN 979* 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: kalleen(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, I noticed that there was a cover mismatch with a coce_amazon cover because the new 2024 title has an ISBN of 9798885795692 (using the 979 instead of 978). There is an Italian title with an ISBN of 8885795692 that is showing instead. It looks like they have updated the valid ISBN standards: https://isbn.org/about_isbn_standard and it seems like coce should be updated to recognize this new standard and not match 9798885795692 to be the same as 8885795692. Thanks! Kal -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 97

[Bug 43198] New: Update suggestions template to use grid layout for forms
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43198 Bug ID: 43198 Summary: Update suggestions template to use grid layout for forms Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 39780 Target Milestone: --- This patch will update the suggestions template to use grid layout for the add/edit form. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39780 [Bug 39780] Update library groups form to use grid layout -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 41113] New: Missing doc-head-close and cssinclude in sci-main.tt
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41113 Bug ID: 41113 Summary: Missing doc-head-close and cssinclude in sci-main.tt Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: aleisha(a)catalyst.net.nz, alexbuckley(a)catalyst.net.nz, dcook(a)prosentient.com.au, hammat.wele(a)inlibro.com, lucas(a)bywatersolutions.com, testopia(a)bugs.koha-community.org +++ This bug was initially created as a clone of Bug #21266 +++ Many of the some changes should be made to the self checkin templates -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 42748] New: Rewrite selenium/administration_tasks.t using Cypress
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42748 Bug ID: 42748 Summary: Rewrite selenium/administration_tasks.t using Cypress Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 29285 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29285 [Bug 29285] [OMNIBUS] Rewrite Selenium tests using Cypress -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 24608] New: Allow modification of checkout due date
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24608 Bug ID: 24608 Summary: Allow modification of checkout due date Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently it is not possible to modify a checkout's due date. This bug proposes to allow such an action. It is only proposed to allow modification of a due date *forward* at this stage as moving a due date backwards may involve additional complication that will require further thought. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 71

[Bug 43606] New: Add x-koha-embed: items support to GET /biblios (list), respecting OPAC/public item visibility
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43606 Bug ID: 43606 Summary: Add x-koha-embed: items support to GET /biblios (list), respecting OPAC/public item visibility Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- The REST API endpoint GET /biblios (operationId listBiblio) can return records as MARCXML, MARC-in-JSON, USMARC and plain text via content negotiation. However, the serialized records never include item data (952 fields), even when the caller would like them embedded. Currently: * The swagger definition for GET /biblios (api/v1/swagger/paths/biblios.yaml) does not declare an x-koha-embed header parameter. Because OpenAPI input validation is strict, sending "x-koha-embed: items" against this endpoint results in an HTTP 400 response. * The controller Koha::REST::V1::Biblios::list serializes with $biblios->print_collection('marcxml'), passing no embed option. * Koha::Objects::Record::Collections::print_collection has a positional signature ( $self, $format ) and serializes each element using $element->record, i.e. the raw stored MARC with no items. As a result, clients that need biblios with items must fall back to fetching items one biblio at a time (GET /biblios/{biblio_id}/items), which is an N+1 access pattern and is significantly slower for bulk/list use cases. Proposed enhancement: Add the ability to embed items into the records returned by the list endpoints, driven by the existing x-koha-embed request header, e.g.: x-koha-embed: items Item visibility MUST be respected according to the interface the request is served on: * Staff/intranet route (GET /biblios): embed all items (subject to the existing catalogue permission already required by the endpoint). * Public route (GET /public/biblios and related public list endpoints): embed only items visible in the OPAC, honouring OpacHiddenItems and patron category override_hidden_items, consistent with how get_public, get_items_public and Items::list_public already scope items via filter_by_visible_in_opac. The building block already exists: Koha::Biblio::metadata_record already supports: $biblio->metadata_record({ embed_items => 1, interface => 'opac' | 'intranet', patron => $patron, }); which applies the EmbedItems record processor and, for the opac interface, scopes items through filter_by_visible_in_opac (plus the ViewPolicy filter). Suggested implementation outline: 1. Give print_collection a hashref-based signature that accepts embed_items (and interface/patron), choosing per element between $element->record and $element->metadata_record({ embed_items => 1, interface => ..., patron => ... }). 2. In the list controllers, read the embed list from the request (the koha.embed stash populated when x-koha-embed is sent) and pass embed_items through to print_collection. The public list controller must pass interface => 'opac' and the current patron so OPAC visibility rules apply; the staff controller passes interface => 'intranet'. 3. Declare the x-koha-embed header parameter with an "items" enum value on the listBiblio operation (and the equivalent public list operation) in the swagger spec, so the header is accepted instead of rejected with HTTP 400. This keeps serialization logic in the collection class, reuses the existing item-visibility scoping, and makes it possible to retrieve a page of biblios with their items in a single request rather than one request per record. Backwards compatibility: default behaviour (no x-koha-embed header) is unchanged and continues to return records without items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 42827] New: Items expected column in parcels.pl always displays 0
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42827 Bug ID: 42827 Summary: Items expected column in parcels.pl always displays 0 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The controller expects the sql to return an itemsexpected value but it never does so it always defaults to the hardcoded fallback of 0 To recreate: 1. Create an order with multiple items and receive the order in full 2. From the vendor record, click Receive shipments 3. You should be in parcels.pl and the table should show your shipments 4. The Items expected column will show 0 even though you ordered multiple items -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 28593] New: Add ability to charge lost fee when applying new lost status when resolving a claim
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28593 Bug ID: 28593 Summary: Add ability to charge lost fee when applying new lost status when resolving a claim Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 28271 Bug 28271 added the ability to apply a new lost status when resolving a claim. We should also add the ability to charge a replacement fee. Many libraries do not charge a replacement fee when a claim is generated. If the item is not found within the time period allowed by library policy, then the item is assumed lost, the claim is resolved, and the item is set to lost. At that point, the library would like to charge the patron. As things stand, there is not a way to generate a lost fee tied to that issue_id. You'd have to either create a manual invoice or return the item, check it back out to the patron, and mark it lost again. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28271 [Bug 28271] Add the ability to set a new lost status when a claim is resolved -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 43136] New: ILL Requests history should have privacy option
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43136 Bug ID: 43136 Summary: ILL Requests history should have privacy option Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- Patrons have the ability to remove circulation and holds history. They should also be able to remove ILL request history. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 40252] New: Create dedicated ILL_HOLD_SLIP
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40252 Bug ID: 40252 Summary: Create dedicated ILL_HOLD_SLIP Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Many ILL backends tie an ILL request to a hold in Koha. In these cases, libraries generally want to print a distinct HOLD_SLIP for holds associated with ILL requests. This leads to long and complicated HOLD_SLIPs. We'd like to teach Koha to use a new distinct slip when a hold has an illrequest associated with it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1