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

[Bug 40791] New: Allow choice of which Overdue messages can be patron preferences
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40791 Bug ID: 40791 Summary: Allow choice of which Overdue messages can be patron preferences Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: philip.orr(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com In Bug 30515, we are discussing adding a new system preference UsePatronPreferencesForOverdueNotices to let patrons control which overdue messages are sent by mail in their messaging preferences. For many libraries it would still be necessary to set a certain overdue notice (say the third overdue notice) as "mandatory for print message". Jonathan suggested to reuse the aforementioned pref and make it multivaluated with 3 values possible: ODUE, ODUE2, ODUE3. Then: - if at least one is selected then patrons can edit it/them - if none selected, we don't allow the patrons to modify any This would be the simplest way to extend the functionality of Bug 30515. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 30515] New: Move Overdue transports to patron messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30515 Bug ID: 30515 Summary: Move Overdue transports to patron messaging preferences 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The idea of this bug would be to allow patrons to choose which format they would like to receive their overdues in while maintaining at least one selection as mandatory -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 111

[Bug 29997] New: Allow to send email notification when a serial issue is late
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29997 Bug ID: 29997 Summary: Allow to send email notification when a serial issue is late Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Serials Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 41251] New: Ability to edit linked serials when editing items needs to be optional
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41251 Bug ID: 41251 Summary: Ability to edit linked serials when editing items needs to be optional Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 37116 added the ability to edit linked serials when editing items. There is no way to turn this off and it has created some extra clicks and frustration for librarians who do not want the option. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 54

[Bug 42035] New: Add diff support to APIKEYS CREATE and DELETE action logs
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42035 Bug ID: 42035 Summary: Add diff support to APIKEYS CREATE and DELETE action logs Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 37940 The action logging for the APIKEYS module (Koha/ApiKey.pm) already has diff support for MODIFY, REVOKE, and ACTIVATE actions. However, CREATE and DELETE actions do not pass the $original parameter. Affected calls in Koha/ApiKey.pm: - APIKEYS/CREATE (~line 84): logaction( 'APIKEYS', 'CREATE', $self->patron_id, $self, undef ); (passes $self as $infos but no $original; for CREATE, $self represents the new state) - APIKEYS/DELETE (~line 142): logaction( 'APIKEYS', 'DELETE', $patron_id ) (no info or original passed at all) For CREATE, passing $self as both $infos and $original (or with undef original) would allow the viewer to show what was created. For DELETE, the API key object should be fetched before deletion and passed as both $infos and $original so the log shows what was deleted. This is important for security audit trails. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37940 [Bug 37940] [OMNIBUS] All modification logged via action logs should include original to create JSON diff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 22972] New: Proposal for enriching the bibliographic records with standard identifiers from authority data
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22972 Bug ID: 22972 Summary: Proposal for enriching the bibliographic records with standard identifiers from authority data Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Thinking in terms of linked data, it would be of profit to have as much of standard identifiers in the bibliographic data produced by the library as possible. Libraries use authority data coming from official sources (like LoC, SUDOC, etc.) or enrich their locally created authority records with standard identifiers (e.g. viafId, ISNI, Wikipedia). This information is linked to the bibliographic record by the Koha-specific subfield $9 which is illegal in terms of MARC 21 and does not mean anything outside of the local Koha ecosystem. A record moved out of a local Koha catalogue (downloaded, exported) loses the linked-data connection to other objects (like authors, subjects etc.), which are then identified only by strings. To make this connection between bibliographic access point and objects identified by universal identifiers more permanent outside of the local environment, the standard MARC 21 $0 subfield could be used. (UNIMARC has to be examined - $3 subfield?) The required changes would include at least: C4::AuthoritiesMarc::merge function, the authority plugin, some new system preferences, optionally display templates and also a script to update the existing biblio records. New possible system preferences needed: - switch the feature on/off - source of the standard IDs (possibly different for different biblio fields?) (standard in MARC 21 authority: 024, but may be also 010/035) (a list) - how many ids should be copied (= how may $0 added): only the first found or all of them - if an extra link/icon should be generated in display (OPAC / librarian) Please, share your comments about this idea. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 72

[Bug 39522] New: Add hooks to allow 'Valuebuilder' plugins to be installable
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39522 Bug ID: 39522 Summary: Add hooks to allow 'Valuebuilder' plugins to be installable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: jacob.omara(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org We should allow the cataloguing or 'valuebuilder' plugins to be installable with the standard plugin architecture. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 72

[Bug 16291] New: koha-remove --purge should also delete /etc/koha/sites/instance
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16291 Bug ID: 16291 Summary: koha-remove --purge should also delete /etc/koha/sites/instance Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org It would be useful if 'koha-remove --purge' also deleted a /etc/koha/sites/instance dir -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 24237] New: The 406 response on the biblios end point should be more discoverable
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24237 Bug ID: 24237 Summary: The 406 response on the biblios end point should be more discoverable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com Other endpoints default to an application/json response by default regardless of the Accept headers in the request. For consistency, we should do the same on the biblios endpoint.. I'm thinking a 406 still, but with a JSON encoded error message in the body explaining the available Accept headers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 32454] New: Patron do not have Overdue Triggers format choice
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32454 Bug ID: 32454 Summary: Patron do not have Overdue Triggers format choice 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Unlike most other notifications, patrons do not get to define what format they receive overdue notices. So, if a library offers all formats, the patron will get all formats, provided they have the address/phone number needed. Why these notices are handled differently from other notices, I do not know, but it would be nice if patrons had a choice in how they get these notices. If it is a matter of them getting always getting a notice, perhaps one format should be on by default and not changeable unless they have the required elements for another delivery format. Having a global setting for patrons on overdues is not patron friendly. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2