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

[Bug 41532] New: Standarise the website placeholder used in the manual to refer to the OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41532 Bug ID: 41532 Summary: Standarise the website placeholder used in the manual to refer to the OPAC and staff interface Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de The manual use **17** different website placeholders when referring to the OPAC and staff interface URL. These are the current variations: - YOUR_KOHA_OPAC_URL - YOURKOHACATALOG - YOURSITE - reference to OPAC URL - YOUROPAC - your-koha-staff-interface - your_koha_address - your-koha-staff-client-url - YOUR.OPAC.URL - default.tld - www.mylib.com - koha-pro.tld - www.mylibrarysite.com - YOURCATLOG - mykohaopac.org - yourlibraryurl (I added another one!) - staff.mylibrary.example.com - myserver.com For consistency, we should decide on a single placeholder to use. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 41087] New: EDI Retry: We should add the option to retry EDI processing for errors
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41087 Bug ID: 41087 Summary: EDI Retry: We should add the option to retry EDI processing for errors 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: 39215, 39291 Blocks: 3728 Now that we're catching and reporting EDI processing errors more, we should add the option to retry and revert a message Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3728 [Bug 3728] select mandatory fields broken https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39215 [Bug 39215] EDIFACT quote files should skip orders that cannot be processed rather than failing to complete https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39291 [Bug 39291] Edifact should record an error and move on if there's a problem with transport filename change -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 43081] New: Hide option/button for edifact error messages in Acquisitions
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43081 Bug ID: 43081 Summary: Hide option/button for edifact error messages in Acquisitions 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: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- We love the error message function that appears in Acquisitions for when something goes wrong with edifact orders. For example if a vendor sends us an invoice with some values incorrect, the error messages help us to work out what has gone wrong and correct the problem. However, the error message remains. We would love to see a 'hide' option for these error messages so we can acknowledge once we've read and dealt with a problem and we'd want the button to be 'sticky' so once pressed it change the default to 'hidden' with an option to re-open the error message if needed. This would help our acq team who get worried about then paying invoices that have error messages and would stop the need to reassure them (from our systems team) that the problem has now been fixed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 43804] New: Add after_edifact_action plugin hook for processed EDIFACT messages
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43804 Bug ID: 43804 Summary: Add after_edifact_action plugin hook for processed EDIFACT messages 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: --- Koha has plugin hooks around bibliographic, item, hold, circulation and account actions, but nothing that lets a plugin react once an EDIFACT message has been processed. Plugins can currently only take over invoice processing (edifact_process_invoice) or alter order sending (edifact_order). Plugins that need to act after a QUOTE, INVOICE or ORDRSP has been processed have to poll edifact_messages for new or recently changed rows. That is racy against the next edi_cron.pl run, and it does not work for invoices processed manually from the staff interface. Typical uses: finance reconciliation, exporting to external systems, alerting, extracting data Koha does not handle itself (e.g. invoice service charges), and post-processing records created from a quote. This patch adds after_edifact_action, following the existing after_*_action pattern (after_biblio_action, after_item_action, ...): after_edifact_action( { action => 'process', payload => { message => $row, message_id => $id, message_type => 'QUOTE' | 'INVOICE' | 'ORDRSP', }, } ) It is called from process_quote, process_invoice and process_ordrsp in Koha::EDI once processing has finished, so it fires for both edi_cron.pl and manual processing. For quotes it fires after any auto-orders are created. For invoices it also fires when a vendor plugin processes the invoice itself via edifact_process_invoice. Test plan: 1. Apply the patch 2. prove t/db_dependent/Koha/Plugins/Edifact_hooks.t => Tests pass 3. Revert the Koha/EDI.pm change and run the test again => It fails 4. prove t/db_dependent/Koha/EDI.t => Tests pass -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 43790] New: EDIFACT messages Import button always runs the invoice importer, even for quotes
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43790 Bug ID: 43790 Summary: EDIFACT messages Import button always runs the invoice importer, even for quotes Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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: --- The EDIFACT messages page (acqui/edifactmsgs.pl) shows an Import button for any message whose status is 'new', whatever its type, and op=import always calls process_invoice(). The button was added by Bug 23682 for invoices when EdifactInvoiceImport is set to 'manual', but nothing restricts it to invoices. If an inbound QUOTE (or ORDRSP) is left at status 'new' -- for example because edi_cron.pl did not get as far as processing it -- the button appears and clicking it runs the invoice importer on the quote. Quote lines carry RFF+QLI rather than RFF+LI, so every line is skipped with "Skipped invoice line N, missing ordernumber" in the EDI errors, an empty aqinvoices row is created for the quote's BGM document number on every click, and the message is marked 'received' without ever creating a basket. Further problems in the same code path: - op=import is a GET link rather than a cud- POST with a CSRF token, unlike the Delete button next to it. - The script does not check the message is still 'new', so a repeated or stale request imports it again and creates duplicate invoice headers. Proposed fix: offer Import for any unprocessed inbound message (QUOTE, INVOICE, ORDRSP) and dispatch on message_type to process_quote, process_invoice or process_ordrsp via a new Koha::EDI::process_message. Outbound ORDERS messages are not importable. Make the action a cud-import POST with CSRF token and only act on messages still in status 'new'. Test plan: 1. Enable EDIFACT. Insert (or download) an EDI message of type QUOTE with a valid quote in raw_msg, status 'new', for a vendor with an EDI account. 2. Go to Acquisitions > EDIFACT messages. 3. Without the patch: click Import. The invoice importer runs: an aqinvoices row is created, "missing ordernumber" errors are recorded and no basket exists. 4. Restore the message to status 'new' and apply the patch. 5. Reload: Import is shown for QUOTE, INVOICE and ORDRSP messages with status 'new' and not for ORDERS or already processed messages. 6. Click Import on the QUOTE: a basket is created from the quote and no invoice or error rows are created. Check an INVOICE (manual import mode) and an ORDRSP are processed by their own importer as well. 7. prove t/db_dependent/Koha/EDI.t -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 43813] New: Remove To Do from runreport.pl
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43813 Bug ID: 43813 Summary: Remove To Do from runreport.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Depends on: 43548 Target Milestone: --- The runreport cronjob includes a To Do note of "Allow Saved Results option." This was added in 2010 Bug 3090. It's unclear from discussion there what this To Do was meant to do. The cronjob does have the option to save report results to the database. I think this note can be removed. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43548 [Bug 43548] Convert misc/cronjobs/runreport.pl to the Getopt::Long::Descriptive convention (see bug 43546) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 43546] New: Standardize command-line scripts on Getopt::Long::Descriptive for safer, more consistent option handling
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43546 Bug ID: 43546 Summary: Standardize command-line scripts on Getopt::Long::Descriptive for safer, more consistent option handling Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Target Milestone: --- Koha's command-line scripts (misc/cronjobs/*.pl and more broadly the roughly 150 scripts under misc/) use plain Getopt::Long, which has a structural gap: its = and : spec modifiers only mean "this flag needs a value if it's used" -- there is no way to express "this flag itself is mandatory." Scripts that need a genuinely required option have to bolt on their own ad hoc check after parsing, for example: GetOptions( 'h|hours=s' => \$hours ); unless ($hours) { print $usage; die "ERROR: No --hours (-h) option defined"; } A survey of misc/cronjobs/ (58 scripts, 43 using GetOptions) found 14 scripts doing this kind of manual required-option check, each with its own bespoke error text, none of it declared anywhere Getopt::Long itself understands. This is a reliability and maintainability gap: Reliability -- a required option silently omitted is only caught by whatever ad hoc check (if any) the script's author remembered to write, which is inconsistent across scripts, easy to miss when writing a new one, and the failure mode for missing checks is scripts running with undef or empty values instead of failing fast. That is particularly risky for unattended cron execution where nobody is watching stdout. Security/robustness -- consistent, declarative validation of required input reduces the chance of an unset or malformed option flowing further into a script (file paths, SQL parameters, shell arguments) before anything checks it. This is defense-in-depth rather than a specific known vulnerability. Maintainability/readability -- option name, description, type, and required-ness end up scattered across the GetOptions call, a separate POD block, and a separate manual check, all of which can drift out of sync. A declarative spec keeps them in one place. Modernization -- this is a small, low-risk step toward more structured, self-documenting CLI code, consistent with Koha's general direction of reducing boilerplate and inconsistency across similar scripts. Proposal: Adopt Getopt::Long::Descriptive (pure Perl, no XS, actively maintained, built directly on top of Getopt::Long -- see https://metacpan.org/pod/Getopt::Long::Descriptive) as the standard for new/converted scripts, using its native "required" constraint, for example: my ($opt, $usage) = describe_options( '%c %o', [ 'hours|h=i', "hours since item was returned", { required => 1 } ], ... ); This makes "mandatory option" an explicit, declarative property of the script rather than something reconstructed from Getopt::Long spec syntax or scattered ad hoc checks, and it auto-generates consistent --help/usage text from the same declaration, removing the separately-maintained pod2usage boilerplate found in roughly 32 of the surveyed scripts. Suggested scope (staged, not a single patch): 1. Add Getopt::Long::Descriptive to cpanfile. 2. Document the convention for how new/converted scripts should declare and parse options -- possibly formalized as a small helper alongside Koha::Script, which currently only handles locking/logging/userenv and has no opinion on option parsing. 3. Convert a small number of scripts as a proof of concept, chosen for having a genuinely mandatory option today (e.g. cart_to_shelf.pl's -h/--hours). 4. Convert the remainder opportunistically over time, not as a single mass patch -- this changes each script's help/error output, which is a real (if minor) behavior change worth reviewing script by script. One real-world motivating example: the third-party koha-plugin-crontab plugin (still a work in progress, not recommended for production use yet -- https://github.com/openfifth/koha-plugin-crontab) lets staff schedule these scripts from a UI and tries to surface which options are required in its form. Lacking any core-level signal, it has to either mis-infer this from Getopt::Long spec syntax or fall back to an administrator manually curating the list per install -- a workaround, not a fix. That is a symptom of the underlying gap this bug is about, not the primary motivation for it. Test plan: - For each converted script, confirm --help output is sensible and existing documented options still work. - Confirm omitting a required option now fails with a clear, consistent error before any side effects occur. - Confirm koha-qa.pl passes for converted scripts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 37248] New: [Omnibus] Power to the user
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37248 Bug ID: 37248 Summary: [Omnibus] Power to the user Change sponsored?: --- 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: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This is for the initiative for helping to ensure that users can do as much of the configuration in the interface rather than the command line. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 43812] New: ILL requests on detail.pl should honor ILLHiddenRequestStatuses
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43812 Bug ID: 43812 Summary: ILL requests on detail.pl should honor ILLHiddenRequestStatuses Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com 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: --- On detail.pl any ILL request associated with the biblio are displayed on the record detail page: # Check if there are any ILL requests connected to the biblio my $illrequests = C4::Context->preference('ILLModule') ? Koha::ILL::Requests->search( { biblio_id => $biblionumber } ) : []; $template->param( illrequests => $illrequests ); This should honor ILLHiddenRequestStatuses -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43803] New: Confirming a hold at checkin can set the hold to waiting on an item that has been checked out again (item ends up both on loan and waiting)
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43803 Bug ID: 43803 Summary: Confirming a hold at checkin can set the hold to waiting on an item that has been checked out again (item ends up both on loan and waiting) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Steps to reproduce: 1. Create an item-level hold on an item currently checked out to patron A (hold by patron B). 2. Workstation 1: check in the item. The "Hold found" modal appears with the "Confirm hold" button. Leave this modal open. 3. Workstation 2 (or another tab): check out the same item to patron C. The "This item is reserved" confirmation appears. Confirm the checkout without cancelling the hold (force checkout is allowed). 4. Back on workstation 1: click "Confirm hold" in the still-open modal. Expected result: The hold confirmation is refused (or the hold is left pending), because the item is now on loan. The hold should not be set to waiting while the item is checked out. Actual result: The hold is set to waiting (found = 'W') even though the item is on loan to patron C. The item ends up both on loan and on the hold shelf ("waiting for pickup"). No warning is shown to the librarian at step 4. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9