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

[Bug 42579] New: Checkout history export "title" column too long
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42579 Bug ID: 42579 Summary: Checkout history export "title" column too long Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: chris.mathevet(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org In OPAC, if you export to CSV or copy to clipboard your checkout history. Title column contains rating informations with extra spaces. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA CC| |pedro.amorim(a)openfifth.co.u | |k --- Comment #54 from Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> --- Hi guys, a few issues here worth revisiting: Issue #1: duplicatetitle and duplicatebiblionumber were removed as template params from addbiblio.tt, but addbiblio.pl is still sending them. This is dead code and should be cleaned up. Issue #2: 1) Go to 'Cataloging' > 'New record' (http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?frameworkcode=) fill in field 020 $a with a test ISBN (e.g. 9781234567897) and a title in 245 $a, then 'Save' 2) Catalog a second new record, same 'Default framework', same 020 $a ISBN, 'Save', confirm Koha shows the normal 'Duplicate record suspected' warning, this is your baseline proving duplicate detection currently works 3) Go to 'Administration' > 'Record matching rules' (http://localhost:8081/cgi-bin/koha/admin/matching-rules.pl) click 'New rule', fill in a 'Rule code' and 'Description', set 'Record type' to 'Authority record' and 'Threshold' to 100, under 'Match points' set 'Search index' to Local-Number, 'Score' to 100, 'Tag' to 001, then save 4) Go to 'Administration' > 'MARC frameworks' (http://localhost:8081/cgi-bin/koha/admin/biblio_framework.pl) click 'Edit' on 'Default framework' 5) In the 'Matching rules used to find duplicates' dropdown, select the authority rule from step 3, then 'Submit' 6) Repeat step 1/2 exactly, same ISBN, still 'Default framework', 'Save' 7) No duplicate warning appears at all this time, even though it's the exact same ISBN collision as step 2. Nothing in the UI stopped you from picking an authority rule here, and picking one silently breaks duplicate detection for that framework instead of using the description-visible 'Matching rules used to find duplicates' feature correctly -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40610] New: Update OPAC templates to improve east of translation
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40610 Bug ID: 40610 Summary: Update OPAC templates to improve east of translation Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com Looking at [lang]-opac-bootstrap.po I see a lot of instances of repeated %s %s %s indicating opportunities to improve the markup structure to ease the translation process. This patch will tackle a batch of include files: koha-tmpl/intranet-tmpl/prog/en/includes/item-status.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/biblio-title-head.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/biblio-title.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/date-format.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/holds-table.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/masthead.inc -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 8214] Create a bound with function
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8214 --- Comment #56 from Matt Blenkinsop <matt.blenkinsop(a)openfifth.co.uk> --- Created attachment 205543 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=205543&action=e… Bug 8214: Adjust API logic for item linking to be exact match Previously the barcode check was a LIKE match. This patch forces the exact match and also updates the API syntax to match the Vue APIClient methodology -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8214] Create a bound with function
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8214 Matt Blenkinsop <matt.blenkinsop(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38589] New: The manual should specify that MARC configuration for bundles is the same for MARC21 and UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38589 Bug ID: 38589 Summary: The manual should specify that MARC configuration for bundles is the same for MARC21 and UNIMARC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)ptfs-europe.com, philip.orr(a)lmscloud.de In the manual, the item bundle section (https://koha-community.org/manual/latest/fr/html/circulation.html#circulati…) states "The bundle functionality will only be displayed if you create a catalogue record with the Leader, (000 MARC tag) position 7 set to ‘c’ for Collection." and displays a picture from MARC21 framework This exact configuration setting is working for UNIMARC ("c" in pos.7 of leader), but this is not obvious as many settings in Koha are MARC-flavour-dependant -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |additional_work_needed -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #953 from Jonathan Druart <jonathan.druart(a)gmail.com> --- Very quick, and late, QA review: 1. admin/circulation_triggers.tt 34 const letters = [% To.json(letters) | $raw %]; => XSS? 2. admin/circulation_triggers.tt 37 const logged_in_library_id = "[% Branches.GetLoggedInBranchcode | html %]"; We have a global logged_in_user JS variable already 3. Koha/REST/V1/CirculationRules.pm 120 return $c->render_invalid_parameter_value( 121 { 122 path => '/query/rules', 123 values => { 124 uri => '/api/v1/kinds', 125 field => 'rule_name' 126 } 127 } 128 ) unless $valid_kinds->{$rule_key}; Is this correct? /kinds is not defined in the api specs. Should it be /circulation_rules/kinds? 4. Certainly a personal pov but the code in Koha/REST/V1/CirculationRules.pm starting at l.244 (`my $logged_in_user = $c->stash('koha.user');`) to return the 403 is confusing. Too many return statements maybe? I am also not sure it's covered properly by tests (but I may have missed them). 5. Why do we still have occurrences of "edit_notice_status_triggers" in t/Koha/Auth/Permissions.t? t/Koha/Auth/Permissions.t:# Remove the deprecated edit_notice_status_triggers permission (bug 10190). t/Koha/Auth/Permissions.t:C4::Context->dbh->do(q|DELETE FROM permissions WHERE code = 'edit_notice_status_triggers'|); 6. i18n a. CirculationTriggersFormConfirmTriggerDelete.vue Untranslatable strings? + :formTitle=" + initialized + ? `Confirm deletion of Trigger ${triggerNumber} for ${handleContext(library_id, libraries, 'library_id')}` + : 'Confirm circulation trigger deletion' + " b. EditActions.vue + {{ $__("Add new trigger") + " " + triggerNumber }} + {{ $__("Edit trigger") }} {{ " " + triggerNumber }} => Should use `$__x()` to correctly handle this translation. Same pattern exist in other files. 7. EditActions.vue use an svg icon, any good reason or that? Doesn't it exist in font-awesome? 8. Duplicated CSS rules a. Just one example, but there are many like that: EditActions.vue CirculationTriggersFormConfirmTriggerDelete.vue CirculationTriggersFormConfirmReset.vue All 3 have the same CSS rules for `.chevron-buttons`, and only EditActions.vue have the .chevron-buttons element in the template. b. v-select related rules already exist in the shared css/vue.css (see "Bug 38201: Do not duplicated CSS rules") 9. In (at least) EditNotice.vue, there are !== conditions that can certainly be simplified: `v-if !== '' && !== null && !== undefined` => simply "v-if"? or do we care about 0? If we care about 0, then `!== null, !== undefined` and `!= null` are equivalent. 10. I don't understand why all the functions are in the stores file, is this a vue best practice? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42790] New: Bookings tab: action improvements
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42790 Bug ID: 42790 Summary: Bookings tab: action improvements 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com This patchset improves the patron and biblio bookings tabs by unifying the available actions across both displays, syncing due dates with booking end dates at issue time, and introducing a booking-aware Extend action for issued bookings. Depends on: Bug 41898 (Booking status lifecycle: rename and extend) === 2.1 Unified action set across Patron and Biblio bookings displays === Both the Patron bookings tab and the Biblio bookings page show the same actions, gated on booking status and the logged-in user's permissions: Status | Edit | Cancel | Checkout | Extend new | manage_bookings | manage_bookings | circulate | â issued | â | â | â | circulate completed | â | â | â | â cancelled | â | â | â | â The Patron bookings tab currently shows only Cancel; it gains Edit and Checkout. The Biblio bookings page currently shows Edit, Cancel, and "Transform to checkout"; "Transform to checkout" is renamed Checkout and shortcuts to the checkout screen pre-populated with the patron and item. === 2.2 Due date sync at AddIssue === When a booked item is checked out, AddIssue uses booking.end_date as the default due date. If staff override the due date at checkout time, the override is synced back to booking.end_date server-side, keeping the booking and the checkout in sync from the moment of issue. === 2.3 Booking-aware extension for issued bookings === An Extend button appears in the Actions column for issued bookings. It opens a modal containing: - The current booking end_date - The current checkout date_due from the embedded issue record - A date picker that visually blocks dates where another new or issued booking exists for the same item - A Confirm button On confirm, a single API call handles all updates server-side: 1. Validates the new date against the maximum booking period 2. Checks for conflicting bookings for the same item 3. Updates date_due on the linked checkout 4. Updates end_date on the booking The Extend button is only visible to users with circulate permission. === 2.4 Checkout link and due date display for issued bookings === For rows with status = issued, the Item column additionally shows the checkout due date and a link to the checkout record. Staff can see at a glance when the loan is due back and navigate to it without leaving the bookings tab. === 2.5 Visual row indicators for uncollected past-window bookings === new bookings where start_date < today receive a table-info row class to highlight that the booking is awaiting collection. new bookings where end_date < today receive a table-warning row class to highlight that the collection window has passed. === Test plan === 1. Apply Bug 41898 patches first. 2. Create a booking for a patron on a specific item. 3. Confirm the Patron bookings tab shows Edit, Cancel, and Checkout actions for the new booking; Biblio bookings page shows the same. 4. Click Checkout â confirm it pre-populates the checkout screen with the patron and item; confirm the due date defaults to the booking end_date. 5. Override the due date at checkout; confirm booking.end_date is updated to match. 6. Confirm the issued booking shows the due date and a checkout link in the Item column on both tabs. 7. Click Extend on the issued booking; select a new date; confirm both date_due and booking.end_date are updated. 8. Create a subsequent booking for the same item and confirm its start_date is blocked in the Extend date picker. 9. Advance the clock past a new booking's start_date; confirm the row receives the table-info highlight. 10. Advance past end_date; confirm the row receives the table-warning highlight. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 42998] New: Allow a requested due date when renewing a checkout via the REST API
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42998 Bug ID: 42998 Summary: Allow a requested due date when renewing a checkout via the REST API 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- Depends on bug 42997 (booking/checkout due date synchronisation). This patch extends the checkout renewal endpoints so API consumers can renew a checkout through to a specific date: - an optional request body may carry a due_date (RFC3339); it is used in place of the due date calculated from the circulation rules and is validated against any bookings for the item via CanBookBeRenewed. When the checkout is linked to a booking, AddRenewal keeps the booking end date in sync (bug 42997) - a new renewal_limit value is accepted in the x-koha-override header, skipping renewal count limits when AllowRenewalLimitOverride is enabled - intended for staff explicitly authorising an extension of a booked loan - the 403 error response now carries the CanBookBeRenewed error as a machine-readable error_code (e.g. 'booked', 'too_many') The requested due date is a body attribute rather than a query parameter or override: the POST creates a renewal resource and the date is data about that renewal. The existing 'seen' query parameter predates the current guidelines and has been left untouched. Both /checkouts/{checkout_id}/renewal and the newer /checkouts/{checkout_id}/renewals route to the same controller, so the body is accepted and documented on both. Test plan: 1. yarn api:bundle && restart_all 2. Run t/db_dependent/api/v1/checkouts.t -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15