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

[Bug 43535] New: Support matching EDIFACT invoice lines to orders via RFF+SLI
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43535 Bug ID: 43535 Summary: Support matching EDIFACT invoice lines to orders via RFF+SLI 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 Depends on: 43534 Target Milestone: --- Koha::Edifact::Line already parses the RFF+SLI segment (supplier's unique order line reference number) into orderline_reference_number for both QUOTES and INVOIC messages. However, Koha::EDI's process_invoice only ever matches an incoming invoice line to an aqorders row via RFF+LI (Koha's own internal ordernumber, which the supplier is expected to echo back because Koha sent it in the original EDIFACT ORDERS message). If RFF+LI is missing, or was never set in the first place, the invoice line is skipped and logged as an error - even in cases where RFF+SLI carries a vendor reference that could be matched against aqorders.suppliers_reference_number. Use case: Vendors such as GOBI/YBP support ordering via MARC file import (Koha's MarcFieldsToOrder workflow, see bug 43534) rather than via EDIFACT ORDERS, yet still return EDIFACT INVOIC invoices referencing their own order/line ID via RFF+SLI (e.g. the GOBI order ID). Because Koha never sent an ORDERS message for those lines, there is no RFF+LI value the vendor can echo back, so the invoice lines currently cannot be auto-matched at all. Bug 43534 proposes capturing that vendor reference into aqorders.suppliers_reference_number / suppliers_reference_qualifier at MARC-order time. This bug is to add a fallback in Koha::EDI's invoice processing: when RFF+LI does not resolve to an aqorders row, attempt to match the invoice line to an order via RFF+SLI (orderline_reference_number) against aqorders.suppliers_reference_number. Depends on bug 43534. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43534 [Bug 43534] Allow MarcFieldsToOrder to map a MARC field to supplier's reference number/qualifier -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 43534] New: Allow MarcFieldsToOrder to map a MARC field to supplier's reference number/qualifier
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43534 Bug ID: 43534 Summary: Allow MarcFieldsToOrder to map a MARC field to supplier's reference number/qualifier 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: --- This enhancement extends the MARC Orders workflow (Koha::MarcOrder, driven by the MarcFieldsToOrder / MarcItemFieldsToOrder system preferences) to allow mapping a field on the incoming MARC order record to the existing aqorders.suppliers_reference_number and aqorders.suppliers_reference_qualifier columns. Currently those two columns are only ever populated by the EDIFACT quote-to-order flow (Koha::EDI, when an order is created from a supplier's QUOTES message), using the reference value the supplier returned in RFF+QLI or RFF+SLI. Koha::MarcOrder.pm has no equivalent mapping target, so an order created by staging a MARC file from a vendor can never record that vendor's own unique identifier for the order line. Use case: Vendors such as GOBI/YBP can supply MARC order records for import via MarcFieldsToOrder, and separately send EDIFACT INVOIC (invoice) messages for those same orders, quoting their own unique order/line reference (e.g. a GOBI order ID) in RFF+SLI. If Koha could capture that same vendor reference at MARC-order time into suppliers_reference_number / suppliers_reference_qualifier, it would become possible to match invoice lines back to the correct aqorders row using the vendor's own ID, rather than relying solely on Koha's internal ordernumber (RFF+LI) being echoed back correctly by the vendor. This bug is a prerequisite for a related enhancement to add RFF+SLI matching support to EDI invoice processing (Koha::EDI). Suggested implementation: - Add a mapping option in the MarcFieldsToOrder (and/or MarcItemFieldsToOrder) YAML syntax for suppliers_reference_number and suppliers_reference_qualifier. - Have Koha::MarcOrder read this mapping when building the order hash passed to Koha::Acquisition::Order->new / ->insert, alongside the other mapped fields. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 19501] New: New list category to restrict specific lists to staff & hide from OPAC
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19501 Bug ID: 19501 Summary: New list category to restrict specific lists to staff & hide from OPAC Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: Jeremy.evans(a)nibsc.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We are creating various lists of titles that need to be hidden from view in the OPAC for the time being but other staff members need to see them. At the moment the options are Public or Private so this won't do what we require. We would like an additional list category selection of Staff so that those lists are then visible in the staff client (& presumably also to anyone who logs into the OPAC with a staff permissions login) but are not publicly visible in the OPAC. The intention is that multiple staff members may need to add items to some of these lists. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 54

[Bug 23005] New: Specify notice language for vendors
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23005 Bug ID: 23005 Summary: Specify notice language for vendors Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: mbarham(a)birzeit.edu QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- right now, there is no way to specify notices language for vendors. (it is available for Patrons) it will be great if this will be added. regards -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 38207] New: Add vendor payment methods
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38207 Bug ID: 38207 Summary: Add vendor payment methods Change sponsored?: --- 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: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org It would be useful to identify the payment methods for a vendor, ideally as authorised values -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 49

[Bug 43537] New: Allow MarcFieldsToOrder/MarcItemFieldsToOrder mappings to be configured per MARC order account (vendor)
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43537 Bug ID: 43537 Summary: Allow MarcFieldsToOrder/MarcItemFieldsToOrder mappings to be configured per MARC order account (vendor) 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: --- MarcFieldsToOrder and MarcItemFieldsToOrder are plain system preferences (read via C4::Context->yaml_preference) - a single global mapping shared by every MARC order account. Koha::MarcOrderAccount (admin/marc_order_accounts.pl) stores per-vendor settings such as vendor, budget, matcher and item-handling options, but has no way to override the field mapping per account. This is fine while every vendor's MARC order files share the same layout, but breaks down as soon as two vendors put the same order information (price, quantity, budget code, discount, sort codes, or any future mapped field) in different MARC fields - there is currently no way to serve both from one Koha instance, since only one global mapping can be active at a time. This enhancement proposes making the field mapping configurable per MARC order account, falling back to the global MarcFieldsToOrder / MarcItemFieldsToOrder sysprefs when an account has no override. This would need to cover every currently-mapped field (price, replacementprice, quantity, budget_code, discount, sort1, sort2, and any new ones such as suppliers_reference_number / suppliers_reference_qualifier from bug 43534), not just a single field in isolation. This came up while working on bug 43534 (which adds suppliers_reference_number / suppliers_reference_qualifier to the existing global mapping) - see that bug and bug 43535 for context. This bug is intentionally not a dependency of either: 43534/43535 are being implemented against the existing global-syspref model, and this bug tracks the idea of moving to per-account configuration as a separate, larger piece of work. Suggested implementation (not yet scoped in detail): - Add mapping storage to Koha::MarcOrderAccount (or a linked table), edited from admin/marc_order_accounts.pl. - Update Koha::MarcOrder's mapping lookups to check the account's own mapping first, falling back to the global sysprefs. - Update the admin UI to let a librarian override individual fields per account rather than editing the global YAML. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 39438] New: Add additional fields to agreements periods
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39438 Bug ID: 39438 Summary: Add additional fields to agreements periods Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com It could be discussed... But it would probably be useful to give this possiblity to libraries -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 42296] New: Tidy all script tags - trivial ones
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42296 Bug ID: 42296 Summary: Tidy all script tags - trivial ones Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 42094 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42094 [Bug 42094] Tidy all script tags (except value_builder) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 42418] New: Add Koha::Checkin(s) â checkin as a first-class resource
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42418 Bug ID: 42418 Summary: Add Koha::Checkin(s) â checkin as a first-class resource Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 41728 Blocks: 24401 Checkins in Koha are currently a side effect â they happen to checkouts, transfers, and holds, but there is no single record that captures 'a staff member scanned this item and here is what happened.' This bug introduces checkins as a proper resource: - New `checkins` table tracking the full context (who, what, where, when) and outcomes (checkout returned, transfer triggered, hold filled) - Koha::Checkin and Koha::Checkins object classes - Wire into AddReturn so every checkin path (returns.pl, SIP, API) produces a Koha::Checkin record This addresses several long-standing gaps: - 'Who checked this in?' is currently unreliable (no checkin_user_id on old_issues) - Transfers and holds triggered by a return have no causal link back to the scan - Lost item fee refunds cannot be traced to the return event that caused them - Plugins (e.g. Rapido ILL) have to reconstruct context from side effects Depends on bug 41728 (checkin availability). Blocks bug 24401 (checkin REST API endpoint). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24401 [Bug 24401] REST API: Check-in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41728 [Bug 41728] Add `Koha::Item::Checkin::Availability` to centralize logic -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 137

[Bug 42388] New: Extract patron charge limit resolution into Koha::Policy::Patrons::ChargeLimits
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42388 Bug ID: 42388 Summary: Extract patron charge limit resolution into Koha::Policy::Patrons::ChargeLimits Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 41728 Koha::Patron->is_patron_inside_charge_limits is a policy resolution method that resolves effective charge limits from patron category-level overrides falling back to global system preferences (noissuescharge, NoIssuesChargeGuarantees, NoIssuesChargeGuarantorsWithGuarantees). This is the same pattern as Koha::Policy::Holds->holds_control_library, which resolves the controlling library from ReservesControlBranch, and Koha::Policy::Patrons::Cardnumber->is_valid, which resolves cardnumber constraints from CardnumberLength and BorrowerMandatoryField. This bug proposes: - Add Koha::Policy::Patrons::ChargeLimits with methods to resolve effective charge limits for a patron - Have Koha::Patron->can_checkout and Koha::Patron->can_place_holds consume the new policy class instead of inlining the resolution logic - Add unit tests This is a prerequisite for the checkout availability work. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41728 [Bug 41728] Add `Koha::Item::Checkin::Availability` to centralize logic -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3