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

[Bug 39650] New: Updating the protected flag is not possible when creating a new patron
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39650 Bug ID: 39650 Summary: Updating the protected flag is not possible when creating a new patron Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When creating a new patron, it is not possible to update the protected flag even when logged in as a superlibrarian. It is still possible to update this flag when updating an existing patron. This seams liked to bug 36085. The check to set the authorization flag CanUpdateProtectPatron (witch restrict the update to only superlibrarian) is itself in a check for op 'edit_form', 'cud-save' or 'duplicate'. The flag CanUpdateProtectPatron is not passed to the template when creating a new user as the op is 'add_form' even when logged in as a superlibrarian. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 41946] New: Superlibrarian should be able to set protected status on patron creation
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '26

22 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41946 Bug ID: 41946 Summary: Superlibrarian should be able to set protected status on patron creation Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Since bug 36085, the protected flag in a patron account was removed from the patron creation form, regardless of if the user is a superlibrarian. 1. With a superlibrarian account, go to Patrons > New patron > Choose any category --> Before bug 36085 : In "Library management" section, there is a Protected yes/no field --> After bug 36085 : the Protected option is no longer there. If I create a SIP account, I now have to create the account, then go back an edit it to add the protection. Non-superlibrarians should still not be able to set the flag on creation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 41771] New: Diff in syspref descriptions after Bug 30331
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41771 Bug ID: 41771 Summary: Diff in syspref descriptions after Bug 30331 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org There is a diff in syspref's description for existing installs: # Failed test 'Comparing AutomaticRenewalPeriodBase' # at t/db_dependent/check_sysprefs.t line 135. # Structures begin differing at: # $got->{explanation} = 'Set whether the renewal date should be counted from the date_due or from the moment the Patron asks for renewal, for automatic renewals' # $expected->{explanation} = 'Set whether the renewal date should be counted from the date_due or from the moment the Patron asks for renewal, for automatic renewals ' # Failed test 'Comparing ManualRenewalPeriodBase' # at t/db_dependent/check_sysprefs.t line 135. # Structures begin differing at: # $got->{explanation} = 'Set whether the renewal date should be counted from the date_due or from the moment the Patron asks for renewal ' # $expected->{explanation} = 'Set whether the renewal date should be counted from the date_due or from the moment the Patron asks for renewal, for manual renewals ' # Looks like you failed 2 tests of 1753. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 30331] New: Allow RenewalPeriodBase behavior to differ between manual and automatic renewals
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30331 Bug ID: 30331 Summary: Allow RenewalPeriodBase behavior to differ between manual and automatic renewals Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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.m.hall(a)gmail.com We should have a way to make auto-renewals and manual renewals follow different RenewalPeriodBase behavior. I'm working with a library that uses a mix of manual and automatic renewals. For items that auto-renew, the renewal happens two days before the item is due, so they want RenewalPeriodBase set to add time on to the existing due date so the patron gets their full renewal period. But for items renewed manually, they want RenewalPeriodBase set to calculate from the renewal date, though, so patrons can't renew early and lock in extra time with the item. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 53

[Bug 42046] New: Bug 30331 database update is not idempotent
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42046 Bug ID: 42046 Summary: Bug 30331 database update is not idempotent Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The DBRev for Bug 30331 is not idempotent: my $base_period = C4::Context->preference('RenewalPeriodBase'); $dbh->do( q{ UPDATE systempreferences SET variable = 'ManualRenewalPeriodBase' WHERE variable = 'RenewalPeriodBase' } ); When ran twice: "ERROR: {UNKNOWN}: DBI Exception: DBD: :db do failed: Duplicate entry 'ManualRenewalPeriodBase' for key 'PRIMARY' at /kohadevbox/koha/C4/Installer.pm line 819" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 22637] New: Add ability to full reindex elasticsearch index from UI
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22637 Bug ID: 22637 Summary: Add ability to full reindex elasticsearch index from UI Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com Target Milestone: --- Button in toolbar on elastic search admin page to initiate full reindex. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 41627] New: Add Koha::CSV::Acquisitions for acquisition exports
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41627 Bug ID: 41627 Summary: Add Koha::CSV::Acquisitions for acquisition exports 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 Depends on: 41619 Blocks: 41621 This bug adds Koha::CSV::Acquisitions to standardize CSV generation for acquisition exports. Files to update: - C4/Acquisition.pm - admin/aqplan.pl Benefits: - Consistent CSV formatting - Proper quote handling - Testable code Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41619 [Bug 41619] Add `Koha::CSV` https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41621 [Bug 41621] Use Koha::CSV everywhere [UMBRELLA] -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 38540] New: Checkout override allowed without permissions when item has parts / materials specified
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38540 Bug ID: 38540 Summary: Checkout override allowed without permissions when item has parts / materials specified Change sponsored?: --- 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.m.hall(a)gmail.com Koha will allow a user who does not have force_checkout permissions to check out to a user with fines over the NoIssuesCharge amount if the item to be checked out has a value in items.materials has content. To confirm: 1- set AllowFineOverride to Allow, confirm there is a value in NoIssuesCharge 2- have a user with circulate_remaining_permissions but not force_checkout 3- have a patron with fines over the NoIssuesCharge amount 4- have two items: Item A does not have a value in items.materials, Item B does 5- log in as your user, find your patron 6- attempt to check Item A out to your patron, Koha tells you "Cannot check out" and "Patron has a debt" 7- attempt to check out Item B, Koha says "Please confirm checkout," tells you about the debt and the materials note This happens whether or not CircConfirmItemParts is on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 40990] New: Checkout override allowed without permissions when item has circulation alert
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40990 Bug ID: 40990 Summary: Checkout override allowed without permissions when item has circulation alert Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Koha will allow staff who do not have force_checkout permissions to check out items beyond the maximum number per type allowed if the item has a circulation alert. In this case a warning is offered but staff can click to continue with the checkout. This behavior is different than when items do not have the circulation alert ; in that case the same staff hit a hard block and cannot override the limitation. This may be related to bug 38540. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 30894] New: Add ability to select all/clear all and delete selected label batches
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30894 Bug ID: 30894 Summary: Add ability to select all/clear all and delete selected label batches Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When managing label batches (label-manage.pl) it would be handy to be able to select all/clear all label batches. It would also be nice if you could delete all selected batches instead of having to go through your batches and delete them one at a time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2