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

[Bug 43432] New: ReportsExportLimit system preference - clarify description
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43432 Bug ID: 43432 Summary: ReportsExportLimit system preference - clarify description Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- The current description for this system preference uses "records". It actually controls the number of rows downloaded, which may or may not be records. Current description: Download a maximum of _____ records when downloading from the reports module. NOTE: Only a positive value will enforce a limit. A specific limit in the report overrides this setting. The system preference description should be updated to reflect this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 43346] New: MarkLostItemsAsReturned does not work without userenv set
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43346 Bug ID: 43346 Summary: MarkLostItemsAsReturned does not work without userenv set Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- If MarkLostItemsAsReturned is called when there is no userenv set it fails because "checkin_library" is set from userenv. $issue->checkin_library( C4::Context->userenv->{'branch'} ); I have developed an Opac payment plugin with a callback to a public REST endpoint, that is authenticated by a cryptographic token (similar to the easy payments plugin). This callback is executed without userenv and will therefore occasionally fail. As the item is lost, it is unclear what the checkin_library should signify. Setting it the the branchcode on the issue seems just as appropriate. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 43330] New: C4::Tags fails to compile when TagsExternalDictionary is configured
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43330 Bug ID: 43330 Summary: C4::Tags fails to compile when TagsExternalDictionary is configured Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When the TagsExternalDictionary system preference contains a value, C4::Tags fails to compile with: Undefined subroutine &C4::Tags::check_install called at C4/Tags.pm line 44. This can cause HTTP 500 errors throughout the staff interface on pages which load C4::Tags, including the staff home page, catalog detail pages, and Tools. Observed on Koha 25.11.06. The problem appears to be caused by the order in which check_install is imported in C4/Tags.pm. Currently C4/Tags.pm contains: use Modern::Perl; use base 'Exporter'; use C4::Context; BEGIN { ... my $ext_dict = C4::Context->preference('TagsExternalDictionary'); if ( $ext_dict && !check_install( module => 'Lingua::Ispell' ) ) { warn "Ignoring TagsExternalDictionary, because Lingua::Ispell is not installed."; $ext_dict = q{}; } ... } but Module::Load::Conditional is loaded later: use Module::Load::Conditional qw( check_install ); Because the check occurs inside a BEGIN block, the BEGIN block is executed during compilation before Perl reaches the later `use Module::Load::Conditional` statement. As a result, when TagsExternalDictionary has a non-empty value, Perl attempts to call check_install() before that function has been imported. When TagsExternalDictionary is empty, the problem is hidden because this expression short-circuits: $ext_dict && !check_install(...) so check_install() is never called. To recreate: 1. Set the TagsExternalDictionary system preference to a non-empty value, for example: /usr/bin/ispell 2. Restart Plack if necessary. 3. Visit a staff interface page which loads C4::Tags, such as the staff home page or a bibliographic detail page. OR reproduce directly from the command line: perl -MC4::Tags -e 'print "C4::Tags loaded OK\n"' 4. Observe: Undefined subroutine &C4::Tags::check_install called at C4/Tags.pm line 44. BEGIN failed--compilation aborted at C4/Tags.pm line 53. Compilation failed in require. BEGIN failed--compilation aborted. 5. Clear TagsExternalDictionary and clear/update the system preference cache. 6. Run the same command again. 7. C4::Tags loads successfully. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 43225] New: Renewal confirmation message formatting is missing punctuation and space
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43225 Bug ID: 43225 Summary: Renewal confirmation message formatting is missing punctuation and space Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- The new renewal confirmation message introduced by Bug 23415 is missing a period and space between the amount due and the second sentence. It currently reads: "The patron has a debt of [amount]Are you sure you want to renew checkout(s)?" It should be, with the period and then space after the amount due: "The patron has a debt of [amount]. Are you sure you want to renew checkout(s)?" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 38638] New: Offer the option to set non-priority option when placing multiple holds
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38638 Bug ID: 38638 Summary: Offer the option to set non-priority option when placing multiple holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 22789 When placing multiple holds in the staff interface there isn't an option to set the holds as non-priority. As far as I know there's not a technical reason not to include the option? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22789 [Bug 22789] Establish non-priority holds -- You are receiving this mail because: You are watching all bug changes.

1 14

[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 #955 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- (In reply to Jonathan Druart from comment #953) > 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? Many thanks for this! Went through the list, and made changes accordingly. Here is where I landed: 1: Agreed, fixed 2: logged_in_user is not available to circulation triggers as it stands. I could make it available, but it also is a lot more data than what circulation triggers really needs. That said we do need to move from consulting the logged in library to looking for the logged in user’s home library instead - and that much is fixed (see commit message). 3: Agreed, fixed 4: I think we could extract code and collapse guard clauses 2 and 3 - but reckon that's a later follow-up? Re-tests - I’m not seeing any that check the permissions logics and 403s either (part of this is on me, I spotted the missing clause, added it, and forgot to update the tests accordingly, my bad!) -> added them. 5: The comment between those two lines reads “It may still be present in DBs that pre-date the atomic update.” I don’t know if you’ve seen it (won’t come up if grepping I don't think?). Does that answer it? I can ask Martin about it otherwise. 6-8: Agreed, fixed. 9: left untouched for now. “” is ‘No letters' where admins explicitly want nothing sent for this context, while null / undefined indicates no override, fall back to the less specific rule set. Where ‘No letters’ is set, we don’t display the transport type options - hence the explicit '' check. I think some cases can definitely be simplified in a follow up (which can be included as preparation for bug 39756. I do remember running into issues much earlier on when I did try to simplify - I don’t mind having another go, but I do think it’d be better in a follow-up. 10: best practice: I don’t think so - but I do think it’s a step in that direction (the direction of travel so far had been to remove duplicate code, prevent redundant data (re)loads, remove duplicated logic, etc). Further refactoring into more specialised components will be beneficial. 39756 (long overdue cron) can certainly take that refactoring further. Thoughts? I’ll happily stand corrected on anything I got wrong! -- 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 #954 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- Created attachment 205599 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=205599&action=e… Bug 10190: (QA follow-up): fixes phase five 1. apply html filter to letters so notice names are escaped (must be done in attribute so the JSON format of the letters can be parsed). 2. fix a correctness issue where the frontend was pinning the logged in library instead of the logged in user's home library, which would have led to 403s (correct) when saving rules. Since the library dropdown is deliberately disabled unless a user has the manage_circ_rules_from_any_libraries permission, the user would then have needed to use 'Set library' to match their home library to fix this. Prevent the issue by setting the library to the user's home library. Also rename the variable to user_library_id. 3. list_rules correctly references /api/v1/circulation_rules/kinds 4. make untranslatable strings translatable 5. swap svg for font-awesome icon. 6. avoid css duplication: - remove dead / unused scoped css (leftover from an early component extraction) - import vue.css and only leave the minimal override required. 7. improve set_rules test coverage: add tests for manage_circ_rules / manage_circ_triggers separation Test plan: 1) Administration > Circulation triggers: notice the 'Letter' dropdowns list circulation notices as "name (code)" and offer 'No letter'. (no regression) 2) Give a staff user 'catalogue' + 'manage_circ_triggers' only, with home library A. Log in as them, 'Set library' to B, and open Administration > Circulation triggers. Notice the view is pinned to A, and that adding and editing a trigger saves without a 403. (behaviour is now correct) 3) GET /api/v1/circulation_rules?rules=nosuchrule - notice the error points at /api/v1/circulation_rules/kinds. (behaviour is now correct) 4) Run 'gulp po:update --lang fr-FR'. Notice 'Add new trigger {triggerNumber}', 'No letter' and 'any' now appear in misc/translator/po/fr-FR-messages-js.po (behaviour is now correct) 5) Edit a trigger. Notice the delay's reset button is an 'x' inside the input, left of the chevrons, and clears the delay; the letter's reset button does the same for the notice. (no regression) 6) Notice no visual regression across the list, add, edit, reset and delete screens - select widths, chevrons and modals unchanged. Also run t/db_dependent/api/v1/circulation_rules.t Assisted-by: Claude Opus 5 (Anthropic) Sponsored-by: Glasgow Colleges Library Group <https://library.cityofglasgowcollege.ac.uk> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40167] New: Curbside pickups - Show link if not configured
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40167 Bug ID: 40167 Summary: Curbside pickups - Show link if not configured Change sponsored?: --- 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Right now, it displays a warning message when you navigate to Circulation > Curbside pickups, but don't have them configured for the current branch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[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 Eric Phetteplace <ephetteplace(a)cca.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|ephetteplace(a)cca.edu | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43524] New: Vue modals should not close on Escape while focus is inside a form control
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43524 Bug ID: 43524 Summary: Vue modals should not close on Escape while focus is inside a form control Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface 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 Target Milestone: --- This bug proposes generalizing an improvement made on bug 41129 (the Vue rewrite of the booking modal) to all Vue-based modals in the staff interface that contain a form or other interactive elements. Currently, Vue modals built on Bootstrap's modal component (role="dialog", keyboard: true by default) close immediately on Escape regardless of where focus is. This means a librarian who presses Escape to, say, close an open dropdown, clear an autocomplete, or back out of an input while editing a form loses the whole modal (and any unsaved data in it) instead of the smaller, expected interaction. On bug 41129, BookingModal.vue and BookingCalendar.vue were given their own Escape handling: the modal takes over "keyboard: false" on the Bootstrap instance and, in a captured keydown handler, checks whether the event target is an editing control (input, select, textarea, [contenteditable], or a v-select). If it is, the first Escape just moves focus back to the modal container rather than closing; a second Escape (now with focus outside any control) closes it. A focusout handler also recovers focus to the modal if a control blurs to document.body, so Escape keeps working reliably even after that. This logic currently lives only in BookingModal.vue/BookingCalendar.vue. Other Vue modals in the codebase -- the shared Dialog.vue component (confirmation/warning/component dialogs used throughout the staff interface), EHoldingsEBSCOPackageAgreements.vue, and PatronSelfRenewal.vue -- still rely on Bootstrap's default behaviour and close on the first Escape no matter what has focus. This bug asks to extract the pattern from bug 41129 into a shared, reusable piece (e.g. a composable such as useModalEscape, or logic folded into a common modal wrapper) so any Vue-based modal containing a form or other interactive elements gets the safer step-out-first Escape behaviour for free. Test plan: 1. Open a Vue-based modal containing a form (e.g. the booking modal on bug 41129, or Dialog.vue's confirmation dialog with inputs). 2. Focus a text input, select, or v-select inside the form. 3. Press Escape. Expected: focus steps out of the control (back to the modal) without closing it. 4. Press Escape again. Expected: the modal closes. 5. Confirm the same reusable behaviour is available/applied to modals outside the booking workflow, not re-implemented per component. See bug 41129 (comments "Own Escape handling in the booking modal" and "Keep focus inside the modal after a blur") for the reference implementation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4