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

[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

[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