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

[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 37041] New: Logging into addbiblio.pl triggers a 403
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Bug ID: 37041 Summary: Logging into addbiblio.pl triggers a 403 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As Michal Kula noted on Mattermost, trying to log into http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=99… in main will yield a bizarre HTTP response that includes headers for a 403 response and a 200 response... This is partially due to bug 37040, but it's mostly due to a bug in addbiblio.pl where the form builder is generating a 403 that gets printed before the 200 response somehow... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 78

[Bug 34460] New: Patron category should regulate if account can have permissions
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34460 Bug ID: 34460 Summary: Patron category should regulate if account can have permissions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Permission management would be simpler if there were a setting in patron categories that indicate whether that category of patron can have permissions. - If no, that option would not appear in the patron menu. - If patron category is changed to a category that does not allow permissions, any existing permissions should be cleared when change is saved. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[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

[Bug 42491] New: Debian daily cronjob with cleanup_database.pl should only delete old sessions
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42491 Bug ID: 42491 Summary: Debian daily cronjob with cleanup_database.pl should only delete old sessions 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 In the Debian packages there is a daily cronjob that runs cleanup_database.pl with the --sessions option, which deletes ALL sessions. Typically, the daily cronjob is scheduled to run early in the morning, but it's still a pain for early users of Koha to lose their session due to this cronjob. By default, we should be adding at least --sessdays 1 to the cronjob, so that only sessions that haven't been used for 1 day or were created 1 day ago are cleaned up. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 39730] New: Remove GetUnprocessedSuggestions from C4/Suggestions.pm
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39730 Bug ID: 39730 Summary: Remove GetUnprocessedSuggestions from C4/Suggestions.pm Change sponsored?: --- 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: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org See https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23990 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 6532] Way to move items to another record in batches
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 --- Comment #46 from David Nind <david(a)davidnind.com> --- I added a couple of follow-ups: - The number of tests was wrong, so the tests failed - The qa script complained about the permissions for the test file - I updated the form label for the option to delete the source bibliographic record (as you can only move items from one record): Delete source bibliographic records if no items remain. To Delete source bibliographic record if no items remain. An observation about the warning, but I don't know if I'm correct or not: - When only a bibligraphic-level hold, the warning is: The source record has 1 biblio-level hold(s). These holds will remain on the source record after the move. - When only an item-level hold, warning is the same. - When there is both a bibliograohic and item-level hold, the warning is also the same: The source record has 2 biblio-level hold(s). These holds will remain on the source record after the move. - Not sure if this needs updating to reflect a bibliographic and item level holds. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0