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

[Bug 39650] New: Updating the protected flag is not possible when creating a new patron
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39650 Bug ID: 39650 Summary: Updating the protected flag is not possible when creating a new patron Change sponsored?: --- 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: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When creating a new patron, it is not possible to update the protected flag even when logged in as a superlibrarian. It is still possible to update this flag when updating an existing patron. This seams liked to bug 36085. The check to set the authorization flag CanUpdateProtectPatron (witch restrict the update to only superlibrarian) is itself in a check for op 'edit_form', 'cud-save' or 'duplicate'. The flag CanUpdateProtectPatron is not passed to the template when creating a new user as the op is 'add_form' even when logged in as a superlibrarian. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 37815] New: Protected flag permissions should be honoured in the REST API
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37815 Bug ID: 37815 Summary: Protected flag permissions should be honoured in the REST API 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: jake.deery(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com (follow-up from bug 36085) We now restrict access to the protected flag in the GUI. This should also be replicated out to the REST API. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 39128] New: When Modifying a record using a template in cataloguing there is no link back to the modified record
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39128 Bug ID: 39128 Summary: When Modifying a record using a template in cataloguing there is no link back to the modified record Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucy.vaux-harvey(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Steps to reproduce this: - From a catalogue record, go to Edit > Modify using a template - At the batch record modification page select a MARC modification template to apply - Click on Modify selected records - You are taken to the Job enqueued page - There is no way to link back to your modified record from this page For this function where only one record can be modified at a time, the user should be automatically returned to the normal view of the record (there will not usually be any need to see the background jobs pages) or from the Jobs enqueued page there should be a link back to the record. As it stands now you have to either run a new search, use the browser Back button or click through to the background jobs and then pick up the link to the record from there. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 28357] New: E-mail Verification
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28357 Bug ID: 28357 Summary: E-mail Verification Change sponsored?: --- Product: Koha Version: unspecified 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 Dead e-mails are a pain to deal with. It would be great if e-mail notifications were verified, regardless of registering online or in person. If an e-mail address is entered by staff, Koha should have a flag to indicate if the address has been verified. When an account is saved or updated, it should check if an e-mail address has been entered. If so, if it has not been verified, it should send a verification e-mail to the address. When the patron receives it, they should have to click something or login to complete the verification. The address is marked in their account as verified. If the address is changed at all, they have to re-verify. Staff who receive notice that the e-mail has problems (dead, full, etc) should have a flag they can set on the account to mark the address as bad, and the reason why. The patron would then have to supply a new e-mail address and verify again. While the account is flagged with a bad e-mail, notifications to that address should be turned off. If they have another form of notification, Koha could send them a notification that the e-mail address they supplied is no longer working, and needs to be corrected. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 23908] New: Require patrons to confirm their email address
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23908 Bug ID: 23908 Summary: Require patrons to confirm their email address 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: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Koha should require patrons to confirm their email address (by sending a confirmation email to the address) when the email is changed. This would prevent typos. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 32136] New: E-mail testing
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32136 Bug ID: 32136 Summary: E-mail testing 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 Email Checker (email-checker.net) is a tool that does some e-mail validation. Step 1 Koha already does, but I am curious if Koha could do steps 2 and 3? How do we verify an email ? First it checks for email address format. Then make sure that domain name is valid. We also check whether it’s a disposable email address or not. In the final step, It extracts the MX records from the domain records and connects to the email server (over SMTP and also simulates sending a message) to make sure the mailbox really exists for that user/address. Some mail servers do not cooperate in the process, in such cases, the result of this email verification tool may not be as accurate as expected. The tool itself limits you to 5 checks per hour. There is a premium plan, and also an API. Only 5 lookups per hour, in free plan. Upgrade to our premium plan or use the API. This would be a great tool when creating a patron record. With the way it is worded, I don't know if the API is free to use, but if not, I'm wondering if we could incorporate the same methods in Koha? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 23681] New: Patron restrictions should be user definable
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23681 Bug ID: 23681 Summary: Patron restrictions should be user definable 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: andrew.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently the patron restrictions are hard coded as enums in borrower_debarments.type, the available values are 'SUSPENSION','OVERDUES','MANUAL','DISCHARGE'. We (PTFS Europe) have a customer requirement to: - Provide a select box when adding a patron restriction containing user defined values for restriction types, the user defined values should be defined as authorised values - Ensure a default value if no restriction type is selected - Allow the name of the default value to be modifiable - Ensure that if a restriction type authorised value is removed, any restrictions that use it should revert to the default value - Make the selection of restriction type optional via a syspref Currently, at the DB level, the default value is 'MANUAL'. The plan is to: DB MIGRATION ------------ - Add authorised_value_categories row for 'PATRON_RESTRICTIONS' - Add authorised_values.core, default value 0 - Implies AV cannot be deleted and authorised_values.authorised_value cannot be changed - Add new borrower_debarments.debarment_type column - Select distinct values from borrower_debarments.type - For each $value: - Create AV rows: - authorised_values.authorised_value = $value - authorised_values.lib = $value - authorised_values.core = 1 - ** Note id of each new row, associated with $value - update borrower_debarments.debarment_type to be appropriate AV id - Remove borrower_debarments.type OTHER STUFF ----------- - AV UI (and anything else that can bring about AV modification), should respect "core" - Modify Patron::Debarments appropriate functions to abstract underlying changes i.e. we maintain backward compatibility with the way they currently work, we just obfuscate the fact that the "type" comes from a different table - Overload AuthorisedValue::delete to allow us to call optional functions after delete - in a sane world this would be a trigger. This will allow us to set appropriate patron_debarments.debarment_type rows to default value upon AV deletion -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 412

[Bug 20447] New: Add support for MARC holdings records
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20447 Bug ID: 20447 Summary: Add support for MARC holdings records Change sponsored?: --- Product: Koha Version: master 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: ere.maijala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org RFC: https://wiki.koha-community.org/wiki/MARC_Holdings_Records_RFC This is placeholder for upcoming activity. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 766

[Bug 32542] New: Coce images not appearing in staff client
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32542 Bug ID: 32542 Summary: Coce images not appearing in staff client 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1. Have Coce on, use 'https://coce.bywatersolututions.com' as the CoceProviders if needed. Select all providers 2. Turn on IntranetCoce and OpacCoce. 3. Do a OPAC search to retrieve some Coce images on both the OPAC results page and detail. 4. Do the same search and look at the same detail pages in the staff client. Nothing appears. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 17110] New: Lower CSRF expiry in Koha::Token
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '26

26 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17110 Bug ID: 17110 Summary: Lower CSRF expiry in Koha::Token Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 26