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

[Bug 24898] New: AddIssue destructively changes transfers
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24898 Bug ID: 24898 Summary: AddIssue destructively changes transfers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 24298 As highlighted in a comment on bug 24298, AddIssue can destructively cancel transfers. The transferto field is forcefully overriden and the reason isn't recorded. We should handle this in a clearer way.. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24298 [Bug 24298] Record if a transfer was triggered by 'return to homebranch' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 30681] New: Allow overlay protection of MARC data by subfield
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30681 Bug ID: 30681 Summary: Allow overlay protection of MARC data by subfield Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 14957 Bug 14957 introduces overlay protection enforced at the MARC tag level. It would be great to be able to specify down to the subfield level in rules. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 [Bug 14957] Write protecting MARC fields based on source of import -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 39263] New: When an ILL request is closed the item and biblio record created for it should be deleted
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39263 Bug ID: 39263 Summary: When an ILL request is closed the item and biblio record created for it should be deleted Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com When an ILL request is closed (I mean the document has been returned to the supplying library) the item and biblio record created for it should be deleted, either in real time (better I suppose) or with a script in cron They were only created to enable the document to be checked out to the patron. If we don't remove them, they will pollute the catalog. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 29587] New: Test mail option in SMTP servers
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29587 Bug ID: 29587 Summary: Test mail option in SMTP servers 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: vimalibre(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Dear Developers, Here is a feature suggestion to Administration > SMTP servers. Test mail option helpful for users to try newly added SMTP server works or not. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 60

[Bug 32142] New: Add HoldFeeMode option "if all items are checked out OR the record has at least one hold already"
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32142 Bug ID: 32142 Summary: Add HoldFeeMode option "if all items are checked out OR the record has at least one hold already" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Relates to Bug 31963. There is an option for the HoldFeeMode system preference "only if all items are checked out and the record has at least one hold already", except it behaved more like "if all items are checked out OR the record has at least one hold already". Bug 31963 fixed this so that the behaviour better matches the description i.e. it says 'and' so that implies BOTH conditions must be met. However we now need an option so that the behaviour from before isn't lost, behaviour like "if all items are checked out or the record has at least one hold already" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48

[Bug 30295] New: Send a notification when a recall is manually cancelled
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30295 Bug ID: 30295 Summary: Send a notification when a recall is manually cancelled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The process would be: 1. Recall is cancelled by library staff or the requester. 2. Notification of the recall cancellation is sent via email and SMS to the recall requester. So it would be exactly the same as the HOLD_MANUAL_CANCEL notice that we currently have for reserves, only relevant to recalls. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 101

[Bug 35948] New: cleanup_database.pl should remove not only finished background jobs
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35948 Bug ID: 35948 Summary: cleanup_database.pl should remove not only finished background jobs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Bug 31969 changed cleanup_database.pl so it removes only finished background jobs. But old background jobs with other statuses will never be removed. I see no use to that -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 36897] New: Make it possible to use select[multiple] and select[size] in a sidebar
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36897 Bug ID: 36897 Summary: Make it possible to use select[multiple] and select[size] in a sidebar Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com https://git.koha-community.org/Koha-community/Koha/src/commit/1ea4a11c2a88f… sets the height of aside fieldset select to a calculated "one fat line" which is fine for <select>, but for <select multiple> and <select size="10"> it turns what should be a multiline box into one line with a nearly invisible scrollbar. The fix is simple, a rule (like the one that exists in bootstrap.scss, which isn't specific enough to overrule the aside fieldset select rule) right after that for select[multiple], select[size] { height: auto; } but I don't quite know how to formulate a test plan for something unused other than by the advanced cataloging editor, which is working around the problem in bug 36589. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 40498] New: Improve style of list transfer form
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40498 Bug ID: 40498 Summary: Improve style of list transfer form Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When you transfer a public list to another user, the style of the form is not consistent with other forms. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 40800] New: TransferArrived needlessly triggers alerts in SIP
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '26

10 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40800 Bug ID: 40800 Summary: TransferArrived needlessly triggers alerts in SIP Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org A SIP check-in incorrectly triggers alerts when receiving items in transit at the destination library due to the NotIssued status combined with the TransferArrived message. When an item in transit is checked in at its destination library via SIP clients (sorters, self-service kiosks), the system generates an alert because it finds both: * NotIssued status (item not checked out to a user), therefore a checkin failure * Transfer receipt message Whilst this combination appropriately provides informational messages in the staff client, it's inappropriate for SIP contexts where automated systems don't require transfer receipt notifications and the alert disrupts workflow. The item status transition works correctly (transit → available), but the SIP response incorrectly signals an alert condition, preventing automated systems like sorters from processing transferred items seamlessly. Expected Behaviour SIP check-in of transit items at destination libraries should complete without alerts, allowing automated systems to process transferred items without manual intervention. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25