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

[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 42608] New: Hold-shelf expiration over-extends when ExcludeHolidaysFromMaxPickUpDelay is on and useDaysMode=Dayweek
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 Bug ID: 42608 Summary: Hold-shelf expiration over-extends when ExcludeHolidaysFromMaxPickUpDelay is on and useDaysMode=Dayweek Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com When ExcludeHolidaysFromMaxPickUpDelay is on and useDaysMode is set to Dayweek, the pickup expiration date set for a hold by Koha::Hold::set_waiting is inflated by a whole week whenever the pickup window crosses a single (one-off) closure on a normally-open weekday -- for example a Bank Holiday Monday. Steps to reproduce ================== System preferences: ReservesMaxPickUpDelay = 6 ExcludeHolidaysFromMaxPickUpDelay = ON ExpireReservesOnHolidays = ON useDaysMode = Dayweek Branch calendar: - Sundays marked as a weekly closed day. - A single (one-off) holiday on a Monday two weeks out -- for example 2026-05-04 (the early May Bank Holiday). Trap a hold to waiting at that branch on Tuesday 2026-04-28. Actual result ============= expirationdate is set to 2026-05-12 -- a 14-day pickup window. Expected result =============== expirationdate should be 2026-05-06 -- a 6-open-day pickup window. The intent of ExcludeHolidaysFromMaxPickUpDelay is to give the patron the full ReservesMaxPickUpDelay count of *open* days to come and collect the item, by extending the window by one calendar day for every closed day that falls inside it. useDaysMode (Dayweek / Datedue / Calendar / Days) is a loan-due-date concept -- the patron picks no weekday for a hold pickup; staff trap the item, and the only thing that should influence the expiration date is how many open days the patron should get to collect. Wider example table =================== Same configuration as above. Sunday 3 May and Monday 4 May 2026 are closed at the branch. Comparison of current (buggy) vs expected expiration dates for each weekday a hold could be trapped that week: Hold trapped on Current (buggy) Expected ----------------- ----------------- ----------------- Mon 27 Apr 2026 Mon 11 May 2026 Tue 5 May 2026 Tue 28 Apr 2026 Tue 12 May 2026 Wed 6 May 2026 Wed 29 Apr 2026 Wed 13 May 2026 Thu 7 May 2026 Thu 30 Apr 2026 Thu 14 May 2026 Fri 8 May 2026 Fri 1 May 2026 Fri 15 May 2026 Sat 9 May 2026 In each case the expected expiration is `waitingdate + ReservesMaxPickUpDelay` open days, with Sun 3 May and Mon 4 May skipped (not counted toward the 6-day window). The current buggy expirations are all 14 calendar days from the trap date -- a whole extra week. Reproduction snippet ==================== use Koha::Calendar; use Koha::DateUtils qw(dt_from_string); # Test branch: Sundays weekly closed, single holiday 2026-05-04. my $cal = Koha::Calendar->new( branchcode => 'BR', days_mode => 'Dayweek', ); # Bug: prints 2026-05-12 (14 days). # Expected: 2026-05-06 (6 open days). say $cal->days_forward( dt_from_string('2026-04-28'), 6 )->ymd; Notes ===== Loan due dates calculated by Koha::Calendar::addDays under useDaysMode=Dayweek behave correctly -- the bug only surfaces on hold pickup expiration dates. A fix should not regress the loan due-date behaviour, which is the original purpose of the Dayweek mode (keeping a Friday-due loan due on a Friday over closures). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[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 42883] New: koha-dpkg docker image still builds with Debian 11
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42883 Bug ID: 42883 Summary: koha-dpkg docker image still builds with Debian 11 Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: cornelius.hertfelder(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Target Milestone: --- Hello, this docker image used for building custom Debian packages contains a build.sh which still uses Debian 11 Bullseye. This is independent of the Debian version of the docker image itself. https://hub.docker.com/r/koha/koha-dpkg/This is linked here in the first paragraph. >From build.sh: pbuilder create --use-network yes --distribution bullseye --mirror http://debian.csail.mit.edu/debian/ pbuilder execute --use-network yes --save-after-exec /pbuilder.sh --basetgz /var/cache/pbuilder/base.tgz Simply replacing bullseye with bookworm does not work, the build process fails. The deb package created with this command still works under Debian 12 bookworm, but I think it's not a clean solution. Wouldn't it be better to provide a .gitlab-ci.yml which can build the whole thing automatically? And avoid this pbuilder-container-inside-docker-container thing?` Regards Cornelius -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[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