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

[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

[Bug 23080] New: Item search: To Call Number Search Not Inclusive
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23080 Bug ID: 23080 Summary: Item search: To Call Number Search Not Inclusive Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: jyorio(a)esilibrary.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When conducting an item search and specifying a "To Call Number", the results are not inclusive of the call number specified, contrary to the "(inclusive)" on the form. I have seen this on systems with Library of Congress call numbers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 42710] New: Purchase suggestion creation form (staff interface) no longer defaults to logged-in library
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42710 Bug ID: 42710 Summary: Purchase suggestion creation form (staff interface) no longer defaults to logged-in library Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When staff create a purchase suggestion in the Suggestions module, the Library selection under 'Acquisition information' now defaults to 'Any' instead of the logged-in library. This will cause many libraries to have suggestions that aren't affiliated with a location, especially single-location libraries who haven't had to update that field with every suggestion. It should either default to the logged-in library, or there should be a system preference for libraries to decide whether they want it to default to the logged-in library or to 'Any'. This is a change at least between 25.05 and 25.11, but may also be a change between 25.11.xx and 25.11.04. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 42498] New: Accessibility - Page tabs/pagination on results in opac gives "Aria state or property has invalid value"
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '26

22 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42498 Bug ID: 42498 Summary: Accessibility - Page tabs/pagination on results in opac gives "Aria state or property has invalid value" Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: danielle.elder(a)law.utexas.edu QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org I am working on the accessibility of our public catalog. One error flagged on in our Kioha catalog is "ARIA state or property has invalid value." Then it lists this html. 1. That "active" is not a valid value of aria-current and 2. that it is applied to the list and to the list elements (so twice.) <li class="page-item active" aria-current="active"> <a class="page-link" href="#" aria-label="Current page: Page 1" aria-current="true">1</a> </li> Example page: https://tallons.law.utexas.edu/cgi-bin/koha/opac-search.pl?q=an:2414 aria-current does NOT accept arbitrary values like "active". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18