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

[Bug 40159] New: When modifying a subscription with received issues, prediction pattern doesn't start from next issue date
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40159 Bug ID: 40159 Summary: When modifying a subscription with received issues, prediction pattern doesn't start from next issue date Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org To reproduce the issue : Make a record and create a subscription for this record with a week or month subscription length and a first issue date in the past (like 2016). Receive at least one issue. Edit the subscription and test the prediction pattern. The displayed prediction shows only one number (unless you set the subscription length for like a thousand issues). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Passed QA --- Comment #878 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- (In reply to Pedro Amorim (ammopt) from comment #872) > Hi guys, a few issues here: > > 1 - TalkingTech_itiva_outbound.pl > A) In KTD, set 'TalkingTechItivaPhoneNotification' to 'On'. > B) Run perl misc/cronjobs/thirdparty/TalkingTech_itiva_outbound.pl > --type=OVERDUE -o /tmp/out.txt -v > C) It dies: DBI Exception: DBD::mysql::st execute failed: Unknown column > 'items.itemtype' in 'field list' - confirmed the items table only has itype, > never had itemtype. > > 2 - Circulation triggers gated on the wrong permission (menu + router guard) > A) Go to a patron's 'More' > 'Set permissions' tab. Check 'catalogue' > (needed for basic staff login), and under circulation-rules sub-permissions, > check only 'Manage overdue notice triggers' - leave 'Manage circulation > rules' unchecked. > B) Log in as that patron, go to 'Administration' - no 'Circulation triggers' > link (admin-home.tt only checks CAN_user_parameters_manage_circ_rules). > C) Visit http://localhost:8081/cgi-bin/koha/admin/circulation_triggers > directly - loads briefly, then redirects to admin-home.pl (the Vue router > guard also only checks CAN_user_parameters_manage_circ_rules, never > manage_circ_triggers). > > 3 - It appears the migration scenario I pointed out in comment 192 is still > a problem, if you apply patches and: > updatedatabase > yarn api:bundle > yarn js:build > restart_all > And then access > http://localhost:8081/cgi-bin/koha/admin/circulation_triggers - you get a > 404. > > 4 - Clearing 'delay' input using 'X' vs keyboard clear > A) 'Administration' > 'Circulation triggers' > 'Add new trigger' for any > library/category. Set a Delay, a Notice, and a transport type. > B) Select the Delay field's value and clear it via the 'X' clear button. > C) Click 'Submit', notice the Delay value was kept the previous one. > D) Select the Delay field's value and clear it via the keyboard > (Backspace/Delete). Click 'Submit'. > E) Confirm the trigger saved with no Delay value, despite Delay being > effectively required for the trigger to ever function. Thanks Pedro! The follow ups should hopefully address that - I have kept them in separate commits in case we end up needing to discuss and amend any specific part (eg. permissions/ itiva script) or drop a change (eg. the reset/delete behaviour change which extends the issue raised in point 4 to the reset and delete feature, but was technically not a requested fix) as they touch on very different things. Happy to squash if you'd rather! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #877 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- Created attachment 204863 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204863&action=e… Bug 10190: (QA follow-up): fix: prevent delay-less rule sets Since the decision was made that the add / edit trigger form should never let a trigger be created or edited to not have a delay, it follows that this must apply to the rule set reset flow as well. Retain the warning message to the user, and also disable the 'Confirm reset' button if the reset would result in delay-less sets. The same applies to the trigger deletion functionality: if deleting a trigger that is a default for all libraries would then leave any libraries with one or more delay-less rule set, block the trigger deletion (deactivate 'Confirm deletion') and inform the user. Here as well we also still display the warning message. Test plan: A) Create one or more 'Default for all libraries' triggers. B) Create one or more library-specific triggers. C) For one or more of these, add itemtype and/or category specific overrides with not delay override. D) For one or more of these, add itemtype and/or category specific overrides with a delay override. E) Select 'Reset' on a rule set with overrides of type D) and notice that the 'Confirm reset' button is enabled. F) Select 'Reset' on a rule set with overrides of type C) and notice that the 'Confirm reset' button is disabled, and that the warning message explains why reset is unavailable G) Select 'Delete' on the highest 'Default for all libraries' trigger, and notice that, where one or more library-specific overrides are of type D), 'Confirm deletion' is disabled, whereas it is otherwise enabled. H) Delete a trigger for which no override exists and confirm success. I) Delete a trigger for which only type D) overrides exist and confirm success. J) Reset a rule set for which only type D) overrides exist and confirm success. K) Reset a rule set for which no override exists and confirm success. Assisted-by: Claude Opus 5 (Anthropic) Sponsored-by: Glasgow Colleges Library Group <https://library.cityofglasgowcollege.ac.uk> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #876 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- Created attachment 204862 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204862&action=e… Bug 10190: (QA follow-up): fix: keyboard delay delete behaviour If the 'Delay' input field value is deleted using backspace or other, block form submission. The same behaviour apply if the delete button is used, as both clear out the value. As triggers with no delay are not processed and would also cause higher triggers to then also not be processed, we do not allow the creation of triggers without a set delay. Triggers when edited individually do not check for impact on any overrides they might have. It is therefore safest not to allow submission of a trigger where the user explicitly unset the value. An explicit 'reset to fallback' feature is possible and would constitute a follow up enhancement. Test plan (based on comment 872): A) 'Administration' > 'Circulation triggers' > 'Add new trigger' for any library/category. Set a Delay, a Notice, and a transport type. B) Select the Delay field's value and clear it via the 'X' clear button. C) Notice 'Submit' is disabled. D) Select the Delay field's value and clear it via the keyboard (Backspace/Delete). Click 'Submit'. E) Notice 'Submit' is disabled. Assisted-by: Claude Opus 5 (Anthropic) Sponsored-by: Glasgow Colleges Library Group <https://library.cityofglasgowcollege.ac.uk> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #875 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- Created attachment 204861 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204861&action=e… Bug 10190: (QA follow-up): fix: missing rewrite rule in koha-httpd.conf Looking at Bug 41167, this ought to fix the 404 error noted in comment 192 for package installs. We do have a test asserting that RewriteRules must be carried over, so: Test plan: 1. Apply patch 2. prove xt/check_apache_conf.t 3. Confirm it passes That said, I don't think it is replicable in ktd - the copied file at /etc/koha/apache-shared-intranet.conf will remain stale unless cp_debian_files.pl runs. The migration issue itself might be ktd-specific. Sponsored-by: Glasgow Colleges Library Group <https://library.cityofglasgowcollege.ac.uk> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #874 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- Created attachment 204860 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204860&action=e… Bug 10190: (QA follow-up): fix: permissions Important note: the following assumes manage_circ_triggers is intended as a sibling to manage_circ_rules, and that of the two, only manage_circ_triggers ought to grant access to client-side circulation trigger configuration actions. When manage_circ_triggers was introduced, it was not applied client-side, resulting in the router and menu permission checks incorrectly expecting manage_circ_rules. Amend that. Additionally, while the API endpoint blocked a user with only manage_circ_triggers from editing non-triggers circulation rules, it did not block a user with only manage_circ_rules from editing trigger circulation rules. Add a guard clause. Test plan (based on comment 872): A) Go to a patron's 'More' > 'Set permissions' tab. Check 'catalogue' (needed for basic staff login), and under circulation-rules sub-permissions, check only 'Manage overdue notice triggers' - leave 'Manage circulation rules' unchecked. B) Log in as that patron, go to 'Administration' - 'Circulation triggers' link present (admin-home.tt now correctly checks CAN_user_parameters_manage_circ_triggers), 'Circulation and fine rules' is not present. C) Visit http://localhost:8081/cgi-bin/koha/admin/circulation_triggers directly - you are granted access. D) Confirm that you can create and edit circulation triggers. E) Go to a patron's 'More' > 'Set permissions' tab. Check 'catalogue' (needed for basic staff login), and under circulation-rules sub-permissions, check only 'Manage circulation rules' - leave 'Manage overdue notice triggers' unchecked. F) Log in as that patron, go to 'Administration' - no 'Circulation triggers' link present (as we require manage_circ_triggers), however 'Circulation and fine rules' is present. G) Visit http://localhost:8081/cgi-bin/koha/admin/circulation_triggers directly - you see "Error: You do not have permission to access this page" and are prompted to log in as a different user (as we require manage_circ_triggers). H) Go to http://localhost:8081/cgi-bin/koha/admin/smart-rules.pl, and confirm that you can edit circulation rules for your library (no regression). Assisted-by: Claude Opus 5 (Anthropic) Sponsored-by: Glasgow Colleges Library Group <https://library.cityofglasgowcollege.ac.uk> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #873 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- Created attachment 204859 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204859&action=e… Bug 10190: (QA follow-up): fix: itiva script The following issues were identified and resolved: - items.itemtype does not exist -> swap to items.itype - leftover WHERE clause still referred to overduerules -> removed - with the join on overduerules removed there is no need to GROUP BY anymore - Koha::CirculationRules->all -> use next() instead Test plan (as per comment 872): A) In KTD, set 'TalkingTechItivaPhoneNotification' to 'On'. B) Run perl misc/cronjobs/thirdparty/TalkingTech_itiva_outbound.pl --type=OVERDUE -o /tmp/out.txt -v C) No errors / the script does not die mid run. Quick disclaimer: I am not overly familiar with that script: while I did remove the causes behind the script dying mid run, I won't have spotted issues with expected output / outcome. Assisted-by: Claude Opus 5 (Anthropic) Sponsored-by: Glasgow Colleges Library Group <https://library.cityofglasgowcollege.ac.uk> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42476] New: Rephrase ElasticsearchEnableZebraQueue system preference
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42476 Bug ID: 42476 Summary: Rephrase ElasticsearchEnableZebraQueue system preference Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The new system preference for reads: This preference should probably be set to 'Disable' unless you want Koha to act as a Z39.50 or SRU server. But this is not true, you can have Z39.50 and SRU without Zebra as well using the z3950-responder. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 13654] Cannot place a hold for biblio with too many items to display unless viewing them all
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13654 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|oleonard(a)myacpl.org |koha-bugs(a)lists.koha-commun | |ity.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43167] New: Bug in C4::Ris::marc2ris: Destructive STDOUT closing breaks under Plack/PSGI (Error 500) and causes 0-byte exports when processing flawed MARC fields (e.g., 100 ind1 blank)
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43167 Bug ID: 43167 Summary: Bug in C4::Ris::marc2ris: Destructive STDOUT closing breaks under Plack/PSGI (Error 500) and causes 0-byte exports when processing flawed MARC fields (e.g., 100 ind1 blank) Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lopalejandro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In KOHA 23.05.01 when exporting certain records to RIS format via OPAC or Intranet, the server throws an HTTP 500 Error. Plack error logs show: print() on closed filehandle STDOUT at opac-export.pl. This is triggered when the marc2ris function encounters a flawed MARC record—specifically, we isolated the trigger to MARC field 100 having a blank/empty Indicator 1, which breaks the author string evaluation. When this parsing fails, it triggers a cascade effect due to legacy code in /Koha/lib/C4/Ris.pm (sub marc2ris) that attempts to redirect STDOUT destructively: open my $oldout, qw{>}, "&STDOUT"; my $outvar; close STDOUT; open STDOUT,'>:encoding(utf8)', \$outvar; Under a Plack/PSGI environment, closing STDOUT destroys the HTTP output stream handle (_GEN_...), making it impossible to restore it at the end of the function. Any subsequent print call throws an HTTP 500. Furthermore, for analytic records lacking authors (like serials) where the output size doesn't exceed the memory buffer, skipping a proper STDOUT flush before the return causes the function to return an uninitialized variable, resulting in a 0-byte RIS file. Proposed Solution: Use local *STDOUT for a safe memory redirection, and close the localized handle strictly to flush the UTF-8 buffer before returning. Remove lines: open my $oldout, qw{>}, "&STDOUT"; # ... close STDOUT; open STDOUT,'>:encoding(utf8)', \$outvar; Replace with: local *STDOUT; open STDOUT,'>:encoding(utf8)', \$outvar; At the end of the function, remove the $oldout restoration and ensure the buffer is flushed: # close STDOUT; # open STDOUT, ">&", $oldout; Replace with: close STDOUT; # Flushes the buffer into $outvar return $outvar; -- You are receiving this mail because: You are watching all bug changes.

1 1