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

[Bug 27512] New: Block creation of invalid authorised values for LOST, NOTFORLOAN, DAMAGED, RESTRICTED, and WITHDRAWN
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '26

30 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27512 Bug ID: 27512 Summary: Block creation of invalid authorised values for LOST, NOTFORLOAN, DAMAGED, RESTRICTED, and WITHDRAWN Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 Several authorised value categories have inherent limits on what values can be used. Bug 24288 adds text to the screen to tell you about these limits, but doesn't enforce them. It'd be good to just stop a user from saving a value that won't work. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

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

30 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #237 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- Thought I would drop a quick progress update, seeing as I'm not ready to resubmit just yet: What I got sorted: - some UI fixes written - permissions are getting there - removed the link on the Tools page (this is an admin configuration option) The permissions piece has turned out to be more complex than I'd anticipated though I do think it's necessary to add this in properly, so I'm happy to be spending the time on it now :) That does mean that I'm going to push back the resubmission to next week, as I'm still working through my todo list for this. (I'll also rebase it against main to account for 41315 as that one's now been merged.) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36067] New: Inconsistencies in --commit, --confirm for command line scrips
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '26

30 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36067 Bug ID: 36067 Summary: Inconsistencies in --commit, --confirm for command line scrips Change sponsored?: --- Product: Koha Version: master 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)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Our scripts have a mix of --commit and --confirm to 'actually do the job'. I think we should try to be consistent here.. with the most backward compatible option being to make them synonyms in each script. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '26

30 Jan '26

1 0

[Bug 37669] New: Add 'auto_account_expired' to AUTO_RENEWALS_DGST
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '26

30 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37669 Bug ID: 37669 Summary: Add 'auto_account_expired' to AUTO_RENEWALS_DGST Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org We added the account expired error to our digest and find it useful. [% ELSIF checkout.auto_renew_error == 'auto_account_expired' %] [% checkout.item.biblio.title %] (barcode: [% checkout.item.barcode %]) could not be renewed as your account has expired. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 29557] New: auto-renew notices should handle failed renewal due to patron expiration
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '26

30 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29557 Bug ID: 29557 Summary: auto-renew notices should handle failed renewal due to patron expiration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The default auto-renew and auto-renew-digest notices should include logic to tell patrons when their renewals have failed due to upcoming patron expiration. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[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