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

[Bug 8658] Don't display patron attributes which have been limited to another patron category
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8658 Sara Brown <sbrown(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sbrown(a)bywatersolutions.com --- Comment #3 from Sara Brown <sbrown(a)bywatersolutions.com> --- This is still an issue in 26.05.04. Even if a patron never belonged to a category to which an attribute applied (so, the field is blank for that patron), the attribute still shows in their OPAC account. This may become a problem for more libraries now that patrons can renew their accounts online via the OPAC, since doing so requires that patrons verify their account details. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 41702] New: Update MARC21 authority frameworks to Update 41 (December 2025)
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41702 Bug ID: 41702 Summary: Update MARC21 authority frameworks to Update 41 (December 2025) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org https://www.loc.gov/marc/authority/adapndxf.html UPDATE 41 CHANGES ■ New content designators: Subfields $i Relationship information (R) in 368 (Other Attributes of Person or Corporate Body) $i Relationship information (R) in 376 (Family Information) $i Relationship information (R) in 381 (Other Distinguishing Characteristics of Work or Expression) $4 Relationship (R) in 368 (Other Attributes of Person or Corporate Body) $4 Relationship (R) in 376 (Family Information) $4 Relationship (R) in 381 (Other Distinguishing Characteristics of Work or Expression) ■ Changes in content designator names and definitions: Subfield $2 Source redescribed in 368 (Other Attributes of Person or Corporate Body) Appendix HData Provenance Subfields: Data Provenance Code List moved to https://www.loc.gov/standards/valuelist/dataprov.html. New codes bcp47 and dpets added. ■ Fast-track changes: Subfields $g Conversion date renamed Conversion date/time and redescribed in 884 (Description Conversion Information) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 43797] New: Adding Item Number to holdings table
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43797 Bug ID: 43797 Summary: Adding Item Number to holdings table Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: sam.young(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 42001] New: Add duplicate purchase order number detection on EDI quote import
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42001 Bug ID: 42001 Summary: Add duplicate purchase order number detection on EDI quote import Initiative type: --- Sponsorship Sponsored 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 CC: hdunne-howrie(a)westminster.gov.uk, kyle(a)bywatersolutions.com, testopia(a)bugs.koha-community.org Depends on: 40383, 41297 Blocks: 38195 EDIFACT quote processing will detect duplicate purchase order numbers and block basket creation from those orders when using the po_is_basketname setting for EDIfact processing. We should add the ability to notify the supplier, and alert library staff. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38195 [Bug 38195] EDI/Edifact classes should use Koha::Objects instead of plain DBIC https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40383 [Bug 40383] Modernise the EDIFACT Message display modal https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41297 [Bug 41297] Add duplicate invoice number detection on EDI invoice import -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 39215] New: EDIFACT quote files should skip orders that cannot be processed rather than failing to complete
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39215 Bug ID: 39215 Summary: EDIFACT quote files should skip orders that cannot be processed rather than failing to complete Change sponsored?: --- Product: Koha Version: unspecified 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)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When loading an EDIFACT quote file, if the process finds problematic data (usually a mismatched LLO - Branchcode or other enumerated coded field) the load process gets stuck and displays as 'Processing' in the EDFACT messages page. This usually means that the remainder of the quotes in the file have to be manually corrected and is it's currently difficult to debug by library staff. It would be preferable if the process could skip, and report any problem data but complete all other quotes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 41852] New: Modernize EDI support in Koha
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41852 Bug ID: 41852 Summary: Modernize EDI support in Koha Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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 A collector bug for all the modernization and maintenance work we've been undertaking in EDIfact support for Koha -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 21459] New: Allow migrating requests between ILL and purchase suggestions
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21459 Bug ID: 21459 Summary: Allow migrating requests between ILL and purchase suggestions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no One library would like to be able to take a purchase suggestion and turn it into an ILL request. And to take an ILL request and turn it into a purchase suggestion. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 43782] New: GenerateCSRF caches token with global key causing cross-session CSRF 403 errors on Plack workers
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43782 Bug ID: 43782 Summary: GenerateCSRF caches token with global key causing cross-session CSRF 403 errors on Plack workers Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: johan(a)imcode.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 35955 (commit 108c955ea) introduced caching of the CSRF token in Koha::Template::Plugin::Koha::GenerateCSRF using Koha::Cache::Memory::Lite. The cache uses a static key "CSRF-TOKEN" shared across all sessions served by a Plack worker. Because Koha::Cache::Memory::Lite is a package-level in-process hash that is NOT flushed between requests (despite what its documentation says), the cached token from the first session persists and is returned to all subsequent sessions on the same worker process. When session B receives session A's token and submits a form, CSRF validation compares the token against session B's session_id — it was generated for session A — and returns 403. Symptoms: - Intermittent "Invalid CSRF token" 403 errors - Reproducible as "first request after idle period" (e.g. every morning) - Affects both intranet login and OPAC self-checkout (sco-main.pl) - Works on the second attempt (the second request gets the correct session's token because the old cached value is still returned — but a reload generates a new session and fresh token) The 8-hour CSRF_EXPIRY_HOURS (Bug 17110) made the window smaller. After Bug 42924 increased it to 168 hours, a worker running more than ~7 days could additionally serve a near-expired token with less than 1 hour remaining. Note: Bug 18124 correctly made CSRF tokens cryptographically session-specific. The cache layer introduced by Bug 35955 bypasses that protection. The issue can be hard to reproduce, so I have been using reports from customers to piece this together. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 43809] New: illreq_created statistic is not recorded for ILL requests created by plugin backends
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43809 Bug ID: 43809 Summary: illreq_created statistic is not recorded for ILL requests created by plugin backends Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41528] New: Import EDI invoices without changing to received status
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41528 Bug ID: 41528 Summary: Import EDI invoices without changing to received status Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lhilleary(a)wrl.org QA Contact: testopia(a)bugs.koha-community.org It would be ideal if we could import an EDI invoice without everything automatically reverting to received. If we could just have an invoice arrive for a specific shipment, import it, and then go through to check off each item that is received in the shipment, that would be better. Right now, we have the setting to not import automatically to avoid status changes to newly acquired before we even get the items; now, we manually import. However, even doing this presents a problem as once received, the price cannot be changed without un-receiving a title if needed and location information is not visible (when ordering multiple copies of a title for multiple branches). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4