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

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

08 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 --- Comment #24 from Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> --- Created attachment 196933 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=196933&action=e… Bug 6532: Add tests Sponsored-by: Université Côte d'Azur -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

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

08 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 --- Comment #23 from Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> --- Created attachment 196932 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=196932&action=e… Bug 6532: Add batchMod tool Sponsored-by: Université Côte d'Azur -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

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

08 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 --- Comment #22 from Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> --- Created attachment 196931 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=196931&action=e… Bug 6532: Way to move items to another record in batches This patch adds a new "Move items in a batch" feature, allowing to move multiple items from one bibliographic record to another in a single operation. Test plan: 1. Apply the patch and restart_all. 2. Open a record with at least 2 items (record A). Open or create a second record (record B). 3. On record A: Edit -> "Move items in a batch". Select 1 item, enter record B's biblionumber, submit. => Job finishes. The item appears on record B, not on record A. 4. Repeat with "Delete source bibliographic records if no items remain" checked and move the last item of record A. => Job finishes. Record A is deleted. 5. Place a biblio-level hold on a record with 2 items (record C). Go to Edit -> "Move items in a batch". => A warning icon appears on each item explaining that biblio-level holds will follow if no items remain. 6. Move only 1 item of record C to record B. => The biblio-level hold stays on record C (still has 1 item). 7. Move the last item of record C to record B. => Job report warns that the biblio-level hold has been automatically transferred to record B. => Confirm: record B now has the hold, record C has none. 8. Try entering a non-existent biblionumber as destination. => Error shown before the job is enqueued. Sponsored-by: Université Côte d'Azur -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 42304] New: Add deletedauthorities to cleanup_database.pl
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '26

08 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42304 Bug ID: 42304 Summary: Add deletedauthorities to cleanup_database.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Bug 30888 add a table deletedauthorities. We should be able to purge old data from this table with the script cleanup_database.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 30888] New: Add a table for deletedauthorities
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '26

08 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30888 Bug ID: 30888 Summary: Add a table for deletedauthorities Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Just like deletedbiblio and deleteditems, etc. While the long discussion about merging such tables continues, we should imo add a separate table here for consistency. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 107

[Bug 39453] New: Add attribute type settings for restricting access to extended attributes
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '26

08 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39453 Bug ID: 39453 Summary: Add attribute type settings for restricting access to extended attributes Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This patch introduces a "readonly", "secret" and "hidden" setting for patron attribute types. All restrictions enforced by these new settings are not applied for superlibrarians, where attributes behave as if they have not been set. Readonly make the attributes of this type readonly, they appear on the patrons details page and when editing a patron, but their values can't be changed. Hidden attributes are not visible on the patrons details page or when editing a patron, but can for example be used internally. Secret attributes are basically the same thing as hidden, but the appear with their value masked in the patrons details page, and could be used for sensitive data not all staff members should have access to. One use case (at our library) is to emulate a role based access control by having a number of reserved users as templates for roles. We then have a number of hidden attributes mapping users to these "roles", and a script running nightly that assigns permissions based on this mapping. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

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

08 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Michaela Sieber <michaela.sieber(a)kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39109] New: Add throttling / rate limiting to Koha
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '26

08 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39109 Bug ID: 39109 Summary: Add throttling / rate limiting to Koha Change sponsored?: --- Product: Koha Version: unspecified 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Botnets and web spiders can easily bring a Koha instance down. We should implement optional rate limiting in Koha. It appears there are two plack middlewares we could use: https://metacpan.org/pod/Plack::Middleware::Throttle or https://metacpan.org/pod/Plack::Middleware::Throttle::Lite Throttle supports memcached as a backend, but is more complex. Lite uses an in-memory backend, but has fewer dependencies. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 33552] New: Automatic renewals should only send emails for successes
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '26

08 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33552 Bug ID: 33552 Summary: Automatic renewals should only send emails for successes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org I get frequent complaints from libraries about patrons getting emails saying their items can't auto renew. The typical error message is "too_many", and it's sent every single day. Most of the time, we probably only want to send email notices out when the item has successfully renewed. Then notices like advanced item due, item due, and overdues take over from there. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 41409] New: Streetnumber has a different data type in borrower_modifications
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '26

07 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41409 Bug ID: 41409 Summary: Streetnumber has a different data type in borrower_modifications Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org The streetnumber field is inconsistent between the borrowers and borrower_modifications table - tinytext and varchar(10) respectively -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27