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

[Bug 43816] New: 'Self-renewal charge limit', 'Checkout charge limit', and noissuescharge don't block at the same threshold
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43816 Bug ID: 43816 Summary: 'Self-renewal charge limit', 'Checkout charge limit', and noissuescharge don't block at the same threshold Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 26355 Target Milestone: --- With the new OPAC account self-renewal feature (bug 26355), patrons can be prevented from self-renewing if they owe more than a certain amount on their account. The amount is set by the following, in this order: 1) 'Self-renewal charge limit' in the Account expiry and self-renewal section of patron category settings - if blank, then 2) 'Checkout charge limit' in patron category settings - if blank, then 3) noissuescharge system preference However, patrons are blocked from self-renewal if they owe *equal to or greater than* the amount in 'Self-renewal charge limit', but only if *greater than* the amount in 'Checkout charge limit' and noissuescharge. This should be consistent so that they all either block at equal to or greater than the amount, or only when someone owes more than the amount set in any of the three. To recreate: -Create a $10 manual charge on a test patron's account -Set their account to expire tomorrow -Set their patron category to allow self-renewal with a 'Self-renewal availability period' of 5 -Set 'Self-renewal charge limit', 'Checkout charge limit', and noissuescharge to 10 -Log into the OPAC as the test patron, and note that there is no link to self-renew -Return to the patron category, and clear the value in 'Self-renewal charge limit' (leave 'Checkout charge limit' and noissuescharge at 10) -Return to the OPAC, refresh, and see that the link to self-renew appears -In the patron category, clear the value in 'Checkout charge limit' (leave noissuescharge at 10, and 'Self-renewal charge limit' blank) -In the OPAC, refresh again, and see that the link to self-renew is still available Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26355 [Bug 26355] Allow patron account renewals through the OPAC -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 26355] New: Tie account renewals to patron modification requests
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26355 Bug ID: 26355 Summary: Tie account renewals to patron modification requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Allow patrons renewal reminders to link to the patron modification requests, asking them to review their information and make any any necessary updates if necessary, but acknowledging that the information is up to date. Create a check-box stating that they have reviewed all their information, and it is accurate and up to date (if no changes are made). Perhaps this check-box only shows when their account is due for renewal. -- You are receiving this mail because: You are watching all bug changes.

1 259

[Bug 43269] New: Add cached description_for() class methods to Koha::Libraries, Koha::ItemTypes, Koha::Patron::Categories
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43269 Bug ID: 43269 Summary: Add cached description_for() class methods to Koha::Libraries, Koha::ItemTypes, Koha::Patron::Categories 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 Target Milestone: --- Several places in Koha need to resolve codes to human-readable descriptions (branchcode to library name, categorycode to category description, itype to item type description). Currently this is done either per-row via Koha::Libraries->find($code)->branchname (uncached, N+1 queries) or via C4::Biblio::GetAuthorisedValueDesc (cached but MARC-centric API requiring tag/subfield/framework). We should add cached class-level lookup methods on the domain objects: Koha::Libraries->name_for($branchcode); Koha::Patron::Categories->description_for($categorycode); Koha::ItemTypes->description_for($itype); These would: - Use Koha::Caches to pre-fetch all values for the table on first access - Return the description string (or the raw code as fallback) - Be usable from any context (CSV exports, templates, scripts, REST API) This decouples the caching from the MARC layer and makes it available to the Koha::CSV subclass pattern (bug 41621) and anywhere else that needs bulk code-to-description resolution without N+1 queries. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 41921] New: Add ability to run reports as background jobs
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41921 Bug ID: 41921 Summary: Add ability to run reports as background jobs 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 It would be nice if reports can as background jobs instead of standard page loads. This would allow long running reports to be viewable from the staff interface. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 238

[Bug 43815] New: More granular options for Can Be Guarantee
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43815 Bug ID: 43815 Summary: More granular options for Can Be Guarantee Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- As Bug 37439 notes, the ChildNeedsGuarantor preference is actually much more sweeping in its implications, catching both Child-type accounts (legacy mechanism for guarantee relationship) with patron categories set to 'Can be guarantee.' This rolls back the flexibility granted to make any patron category guarantee-able to reflect the diverse communities libraries serve, if a library would otherwise like to have require responsible adult patrons for children's accounts. It would be nice if the 'Can be guarantee' designation had options for 'Must have guarantor' and 'May have guarantor' so that libraries can configure genuine child accounts to have adult account holder while still allowing a library to honor adult guardianship situations. Without something like this, ChildNeedsGuarantor is largely too restrictive for many public library systems. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43552] New: Convert misc/cronjobs/gather_print_notices.pl to the Getopt::Long::Descriptive convention (see bug 43546)
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43552 Bug ID: 43552 Summary: Convert misc/cronjobs/gather_print_notices.pl to the Getopt::Long::Descriptive convention (see bug 43546) 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 Depends on: 43546 Target Milestone: --- This is one of a set of bugs filed alongside bug 43546 (Standardize command-line scripts on Getopt::Long::Descriptive) to convert individual, commonly-used cron scripts to whatever declarative option-parsing convention that bug settles on. Depends on 43546. Current state: gather_print_notices.pl uses plain Getopt::Long (GetOptions call around line 31). No named option is required in the Getopt::Long sense. The actual mandatory input is a positional argument, not a flag: the output directory is taken from $ARGV[0] and validated around line 47 ("You must specify a valid and writeable directory..."). Separately, --csv and --ods each require exactly one --letter_code to also be given -- a cross-option constraint, not a single required flag. What this bug covers: convert the named options (--split, --html, --csv, --ods, --delimiter, --letter_code, --send, --email) to the new convention for consistency. As with runreport.pl in this same set, the positional output-directory requirement and the csv/ods-needs-one-letter_code cross-check don't map onto a simple per-option required constraint and will likely need to stay as manual post-parse validation. Test plan: - --help output covers all documented options and matches current behavior - Running with a valid output directory and various flag combinations still behaves exactly as before - Running with a missing/invalid directory, or --csv/--ods without exactly one --letter_code, still fails with the same errors as today Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43546 [Bug 43546] Standardize command-line scripts on Getopt::Long::Descriptive for safer, more consistent option handling -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 43550] New: Convert misc/cronjobs/update_patrons_category.pl to Getopt::Long::Descriptive, with --from/--to as genuinely required options (see bug 43546)
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43550 Bug ID: 43550 Summary: Convert misc/cronjobs/update_patrons_category.pl to Getopt::Long::Descriptive, with --from/--to as genuinely required options (see bug 43546) 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 Depends on: 43546 Target Milestone: --- This is one of a set of bugs filed alongside bug 43546 (Standardize command-line scripts on Getopt::Long::Descriptive) to convert individual, commonly-used cron scripts to whatever declarative option-parsing convention that bug settles on. Depends on 43546. Current state: update_patrons_category.pl uses plain Getopt::Long (GetOptions call around line 171). -f/--from and -t/--to (source and destination patron category codes) are effectively mandatory: the script dies with "Categories not found" if either fails to resolve to a real category (around line 224), including when the option was never supplied at all -- but Getopt::Long has no way to express that, so nothing stops the script from running with neither supplied and proceeding through several other steps (including the --regbefore/--regafter date-range validation around lines 205-216) before that die is reached. This is a direct analog of cart_to_shelf.pl's -h/--hours case described in bug 43546 -- a genuinely mandatory option currently enforced only by an ad hoc post-parse die, well after other processing has already happened. What this bug covers: convert to the new convention, declaring --from/-f and --to/-t as required, so a missing category code is rejected immediately and consistently, before any of the date-range validation logic runs. Test plan: - --help output covers all documented options and matches current behavior - Omitting --from or --to now fails immediately with a clear, consistent error, before any other validation runs - Supplying both still behaves exactly as before, including the existing "Categories not found" check for invalid (but present) category codes Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43546 [Bug 43546] Standardize command-line scripts on Getopt::Long::Descriptive for safer, more consistent option handling -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 43548] New: Convert misc/cronjobs/runreport.pl to the Getopt::Long::Descriptive convention (see bug 43546)
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43548 Bug ID: 43548 Summary: Convert misc/cronjobs/runreport.pl to the Getopt::Long::Descriptive convention (see bug 43546) 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 Depends on: 43546 Target Milestone: --- This is one of a set of bugs filed alongside bug 43546 (Standardize command-line scripts on Getopt::Long::Descriptive) to convert individual, commonly-used cron scripts to whatever declarative option-parsing convention that bug settles on. Depends on 43546. Current state: runreport.pl uses plain Getopt::Long (GetOptions call around line 210). No option here is actually mandatory -- --format defaults to 'text' if omitted (around line 237); --to/--from/--email are only meaningful together and default from the KohaAdminEmailAddress system preference if unset. The script's real "you must supply something" requirement is a positional argument, not a named option: at least one saved report ID must be passed via @ARGV, enforced by "unless (scalar(@ARGV)) { pod2usage(1); }" around line 268. What this bug covers: convert the GetOptions call to the new convention, declaring each option's type and description explicitly, with none marked required (matching current behavior -- nothing here is a false negative to fix). Note for whoever picks this up: the positional report-ID requirement doesn't map onto a simple per-option required flag, so it will likely need to stay as manual validation after parsing, unless the convention from bug 43546 ends up handling leftover/positional arguments some other way -- check against whatever pattern that bug lands on. Test plan: - --help output covers all documented options and matches current behavior - Running with one or more report IDs still behaves exactly as before - Running with zero report IDs still fails with a clear error Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43546 [Bug 43546] Standardize command-line scripts on Getopt::Long::Descriptive for safer, more consistent option handling -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 43814] New: Make account renewal success message customizable
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43814 Bug ID: 43814 Summary: Make account renewal success message customizable Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 26355 Target Milestone: --- The new OPAC self-renewal option (Bug 26355) has a customizable failure message with the field 'Self-renewal failure message', but the success message isn't similarly customizable in patron category settings. It would be helpful if the success message could be customized as well. It defaults to 'Your account has been successfully renewed until [date per patron category]. You should receive a confirmation shortly.', but that will be confusing for patrons whose libraries aren't sending any sort of confirmation message. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26355 [Bug 26355] Allow patron account renewals through the OPAC -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43771] New: Override ability for "no renewal before" part of AllowRenewalLimitOverride is not working from patron accounts unless another block exists
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43771 Bug ID: 43771 Summary: Override ability for "no renewal before" part of AllowRenewalLimitOverride is not working from patron accounts unless another block exists Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- The starred part of AllowRenewalLimitOverride is not working when overriding renewals from a patron's account unless there is another block such as a hold: "[Allow/Don't allow] staff to manually override renewal blocks and renew a checkout when it would go over the renewal limit or *be premature for the "No renewal before" setting in the circulation policy* or has been scheduled for automatic renewal." However, if there is a second block on the renewal (for instance, another patron's hold on the bib), the override works even when it is still premature. To recreate: Setup: -Set AllowRenewalLimitOverride to [Allow] -Set AllowRenewalOnHoldOverride to [Allow] -Use a staff account with superlibrarian permissions -Set a circ policy to check out an item type for 5 days, 2 renewals allowed, 'No renewal before' set to 1 Part 1: -Find a bib with a single item and no holds, and check it out to a test patron -In the patron's account, click the 'Override renewal restrictions' box - note that no checkbox populates in the patron's checkout table, making it impossible to renew the item early -Go to Circulation > Renew, and input the barcode - note that the renewal is possible via override, which is correct per the system preference (message: [Title/barcode] cannot be renewed before [date].) -Renew the item -Renew again from Circulation (use all available renewals) -Return to the patron's account -Click the 'Override renewal restrictions' box, and note that an override option shows in the patron's checkout table now 0 renewals are remaining (correct per the "when it would go over the renewal limit" part of the system preference) Part 2: -Return the test item -Check the same item out to your test patron -In the patron's account, click the 'Override renewal restrictions' box - no checkbox populates -Go to the bib, and place a hold for another patron -In the original patron's account, click the 'Override renewal restrictions' box - an override option now shows in the patron's checkout table The behavior described above is the same (no override from the patron account unless there's a hold on the bib) when a hold is early due to the 'No automatic renewal before' circ setting. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1