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

[Bug 42901] New: Dark mode for Vue components in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42901 Bug ID: 42901 Summary: Dark mode for Vue components in the staff interface 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 patch builds on the dark-mode foundation (bug 42898) to migrate the staff-client Vue components to the Koha colour tokens, so their styling flips with the Light/Dark/Auto theme switcher, matching the rest of the interface. Areas covered: * The module dashboard - widget cards, the picker, the empty drop placeholder and the drag-and-drop highlight. * The ERM counts widget pills. * Left-hand menus and the SIP2 management menu (including disabled entries, which stay muted but legible). * The ERM usage-statistics report table borders. * The vue-select dropdowns used across ERM and ILL forms (e.g. the agreement and request edit screens). Light mode is unchanged. Decorative brand accents (the green legend hover and blue caret on the resource form) are intentionally left as-is, as they read correctly in both themes. Depends on: bug 42898 Test plan: 1) Apply the patch (after bug 42898) and rebuild the assets (yarn js:build). 2) Light mode regression. With the theme set to Light, open: the module dashboard (add/reorder a widget), the ERM home page (counts widget), the SIP2 management page, an ERM usage-statistics report, and an ERM agreement or ILL request edit form (the searchable dropdowns). Everything should look exactly as before. 3) Dark mode. Switch the header control to Dark and revisit the same screens. Confirm: - widget cards and the dashboard empty/drop placeholder are dark with readable text; - the ERM count pills and left-menu entries (including disabled ones) are legible; - the usage-statistics table borders are visible against dark cells; - the searchable dropdowns (closed control and open list, including a disabled/selected option) are dark and readable. 4) Switch back to Light and confirm the components return to normal. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 42900] New: Dark mode for tables and status rows
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42900 Bug ID: 42900 Summary: Dark mode for tables and status rows 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 patch builds on the dark-mode foundation (bug 42898) to complete the staff-client table styling for dark mode. The table grid, the colour-coded status rows and the DataTables chrome now flip with the Light/Dark/Auto theme switcher. Areas covered: * The table grid itself - header row, striped rows and cell borders. * Status-coloured rows - overdue, on issue, on hold, in transit, lost and warning rows. Each keeps its meaning (yellow/green/blue/red) but uses a pale background with dark text in light mode and a dark background with pale text in dark mode, so it stays legible either way. Rows that are meant to shout (highlighted/warned/selected) keep their bold solid colour. * DataTables chrome - the "processing" overlay, paging buttons, the column-visibility and export menus, the per-column filter inputs and the table search box, and selected-row highlighting. Light mode is unchanged. The brand-coloured export-button icons are left as-is, as they are part of Koha's identity rather than surface colour. Depends on: bug 42898 Test plan: 1) Apply the patch (after bug 42898) and rebuild the CSS (yarn css:build). 2) Light mode regression. With the theme set to Light, open pages with busy tables: a patron's checkouts (rows showing on-issue / overdue / on-hold / in-transit), a circulation page with warnings, and any list with a paging footer (sort a column, open the column-visibility menu, open an export menu). Everything should look exactly as before. 3) Dark mode. Switch the header control to Dark and revisit the same tables. Confirm: - the table grid (headers, stripes, borders) is dark and readable; - each status row is still recognisably its colour but now dark with pale text, and the different statuses remain easy to tell apart; - selected rows are highlighted legibly (not pale-on-dark); - the paging buttons, column-visibility menu and export menu are dark with readable labels. 4) Switch back to Light and confirm the tables return to normal. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 36028] New: When AutoLocation is on there is no error message when the user is at the wrong branch
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36028 Bug ID: 36028 Summary: When AutoLocation is on there is no error message when the user is at the wrong branch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: michael.hafen(a)washk12.org QA Contact: testopia(a)bugs.koha-community.org When AutoLocation is on the user is supposed to be restricted to logging in at their branch. If the user is at a different branch and logs in, they get past the login page, but any action returns them to the login page. They should be returned directly to the login page with an error message. Test plan: 1. select a branch with branchip set to match the ip you are testing from. 2. select a user at a different branch. 3. login. 4. observe that there is no error, and login appears to succeed, but doesn't actually. 5. apply patch and restart services. 6. login again. 7. observe that the login page comes back immediately with an error message about AutoLocation being on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 35890] AutoLocation system preference + setting the library IP field - can still login and unexpected results
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35890 Michael Hafen <michael.hafen(a)washk12.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michael.hafen(a)washk12.org --- Comment #30 from Michael Hafen <michael.hafen(a)washk12.org> --- *** Bug 36028 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42896] New: Add ability to manually resend checkout receipt, slip, or summary email from patron record
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42896 Bug ID: 42896 Summary: Add ability to manually resend checkout receipt, slip, or summary email from patron record Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbaker(a)aclsys.org QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- Koha sends a checkout receipt email to patrons at the time of checkout, provided the patron has a valid email address and appropriate messaging preferences enabled. Once the transaction is complete, however, staff have no native way to resend or re-trigger this email on demand. When a patron did not receive, cannot find, or requests a copy of their checkout receipt or a summary of their checkouts, staff are left without a built-in option to help them. Common scenarios where staff need to resend a checkout receipt include: •The email was sent to a wrong or outdated address •The email was caught by a spam filter •The patron's inbox was full at the time of checkout •The patron lost or deleted the email and needs a copy •The patron requests a summary of their current checkouts by email Koha already provides a manual "Email" button for some financial transaction lines. This request extends that same pattern to circulation checkout receipts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 42890] New: EDI INVOIC processing should create/link items in aqorders_items when AcqCreateItem=receiving
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42890 Bug ID: 42890 Summary: EDI INVOIC processing should create/link items in aqorders_items when AcqCreateItem=receiving 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When AcqCreateItem is set to 'receiving', items are expected to be created during the acquisitions receiving step. In a non-EDI workflow this happens via the staff UI (acqui/receive.pl -> ModReceiveOrder). In an EDI workflow, processing the INVOIC message is the functional equivalent of that receiving step -- the goods are confirmed shipped, prices and quantities are reconciled, and the order lines are closed. However, Koha::EDI::receipt_items (EDI.pm ~L500) currently only updates items that already exist in aqorders_items (i.e. created at ordering time). When AcqCreateItem=receiving, no aqorders_items rows exist at the point the INVOIC is processed, so: 1. The GIR segment data (branch, barcode, etc.) is silently discarded -- items are never created. 2. aqorders_items remains empty, so physical receipt tracking (Bug 40932 -- "automatic invoice closing on physical item receipt") cannot function for EDI+receiving workflows. What should happen: When AcqCreateItem=receiving and an EDI INVOIC is processed, receipt_items should: 1. Create catalogue items from the GIR segment data (mirroring what ModReceiveOrder does for the UI path). 2. Populate aqorders_items rows linking the new items to their order lines, with the 'received' column left NULL. The 'received' timestamp should remain unset at this stage: the INVOIC represents the vendor confirming shipment, not confirmed physical arrival. Physical arrival is recorded at circulation check-in, which stamps 'received' and (via Bug 40932) triggers invoice auto-close. Steps to reproduce: 1. Set AcqCreateItem = receiving. 2. Create an order via a vendor with EDI enabled. 3. Import an INVOIC message for that order. 4. Observe: no items are created; aqorders_items remains empty; subsequent check-in cannot stamp receipt or auto-close the invoice. See also: Bug 40932 (automatic invoice closing on physical item receipt -- scoped to AcqCreateItem=ordering precisely because of this gap). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 19133] New: REST API: Password recovery
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19133 Bug ID: 19133 Summary: REST API: Password recovery Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Add password recovery functionality to REST API. Support third party integrations for reset link: by default, use existing password recovery page in Koha OPAC, but also have the ability to link patron to external system to complete their password recovery. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 34629] New: SCO User cannot hold change pickup location branch when OPACAllowUserToChangeBranch is endabled
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34629 Bug ID: 34629 Summary: SCO User cannot hold change pickup location branch when OPACAllowUserToChangeBranch is endabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Turn on the SCO module and enable 'OPACAllowUserToChangeBranch'. 2. Place a hold for a user and then login to the SCO module 3. Under the hold tab try to change the pick up location for an item 4. Notice you are redirected to '/cgi-bin/koha/opac-modrequest.pl' and forced to log in again. 5. Re login to the SCO module and notice the pickup location for thta branch was not updated. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 1937] Scan barcode with webcam
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1937 --- Comment #13 from Mathieu Saby <mathsabypro(a)gmail.com> --- I am not a dev, but from Chatgpt's anwser it seems it should not be difficult to implement that in JS, without the need of a Andoid or IOS app. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 41239] New: "cite" feature should display more MARC21 author subfields
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41239 Bug ID: 41239 Summary: "cite" feature should display more MARC21 author subfields Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Currently, the OPAC "cite" feature only displays the MARC21 author 100$a, 110$a, 111$a, 700$a, 710$a and 711$a subfields. However, it is standard MARC21 cataloguing practice to also fill in the 110$b and 710$b subfields - as well as the 111 and 711 $b, $c, $d and $n subfields. The "cite" feature should display the information saved in these other subfields. -- You are receiving this mail because: You are watching all bug changes.

1 4