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

[Bug 41616] New: Warnings on authority_hooks.t
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41616 Bug ID: 41616 Summary: Warnings on authority_hooks.t Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Bug 36433 introduced a plugin hook for elasticsearch document generation, which makes the `authority_hooks.t` print some useless noise when ES is enabled in the context: ```shell prove t/db_dependent/Koha/Plugins/t/db_dependent/Koha/Plugins/authority_hooks.t t/db_dependent/Koha/Plugins/authority_hooks.t ................. 1/5 Plugin error (Test Plugin): Exception 'Koha::Exception' thrown 'elasticsearch_to_document ref record: MARC::Record - ref document: HASH' Plugin error (Test Plugin): Exception 'Koha::Exception' thrown 'elasticsearch_to_document ref record: MARC::Record - ref document: HASH' t/db_dependent/Koha/Plugins/authority_hooks.t ................. ok All tests successful. Files=20, Tests=119, 24 wallclock secs ( 0.04 usr 0.02 sys + 17.89 cusr 2.33 csys = 20.28 CPU) Result: PASS ``` -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 41599] New: reports/acquisitions_stats.pl calls output_error incorrectly
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41599 Bug ID: 41599 Summary: reports/acquisitions_stats.pl calls output_error incorrectly Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Typically, output_error should look like this: output_error( $cgi, '404' ); But reports/acquisitions_stats.pl calls it like this: C4::Output::output_error( $input, 'Possible SQL injection' ); 'Possible SQL injection' is not a valid errorno. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 41337] New: koha-create --request-db and --populate-db creates log files owned by root (intranet-error.log, opac-error.log)
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41337 Bug ID: 41337 Summary: koha-create --request-db and --populate-db creates log files owned by root (intranet-error.log, opac-error.log) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: saiful(a)semanticconsulting.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com When creating a new Koha instance using the two-step workflow (--request-db and --populate-db), some log files under /var/log/koha/<instance>/ end up with incorrect permissions. Specifically, intranet-error.log and opac-error.log are created as root:root instead of <inst>-koha:<inst>-koha. This causes Apache/Plack to fail to start cleanly until the ownership is corrected manually. Steps to Reproduce: 1. Run: koha-create --request-db test 2. Create the DB/user on the remote or local DB host as instructed. 3. Then run: koha-create --populate-db test 4. Check ownership of generated logs: ls -l /var/log/koha/test Actual Result: Two files are owned by root:root: -rw-r--r-- 1 root root 0 intranet-error.log -rw-r--r-- 1 root root 0 opac-error.log All other logs have correct ownership (test-koha:test-koha). Koha will not start smoothly until these two files are manually chowned. Expected Result: All log files under /var/log/koha/<instance>/ should be owned by <instance>-koha:<instance>-koha, identical to a normal koha-create run without the request/populate split. Notes: This only happens when using the two-step creation (--request-db + --populate-db). A normal one-step koha-create with --create-db assigns the correct ownership. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 41316] New: Using patron-homelibrary option for overdue notices does not change which rules are used
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41316 Bug ID: 41316 Summary: Using patron-homelibrary option for overdue notices does not change which rules are used Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Bug 32740 added an option to send overdue notices from the patrons home library, saying: When it's selected notification messages for overdues will be bundled and sent from the borrowing user's home library However, the other two options 'item homelibrary' and 'checkout library' also change which set of triggers are used. Currently the patron option will continue to use the triggers of the checkout library This is confusing -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 41131] New: Branch Transfer Limits basic editor allows one to prevent transfers from a library to itself and block related holds
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41131 Bug ID: 41131 Summary: Branch Transfer Limits basic editor allows one to prevent transfers from a library to itself and block related holds 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The branch transfer limits basic editor will always indicate that transfers from a branch to itself are allowed -- when the page loads, it always puts a checkmark under "Allow transfer" for the branch for which one is defining limits. But this checkmark is not reflected in the database. To recreate: - disable AllowHoldPolicyOverride - set UseBranchTransferLimits to Enforce; set BranchTransferLimitsType to itemtype (the also exists when enforcing by collection code, but its impact on holds is easier to see with itemtypes) - go to the branch transfer limits page, see that Allow Transfers is checked for all branches and all itemtypes - in a report, SELECT * FROM branch_transfer_limits, confirm no results -- we put a row in this table for every transfer that's blocked - back on the branch transfer limits, uncheck "Allow transfer" for Books going from Centerville to Centerville, click Save - On save, the page reloads and shows a checkmark under "Allow transfer" for Books going from Centerville to Centerville - back in reports, run your query again, see there is a row in branch_transfer_limits to block the transfer of Books from Centerville to Centerville - Attempt to place a hold on an item currently at Centerville for pickup at Centerville, confirm Koha will not allow this hold This cannot be recreated in the advanced editor. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 41097] New: Deduping authorities script (dedup_authorities.pl) can die on duplicated ids
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41097 Bug ID: 41097 Summary: Deduping authorities script (dedup_authorities.pl) can die on duplicated ids Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When running the script it seems to generate duplicate ids: Processing authority 1660 (531/650 81.69%) Merging 1660,1662 into 1660. Updated 0 biblios Deleting 1662 Merge done. This seems to be a product of _choose_records which gets all the candidates, but then adds the original record twice 318 my @records = map { C4::AuthoritiesMarc::GetAuthority($_) } @recordids; 319 my @candidate_auths = @records; and later: $choose_subs[2] ? $choose_subs[2]->($_) : 0 ] => ( $records[0], @candidate_auths ); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 41058] New: Using Show Checkouts button when LoadCheckoutsTableDelay is set causes collision/error. loadIssuesTableDelayTimeoutId not assigned
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41058 Bug ID: 41058 Summary: Using Show Checkouts button when LoadCheckoutsTableDelay is set causes collision/error. loadIssuesTableDelayTimeoutId not assigned 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: mike.grgurev(a)mainlib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Manually selecting the "Show Checkouts" button does not cancel the setTimeout associated with LoadCheckoutsTableDelay (Checkouts table will show automatically in blah seconds..) In /intranet-tmpl/prog/js/checkouts.js, loadIssuesTableDelayTimeoutId is declared and targeted by clearTimeout() but never applied to the setTimeout() that triggers LoadIssuesTable(). Lines 712 & 735 should be revised from "setTimeout(function () {" to "loadIssuesTableDelayTimeoutId = setTimeout(function () {" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 40711] New: Fix valuebuilder for 181 and 182 in UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40711 Bug ID: 40711 Summary: Fix valuebuilder for 181 and 182 in UNIMARC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl There are some little issues with valuebuilder that need a fix -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 39749] New: RestrictPatronsWithFailedNotices should not trigger for DUPLICATE_MESSAGE failures
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39749 Bug ID: 39749 Summary: RestrictPatronsWithFailedNotices should not trigger for DUPLICATE_MESSAGE failures Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Koha is built to prevent sending duplicate notices. Notices with static language ( e.g. "You have one or more holds ready to pick up" ) will easily trigger this filter. RestrictPatronsWithFailedNotices should ignore these notices because they do not indicate any problem with contacting the patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 30803] New: output_error should not assume a 404 status
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '26

13 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30803 Bug ID: 30803 Summary: output_error should not assume a 404 status Change sponsored?: --- Product: Koha Version: master 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See comments on bug 30261. > There is a fundamental flaw in output_error: > output_with_http_headers $query, $cookie, $template->output, 'html', > '404 Not Found'; > Although we pass $error, it always outputs a 404. I tried sending a 403, and > it does not work! > > The 404 from output_error is caught by Plack middleware and it will output > the 404 error document. In this case the OPAC 404 error document! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27