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

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 --- Comment #63 from Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> --- Thanks for the review. The new follow-up addresses all 4 findings. The unit tests added to t/db_dependent/Search.t were written with the help of an AI assistant (Claude), then reviewed and run by me. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 --- Comment #62 from Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> --- Created attachment 208588 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208588&action=e… Bug 15248: (QA follow-up) Fix duplicate check when editing records - When editing a record, only check for duplicates if a matching rule is configured for the framework - 'Forbid creation of duplicate' no longer prevents saving an existing record: a warning is displayed with an option to save - Request one more match when excluding the edited record, so it does not hide an actual duplicate - Fix the description field when editing a non-default framework Test plan: 1. Apply the patches, updatedatabase and restart_all 2. Follow the steps of the 4 findings in the last QA comment => Finding 1: the record is saved without any duplicate warning => Finding 2: the BKS framework description is editable and saving works => Finding 3: editing biblio 155 warns about biblio 252 => Finding 4: editing biblio 252 shows a warning with 'Yes, save record', and the record can be saved 3. With 'Forbid creation of duplicate' enabled, create a new record with ISBN 0964479621 in the BKS framework => Creation is still forbidden 4. prove t/db_dependent/Search.t Co-Authored-By: Claude Opus 5.5 <noreply(a)anthropic.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42667] New: Split the ability to edit other librarian's reports into a separate permission
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42667 Bug ID: 42667 Summary: Split the ability to edit other librarian's reports into a separate permission Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com My work on bug 42108 has lead me to realize that being able to edit anyone's reports creates a loophole that allows anyone who can create reports to bypass 42108 by simply editing someone else's existing report. Aside from that, this seems like a good idea in general. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 78

[Bug 43865] New: Typo in item_inactive class on selected inactive item fund in addorderiso2709.tt
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43865 Bug ID: 43865 Summary: Typo in item_inactive class on selected inactive item fund in addorderiso2709.tt Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial 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: --- Spotted while pushing Bug 43787. In koha-tmpl/intranet-tmpl/prog/en/modules/acqui/addorderiso2709.tt, the item-level fund dropdown renders an option that is both inactive and the item's currently selected fund with the class "buget_item_inactive" (typo: missing 'd'). All the other inactive item options use "budget_item_inactive". koha-tmpl/intranet-tmpl/prog/js/funds_sorts.js builds the "active funds only" dropdown by removing every ".budget_item_inactive" child from a clone of each item select. Because of the typo, the selected inactive fund is not removed, so it stays selected in the active-only dropdown. The typo was introduced by Bug 22712 and no CSS or other JS references either spelling. Do NOT simply correct the spelling: the selected inactive option would then be stripped from the active-only dropdown, the item would lose its existing fund in the visible select, and an empty budget_id would be submitted for it. Suggested approach: decide whether the selected inactive option should keep a class at all. Either drop the class from that option (no behaviour change), or give it an explicit, correctly named class (e.g. budget_item_selected_inactive) that funds_sorts.js deliberately leaves alone, and add a comment explaining why. Test plan: 1. Create an inactive budget with a fund and stage a MARC file whose items map to that fund (MarcItemFieldsToOrder). 2. Go to Add to basket > From a staged file and open the staged file. 3. Confirm the item's fund dropdown shows the inactive fund selected while 'Show inactive funds' is unchecked. 4. Toggle 'Show inactive funds' and confirm the selection is retained both ways. 5. After the fix, repeat and confirm behaviour is unchanged. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

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

21 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 46

[Bug 41717] New: Update PDF::Reuse and PDF::Reuse::Barcode to the latest version
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41717 Bug ID: 41717 Summary: Update PDF::Reuse and PDF::Reuse::Barcode to the latest version Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: chris.nighswonger(a)veritassuperaitsolutions.com QA Contact: testopia(a)bugs.koha-community.org Update PDF::Reuse to the current version 0.43. Update PDF::Reuse::Barcode to the current version 0.09 The existing test suite passes when with both so this should be a pretty straightforward bump. ~/git_repos/koha/Koha(main)$ sg docker -c 'docker exec koha-testing-docker-koha-1 perl -MPDF::Reuse -e "print \$PDF::Reuse::VERSION, chr(10)"' 0.43 ~/git_repos/koha/Koha(main)$ sg docker -c 'docker exec koha-testing-docker-koha-1 perl -MPDF::Reuse::Barcode -e "print \$PDF::Reuse::Barcode::VERSION, chr(10)"' 0.09 ~/git_repos/koha/Koha(main)$ sg docker -c 'docker exec koha-testing-docker-koha-1 bash -c "cd /kohadevbox/koha && prove t/Creators.t t/db_dependent/Labels/t_Label.t"' t/Creators.t ..................... ok t/db_dependent/Labels/t_Label.t .. ok All tests successful. Files=2, Tests=49, 4 wallclock secs ( 0.05 usr 0.01 sys + 3.46 cusr 0.38 csys = 3.90 CPU) Result: PASS -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 43825] New: Patron edit page doesn't return to moremember.pl when it should
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43825 Bug ID: 43825 Summary: Patron edit page doesn't return to moremember.pl when it should Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- To reproduce: 1. Pull up a patron account on the Details tab (moremember.pl) 2. Click the Edit button at the top of the page 3. Click Save --> You're now on the Checkouts tab instead of returning to the Details tab -- You are receiving this mail because: You are watching all bug changes.

1 10

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

21 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 11

[Bug 43769] New: existing_holds table search/filter by pickup library is broken on request.tt
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43769 Bug ID: 43769 Summary: existing_holds table search/filter by pickup library is broken on request.tt Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- To recreate: 1. Make a branch with a code 'TEST' and name 'Sparkly Unicorn Land' 2. Place some holds, more than 2, on a record. Make the pickup location for one be 'Sparkly Unicorn Land'. 3. On Use the dT search to search the existing holds table on request.tt 4. Search by 'TEST' - the hold appears 5. Search by 'Sparkly' - the hold appears 6. Search by 'Unicorn' - the hold does not appear -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37