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

[Bug 41737] New: Page title (and thus browser history) exposes patron names, other unnecessary PII
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '26

30 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41737 Bug ID: 41737 Summary: Page title (and thus browser history) exposes patron names, other unnecessary PII Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: jake.bateman(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 192234 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192234&action=e… An example of the floating/quick history menu in Edge displaying full patron names, after a staff user has logged out of Koha. We've recently had a library express privacy concerns relating to the exposure of full patron names, along with application verbs like "issuing to" and "modify user" in the page title, which propagates to browser history and persists after a staff interface logout. While live page titles and browser history of computers used by administrative staff should be considered "not for viewing by unauthenticated users", some cases of computer-sharing or shoulder-surfing in a library setting seems highly likely. This inclusion of full names in page titles to me does not seem strictly necessary. In some testing, we find that a popular CRM also exposes names like this in page titles, while the administrative pages of Gitea and Cloudflare seem to make an explicit effort not to do so. Do we think this warrants changing? I do feel this problem can most effectively be mitigated with process changes, but the question remains; could Koha minimise PII exposure here without impacting functionality? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 41736] New: Move IntranetNav to HTML customizations
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '26

30 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41736 Bug ID: 41736 Summary: Move IntranetNav to HTML customizations Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org It would be nice if IntranetNav system preference was moved to HTML customizations. It would allow for example translations to different languages. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 35655] New: Make it possible to switch off RabbitMQ without any warns in logs/about page
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '26

30 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35655 Bug ID: 35655 Summary: Make it possible to switch off RabbitMQ without any warns in logs/about page Change sponsored?: --- Product: Koha Version: master 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org A recent survey on IRC revealed that a lot of people are still running Koha without RabbitMQ. It's not a small dependency and for smaller libraries it might not be needed ever. Also we still see issues with jobs not being processed correctly that has people turning it off. We should not create any warns or logs, but have a proper switch to turn RabbitMQ off without Koha complaining until we can fully rely on RabbitMQ at least. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 51

[Bug 41726] New: Item search: "Is not" is missing all items where location/collection is empty
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '26

30 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41726 Bug ID: 41726 Summary: Item search: "Is not" is missing all items where location/collection is empty Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When adding a new item to Koha and not setting a location or collection, they are set to NULL in the database. This leads to problems with "is not" searches in the item search. Items with no collection or location are excluded/missing from search results. To test: * Create a new location by adding a new entry to the LOC authorised value category (so it's not used otherwise) * Add 2 items to a record Item A: has the location with the new value Item B: has no location Note the title of your record * Search using the item search: Title: your title (don't forget to truncate with %) Verify your 2 items are found * Amend the search and add to the search criteria: Location is not <your new location> * Verify that you get NO results. Expected behavior: The item with no location should be found In SQL we can see the difference: select * from items where location != "something"; Results including NULL/empty locations: select * from items where location != "something" OR location is NULL; -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 41718] New: draw_guide_grid() passes incorrect arguments to PDF methods, causing warnings.
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '26

30 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41718 Bug ID: 41718 Summary: draw_guide_grid() passes incorrect arguments to PDF methods, causing warnings. Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: chris.nighswonger(a)veritassuperaitsolutions.com Reporter: chris.nighswonger(a)veritassuperaitsolutions.com QA Contact: testopia(a)bugs.koha-community.org Patroncard.pm:219-221: $pdf->Font('Courier'); $pdf->FontSize($font_size); my $strtop_len = $pdf->StrWidth($strtop) * 1.5; There are actually two underlying bugs here: Bug 1 (line 219): Uses hardcoded 'Courier' font name. This may not match a TTF config entry, and the fallback to prFont('Courier') may not work as expected. Bug 2 (line 221): Calls $pdf->StrWidth($strtop) with only one argument, but StrWidth() in PDF.pm expects ($string, $font, $fontSize): # PDF.pm:411 my ( $string, $font, $fontSize ) = @_; $font = C4::Creators::PDF->Font($font); # $font is undef → warnings The correct call should be: my $strtop_len = $pdf->StrWidth($strtop, 'Courier', $font_size) * 1.5; -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 41662] CSRF-vulnerability in opac-patron-consent.pl.
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '26

29 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41662 --- Comment #14 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- Also pushed to 25.05 for 25.05.07! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41662] CSRF-vulnerability in opac-patron-consent.pl.
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '26

29 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41662 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|26.05.00,25.11.01,24.11.12, |26.05.00,25.05.07,25.11.01, released in|22.11.34 |24.11.12,22.11.34 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41662] CSRF-vulnerability in opac-patron-consent.pl.
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '26

29 Jan '26

1 0

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

29 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #236 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- qa script is finding various issues. Like tidy, spelling, filters, permissions. All minor stuff. Tidy stuff might be a pain, we shouldn't use tidy commits anymore, it should be done inline. If the untidy stuff comes from many commits (maybe old commits were done on a machine without the git hook that should tidy automatically), then it would be bad to have all the fixes in the last commit. If that's the situation, it might work to do an interactive rebase and mark all commits for "edit". Then amend them one by one without any change, but it should trigger the tidy hook. Hopefully that doesn't start doing tons of conflicts if commits touch the same places that were untidy. In that case, I think it would be a ok have tidy commit. The history on main shows there are a very few other tidy commits. So we can sneak another one if that's needed to fix an old mess without being a total pain. Hope that helps. ---- Code coverage is good, whether on new code and changes being covered. And on test removal not removing coverage on any still existing code. -- 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 29 Jan '26

29 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #235 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- There is a ghost of PTFS Europe still haunting the the copyright notice in admin/circulation_triggers.pl -- You are receiving this mail because: You are watching all bug changes.

1 0