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

[Bug 42497] New: Warning on acqui-home.pl
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42497 Bug ID: 42497 Summary: Warning on acqui-home.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In acqui/acqui-home.pl, this returns a warning because depth does not exist: 134 for my $bp ( @{$budgetperiods} ) { 135 my $hierarchy = C4::Budgets::GetBudgetHierarchy( $$bp{budget_period_id}, undef, undef, 1 ); 136 for my $budget ( @{$hierarchy} ) { 137 $$budget{budget_display_name} = sprintf( "%s", ">" x $$budget{depth} . $$budget{budget_name} ); 138 } 139 $$bp{hierarchy} = $hierarchy; 140 } Could not find any reference to {depth} in budgetperiod -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 39422] New: Checkout 'remember for session' override does not handle holds cancellation
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39422 Bug ID: 39422 Summary: Checkout 'remember for session' override does not handle holds cancellation 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1 - Place several holds for patron A 2 - Checkout one of the items to Patron B 3 - You get a warning with an option to cancel the hold 4 - Check the cancel button and the remember button 5 - Checkout the rest of the held books 6 - No warnings 7 - Check patron A - only the first hold was cancelled We have situations where a caregiver or relative will pickup the holds for a patron and the libraries would like to see all of the holds cancel - i.e. we need to remember the saved options correctly -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 37638] New: Link permissions to entry in the manual
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37638 Bug ID: 37638 Summary: Link permissions to entry in the manual Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lauren_denny(a)sil.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Similar to bug 37624, create a link by the permission that takes you to the manual. If applicable, it would also be helpful to put a note by the permission if a system preference is required. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 9805] Lost items are un-lost if returned, but not if renewed
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9805 Avery Campbell (Butte County Library (CA)) <acampbell(a)buttecounty.ca.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |acampbell(a)buttecounty.ca.go | |v --- Comment #66 from Avery Campbell (Butte County Library (CA)) <acampbell(a)buttecounty.ca.gov> --- This would be great to see implemented. As others have said, there have been issues where items are renewed, fines are cleared (because the due date is now in the future), but their items are still Long Overdue (Lost). Manually changing the status of the items via the record, checks the items in. If the fines are over the threshold, staff can still override the renewals, even if we tell them don't renew to avoid this issue. If the item is still not returned, DefaultLongOverdueLostValue will take care of reassigning the LOST status. Currently, if a manager needs to renew the item(s), they check the items in to clear the LOST status, then check them back out. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 20844] New: Reset a hold when it is missing after allocation
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Bug ID: 20844 Summary: Reset a hold when it is missing after allocation Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: hughr(a)brimbank.vic.gov.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There currently is no simple way to 'deallocate' a hold if it has gone missing after it is allocated to a patron but before they collect it. This enhancement would work as follows: 1. item is allocated 2. item cannot be located when patron tries to collect it 3. staff member marks item as Lost 4. if hold was originally a bib-level hold, hold reverts from being specific to the missing item, back to a bib-level hold with priority 1. 5. if hold was originally item-level, staff member gets an alert asking whether to cancel or retain the hold 6. (optionally?) a 'lost hold' notice is queued to be sent to the patron This bug is related to the original description of https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19287#c32 and also to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15679 To do it properly, it may require a couple of new settings, something like: LostBibLevelHoldsRevert SendLostHoldNotices -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 150

[Bug 38399] New: Create a script that lists records that are not linked to any authority
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38399 Bug ID: 38399 Summary: Create a script that lists records that are not linked to any authority Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: enica(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz It would be nice to have a script that would list which bibliographic records are not linked to any authorities. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 42494] New: Staff login through plugins/run.pl does not persist the new session cookie
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42494 Bug ID: 42494 Summary: Staff login through plugins/run.pl does not persist the new session cookie Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When a staff user reaches a Koha plugin page directly while unauthenticated, Koha displays the normal staff login form. After submitting valid credentials, the plugin page renders for the current request, but the browser does not keep a usable authenticated staff session for the next request. Reloading the same plugin page asks for login again. If the same staff user first logs in through /cgi-bin/koha/mainpage.pl and then opens the same plugin URL, the plugin page can be reloaded repeatedly as expected. To recreate: 1. Use a staff user with permission to run a plugin tool/report. 2. Clear browser cookies or use a private browser window. 3. Go directly to a plugin run URL, for example: /cgi-bin/koha/plugins/run.pl?class=Koha::Plugin::...&method=tool 4. Submit the staff login form with valid credentials. 5. Confirm that the plugin page renders. 6. Reload the page. 7. Notice that Koha asks for login again. 8. Clear cookies or log out. 9. Log in through /cgi-bin/koha/mainpage.pl with the same staff user. 10. Open the same plugin URL and reload it several times. Actual result: The login through plugins/run.pl only works for the current request. The browser does not appear to receive/persist the new authenticated CGISESSID needed for later requests to the same plugin page. Expected result: Logging in through a plugin URL should persist the staff session in the same way as logging in through mainpage.pl. Technical note: plugins/run.pl calls get_template_and_user and receives the authentication cookie returned by checkauth. When plugins are enabled, run.pl delegates the response to Koha::Plugins::Handler and the plugin usually renders through Koha::Plugins::Base output helpers. That path does not currently carry the cookie returned by get_template_and_user into the plugin response, so the Set-Cookie header can be lost. This is related in spirit to bug 40943 / bug 37041, where code after login had to use the current authenticated session rather than stale request cookie state, but this issue is specific to plugin execution through plugins/run.pl. I will attach a proposed patch. It is intentionally offered for review as a candidate fix: it propagates the authentication cookie returned by get_template_and_user from plugins/run.pl through Koha::Plugins::Handler to the plugin output helpers, so might be not the best solution or have a backhole. Because this touches authentication cookie propagation for plugin responses, please review carefully from both QA and security perspectives. I am not aware of a privilege escalation here; the concern is that the proposed fix changes where Koha includes staff login cookies in plugin-generated responses. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 42495] New: OPACUserCSS editor points out syntax errors that aren't there
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42495 Bug ID: 42495 Summary: OPACUserCSS editor points out syntax errors that aren't there Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: tadeusz(a)sosnierz.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 198353 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198353&action=e… Screenshot of the issue Entering the following CSS into the OPACUserCSS editor field: ``` div.availability:has(span.noitems) { color: red; } ``` results in an error popup: "Expected RPAREN at line 1, col 26.". The CSS is correct though, and works as expected. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 38327] New: 403 errors when logging back into Koha.
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 Bug ID: 38327 Summary: 403 errors when logging back into Koha. Change sponsored?: --- 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Firstly, I have been unable to recreate this issue myself, either in a production environment or in k-t-d. Many libraries are reporting 403 errors after signing back into Koha. The only remedy seems to be clearing the browser cache. This is happening to sessions in the staff client but also happening frequently in the SCO module. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 42492] New: cleanup_database.pl's --sessdays option could be more efficient
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42492 Bug ID: 42492 Summary: cleanup_database.pl's --sessdays option could be more efficient 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, the --sessdays option for cleanup_database.pl uses a 2 step approach. The first step is to retrieve ALL sessions, and then to run some regular expressions to extract "lasttime" or failing that "ATIME" or "CTIME". Then that time is checked against a 24 hour ago timestamp. We could actually handle that calculation in the SQL and let the database do the heavy lifting so tat we only have to run 1 query. Since it's a cronjob, it probably doesn't matter too much, especially if we use --sessdays regularly (see bug 42491). But... thought I'd highlight it anyway. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0