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

[Bug 41641] New: Link emails sent from cart or lists to existing patron accounts
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41641 Bug ID: 41641 Summary: Link emails sent from cart or lists to existing patron accounts Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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 When sending a list or a cart to a patron via email, it is great that we are not limited to existing patrons, but it would also be nice if the email we are sending to would check if the email is going to a matching patron account so the email could be added to their list of notices in their account. It would also be great if instead of entering an email address, we could search for a patron account and select from any email addresses listed in their account, and then linking to their notices as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 41657] New: Patron messaging preferences - list notices in alphabetical order
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41657 Bug ID: 41657 Summary: Patron messaging preferences - list notices in alphabetical order Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The order of the notices shown for 'Patron messaging preferences' seems somewhat random. I recommend putting them in alphabetical order. To reproduce: 1. In the staff interface, go to Administration > System preferences 2. Set UseRecalls to Use 3. Set ILLModule to Enable 4. Go to Patrons 5. Add a new patron: + New patron > Patron 6. Scroll down to the "Patron messaging preferences" section (at the bottom) 7. Note the order of the notices: - Hold filled - Hold reminder - Return recalled item - Recall awaiting pickup - Interlibrary loan ready - Interlibrary loan unavailable - Interlibrary loan updated - Item checkout - Auto renewal - Advance notice - Item due - Item check-in 8. If you go to Administration > Patrons and circulation > Patron categories, and edit any patron category, the order is the same. 9. If you go to the OPAC, log in as a patron, and go to the 'Messaging' section, note that they are in alphabetical order. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 29194] New: Patron messaging preferences should be ordered
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29194 Bug ID: 29194 Summary: Patron messaging preferences should be ordered 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 28153 comment 3 suggests the preferences should be ordered Alphabetical could differ in different languages, and I think that would be confusing I would suggest a 'logical' ordering - Holds options together, ILL options together, and item option in process order: Checkout, Predue, Due, Checkin Currently the table is ordered by 'message_attribute_id' and these is not a simple way to sort as desired -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 40872] New: opac/unapi type not detected by tidy.pl
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40872 Bug ID: 40872 Summary: opac/unapi type not detected by tidy.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 41498] New: Documentation maintenance tasks - December 2025
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41498 Bug ID: 41498 Summary: Documentation maintenance tasks - December 2025 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de This is a bug to record documentation maintenance tasks against for December 2025. This includes: - Fixing build errors and warnings - Link checking - Spell checking - Any other maintenance task -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 10446] System preference maxoutstanding is poorly named
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10446 Christopher Brannon <cbrannon(a)cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon(a)cdalibrary.org --- Comment #19 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- If anyone ever gets around to this bug again, the description is misleading on this setting as well. It says it is based on fines, but it should be account balance, right? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33495] New: Patron search results can be misleading
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33495 Bug ID: 33495 Summary: Patron search results can be misleading Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If I search for a patron barcode, particularly one that has been deleted, there is a slight chance that this number could be part of another searchable field in the patron record, like a phone number. In that case, the Koha might just go straight into the record without skipping a beat, and staff make the assumption that they are in the correct record. It would be preferable that unless an exact match is made on search criteria, Koha only displays search results rather than going straight into the record, if it is only the closest match. There is still room for error, but this would help shave that rate down a bit. Close or partial matches should not go straight into a record. If you are typing a patron name or number and the suggestions show up, it is on the staff member for picking the right or wrong patron. But if the system is throwing us into a record based on loose information, that is a problem. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 38677] New: XSLT doesn't follow frameworks
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38677 Bug ID: 38677 Summary: XSLT doesn't follow frameworks Change sponsored?: --- Product: Koha Version: 24.05 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: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Users often assume the visibility checkbox on fields on the frameworks will change if it's visible on the OPAC details page. It would be great if we could build/update the XSLT based on those fields (or additional fields for details, search results, for both OPAC and Staff. This would be good for users being able to make changes without access to the XSLT. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 27309] New: Add plugin hooks for capturing raw passwords (NNPDB)
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27309 Bug ID: 27309 Summary: Add plugin hooks for capturing raw passwords (NNPDB) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Bug 22706 tried to add hooks to make it possible to implement support for the Norwegian National Patron Database (NNPDB) via a plugin. That bug added a new hook called check_password, and this was called in two places: 1. In Koha::Patron::set_password https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/P… 2. In Koha::Patron::store https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/P… The second call to check_password was initially placed after this call: $self = $self->SUPER::store; so we could send both the raw password and the borrowernumber to the hook. This is of course a problem, since checking the password after the borrower has been stored means we can't reject the user completely based on the password. And so the call to the check_password hook was placed bwfore this line. This meant that the check_password hook could not serve the intended purpose of implementing the NNPDB. This bug proposes a new plugin hook, to be implemented after the ->store, to finally make it possible to implement NNPDB as a plugin. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 40897] New: Uneven field lengths in additem.tt
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '26

20 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40897 Bug ID: 40897 Summary: Uneven field lengths in additem.tt Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Created attachment 187036 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=187036&action=e… Example IF you look at the additem form on additem.tt the input lengths are not the same width. Fields with select2 dropdowns are longer than those without. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26