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

[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

[Bug 42919] New: Suggestion duplicate warning erases suggestion info
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42919 Bug ID: 42919 Summary: Suggestion duplicate warning erases suggestion info Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- To recreate: 1. Make a suggestion that will trigger a duplicate warning, in KTD I like "Clothes, clothes, clothes, music, music, music, boys, boys, boys". 2. Fill out some other details, like notes and public notes. 2. The warning says "Click on "Confirm your suggestion" to ignore this message." 3. Notice none of the details are still there. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 43046] New: Checkbox labels in Currencies and EDI accounts have unnecessary colons
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43046 Bug ID: 43046 Summary: Checkbox labels in Currencies and EDI accounts have unnecessary colons Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Remove unnecessary colons from checkbox labels when adding/editing currencies and EDI accounts. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 42986] New: JS error when writing off selected charges
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42986 Bug ID: 42986 Summary: JS error when writing off selected charges Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- When you go to write off selected charges, there is an error in the console. To recreate : 1. In the staff interface, go to a patron's account 2. Go to Accounting > Create manual invoice 3. Fill out the manual invoice form with an amount 4. Click Save 5. Go to Make a payment 6. Click Write off selected 7. IMPORTANT : Open the browser console 8. Click Confirm --> In the console, there is an error 'Uncaught TypeError: can't access property "innerHTML", change is undefined' -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 42850] New: ILL requests stylesheet is not installed
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42850 Bug ID: 42850 Summary: ILL requests stylesheet is not installed Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- The ILL requests page includes css/ill-requests.css. This stylesheet is generated from koha-tmpl/intranet-tmpl/prog/css/src/ill-requests.scss and ignored by git. On a package/source install, the generated file is not copied into blib because Makefile.PL does not list it in the generated asset map. Asset.css cannot resolve it, warns "File not found : css/ill-requests.css", and returns no link tag. Steps to reproduce: 1. Use a clean package or source-style install built from current main. 2. Open /cgi-bin/koha/ill/ill-requests.pl in the staff interface. 3. Inspect the page source/head and the intranet log. Expected result: The page includes a link tag for css/ill-requests.css and the intranet log has no missing-asset warning for that file. Actual result: No css/ill-requests.css link tag is emitted and the intranet log warns: File not found : css/ill-requests.css. Technical note: This follows the generated asset install mapping pattern from bug 32609 and bug 38779. Bug 30200 added the generated stylesheet and template include, but the generated CSS was not added to Makefile.PL. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 42519] New: Terminology: branch should be library
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42519 Bug ID: 42519 Summary: Terminology: branch should be library Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: Academy Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Found while translating main: koha-tmpl/intranet-tmpl/prog/en/modules/admin/categories.tt:578 Your self-renewal can't be processed at this time. Please visit your local branch to complete your renewal. Also: for installations with only one library this might sound little odd, maybe just: visit your library? -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 43522] New: Add locale-aware address display to PatronSelect option rows
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43522 Bug ID: 43522 Summary: Add locale-aware address display to PatronSelect option rows Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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 Depends on: 43518 Target Milestone: --- Bug 43518 added a plain city/country summary to PatronSelect's matching-option rows (patronToOption()'s _city/_country fields), deliberately simplified from the legacy autocomplete's address display. The legacy patron_autocomplete() dropdown (staff-global.js) shows a fully formatted address via $format_address(), which is not a static function -- it is generated per-page by js-patron-format-address.inc, a Template-Toolkit include that embeds a server-resolved authorised-values map (AuthorisedValues.Get('ROADTYPE')) and picks between locale-specific address formatters (US style, DE style, etc., driven by a syspref). Reproducing that faithfully client-side needs either an additional client-side authorised-value lookup or a duplicated set of locale-specific formatters -- a materially bigger lift than the rest of bug 43518's parity work, so it was deferred rather than descoped silently. This bug tracks doing that properly, if/when there is a concrete need for it in a PatronSelect-based screen: 1. Decide how road-type and other authorised-value-backed address fields get resolved client-side (e.g. embed via the patron API response, or fetch authorised values through the existing AVAPIClient). 2. Port (or share) the locale-specific address assembly rules from js-patron-format-address.inc. 3. Extend patronToOption() with a richer _address field (or similar) and update PatronSelect.vue's option row template. Test plan: 1. Apply on top of bug 43518. 2. Configure at least two different address-format locales (e.g. via the relevant syspref) and confirm PatronSelect's option rows render the address the same way the legacy patron_autocomplete() dropdown does for each. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43518 [Bug 43518] Add a reusable PatronSelect Vue component with patron search -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43521] New: Reuse PatronSelect's patron name formatter in patron-format.js
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43521 Bug ID: 43521 Summary: Reuse PatronSelect's patron name formatter in patron-format.js Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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 Depends on: 43518 Target Milestone: --- Bug 43518 added formatPatronName() (vue/utils/patron-options.js), a pure, framework-free reimplementation of $patron_to_html()'s (patron-format.js) name-assembly rules -- preferred_name/firstname, middle_name, other_name, showDiffFirstname, invertName, hidePatronName, displayCardnumber, and the no-name fallback -- but returning plain text for native Vue rendering instead of an HTML string. That means Koha now has two independent implementations of the same formatting rules: $patron_to_html() (used across ~15+ .tt/.js consumers such as catalogue/detail.tt, holds.js, ill-list-table.js, checkout_renewals_modal.js) and formatPatronName() (used by PatronSelect and anything that calls patronToOption()/resolvePatronOption()). If the formatting rules change, both need updating, and nothing enforces that. This bug tracks having $patron_to_html() delegate its field-by-field decisions to formatPatronName(), so there is exactly one source of truth. The complication: patron-format.js is loaded as a plain, unbundled <script> (via [% Asset.js("js/patron-format.js") %] in js_includes.inc) -- it is not part of the rspack build that compiles the vue/ tree, so it cannot use a normal ES import. The realistic approach is to load the shared formatter via <script type="module"> (natively supported, no bundler needed), with the module assigning itself to window for patron-format.js to call. Given $patron_to_html() is only ever invoked from event handlers/callbacks (not at page-parse time), the deferred nature of module scripts should not introduce a race, but this needs verifying across its real consumers. $patron_to_html() would keep its HTML-building responsibilities (title markup, url wrapping, escaping) and delegate only the name-assembly decisions to formatPatronName(). Test plan: 1. Apply on top of bug 43518. 2. Identify pages using $patron_to_html() with each of: invert_name, hide_patron_name, display_cardnumber, showDiffFirstname, and a patron with no visible name (restricted view). 3. Verify rendered patron names are unchanged before and after this change for each case. 4. Run the existing patronOptions_spec.ts and PatronSelect_spec.ts Cypress component specs. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43518 [Bug 43518] Add a reusable PatronSelect Vue component with patron search -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 39208] New: printoverdues.sh requires unavailable cli tool
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39208 Bug ID: 39208 Summary: printoverdues.sh requires unavailable cli tool Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexander.wagner(a)desy.de QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz `printoverdues.sh` relies on `xhtml2pdf` for the conversion of a HTML document to a printable PDF version of said document. At time of writing, this tool dropped out of Debian (bookworm) and Ubuntu stable and sometimes older releases including backports and the like. Debian oldstable still keeps it, but no upstream releases beyond. This may endanger the functionality in Koha upstream. Possible solutions: - Manual installation outside the package management (and bugfixing) of the distribution via `pip`. That would also require a suitable documentation. - Use an alternative tool chain within the distributions (e.g. pandoc, if heading for a swiss army knife of format transformations. For PDF pandoc would require latex as "helper"). Note that `printoverdues.sh` is referred to explicitly in the implementation checklist. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19