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

[Bug 25947] New: Improve locked account message
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25947 Bug ID: 25947 Summary: Improve locked account message 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 106643 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106643&action=e… Warning messages in the patron details When using FailedLoginAttempts, a patron's account is blocked after X many failed login attempts on the OPAC. When that happens, a message 'Account has been locked.' appears on the patron account details page. This message does not indicate why or how it was blocked. I suggest we change it to 'Account has been locked due to too many failed login attempts'. Furthermore, the font is dark red whereas the font for other warnings (such as wrong category or unpaid fines) is bright red and bold. To test: 1. Change FailedLoginAttempts to a small number, like 2 2. Go to a patron's account and copy their username (while you're there, change the password and add some fines, too) 3. In the OPAC, try to log in with the username and a wrong password several times 4. Go back to the patron's account in the staff interface 5. Note that there is no indication as to why the patron's account is locked and that the font color and weight does not match the other warnings. Also, there is no button to change the password next to the warning. When a patron has unpaid fines or is in the wrong category, there is a button to either pay/writeoff the fines or change the category next to the warning. I would add a button that says 'Change password' next to the locked account warning. This might be outside the scope of this bug, but I think it would improve usability. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 75

[Bug 35885] New: ERM vendor sort order
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35885 Bug ID: 35885 Summary: ERM vendor sort order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: Laura.escamilla(a)bywatersolutions.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Currently the vendor drop-down list shows the vendors in the order that they were added to the Acquisitions module. It would be ideal if the vendors were sorted in alphabetical order so that libraries could easily locate their selection. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 33224] New: OPACHoldsIfAvailableAtPickup and no on-shelf holds don't mix well
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33224 Bug ID: 33224 Summary: OPACHoldsIfAvailableAtPickup and no on-shelf holds don't mix well Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This is the situation: The library wants to prevent on-shelf holds as much as possible, only allowing for transfers if the copy at the patron's library is not available. For example, a record with a checked out copy at Centerville and an available copy at Midway. A Centerville patron should be able to place a hold for pickup at Centerville (the hold will appear on Midway's holds to pull for transfer to Centerville). A Midway patron should not be able to place a hold for pickup at Midway since the Midway copy is available. Does that make sense? This is the setting: - circulation rules allow on-shelf holds only if any unavailable - OPACHoldsIfAvailableAtPickup is set to Don't allow Currently, this allows the Midway patron to place a hold for pickup at Midway. To test: 1. Set up the circulation rule so that on-shelf holds are allowed ('Yes') 2. Create a record with two items, one at Centerville and one at Midway 3. Check out the Centerville item 4. Log into the OPAC with a Midway patron (I used Henry Acevedo) 5. Try to place a hold on the record --> Midway is not a valid pickup location (correct behaviour) 6. Cancel 7. Change the circulation rules so that on-shelf holds are only allowed 'if any unavailable' 8. Try to place a hold on the record from the OPAC again --> The system allows you to place the hold for pickup at Midway (incorrect behaviour) 9. Optionally, check the Holds to pull for Midway (the hold is there, it shouldn't) 10. Optionnaly, check in the Midway item (it is trapped for Henry's hold) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 38095] New: Custom patron messages should have access to information about the logged-in library they were sent from
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38095 Bug ID: 38095 Summary: Custom patron messages should have access to information about the logged-in library they were sent from Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 29393 Bug 29393 added the ability to define custom notices that could be sent from the patron account page. It would be useful if these notices had access to information about the logged-in library from which the notice was triggered. For example, we'd like to use this feature to add an email template for notifying a patron that a lost library card was found and turned in to the library. That notice should include which branch found the card and triggered the notice, which may not be the patron's home library. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29393 [Bug 29393] Ability to send emails from patron details page -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 37832] New: Rentaldiscount is not required to be decimal like other similar fields in smart-rules.tt
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37832 Bug ID: 37832 Summary: Rentaldiscount is not required to be decimal like other similar fields in smart-rules.tt Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: stalkernoid(a)gmail.com Reporter: stalkernoid(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 38313] New: RESTOAuth2ClientCredentials pref description is confusing
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38313 Bug ID: 38313 Summary: RESTOAuth2ClientCredentials pref description is confusing 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: jake.deery(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In Bug 20734, we added a string informing sysadmins that Net::OAuth2::AuthorizationServer is required for the RESTOAuth2ClientCredentials syspref to be operable. I don't think we need this anymore, as for git installs this is in the cpanfile, and for package installs this is included as a dependency for koha-perldeps. Could we remove this string to a) tidy things up, and b) avoid confusion of people installing the cpan module twice (once in Debian, and once in cpan-land)? Jake. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 38760] New: koha-mysql doesn't work with encrypted database connection
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38760 Bug ID: 38760 Summary: koha-mysql doesn't work with encrypted database connection Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: cornelius.amzar(a)bsz-bw.de, markus.john(a)bsz-bw.de, robin(a)catalyst.net.nz We noticed that the koha-mysql command doesn't send the right parameters when using an encrypted database connection. We are using the solution as outlined in bug 36026. If you add a warn to see the connection command as created by koha-mysql, you will see something like: mysql --host=<host> --user=XXX --password=XXX koha_XXX The parameters required for the encrypted connection (--ssl and --ssl-ca) are missing/unsupported. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 31167] New: Only mark due dates in the past red on overdues report
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31167 Bug ID: 31167 Summary: Only mark due dates in the past red on overdues report Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 27996 Bug 27996 added formatting to the due dates on the overdues report, but we forgt that it doesn't only show due dates in the past. If you check the checkbox on top, also current checkouts with due dates in the future will display. They area also formatted in red now. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27996 [Bug 27996] Format of "Due date" on Circulation > Overdues page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 37546] New: We should output error messages alongside error codes for z39.50 errors
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37546 Bug ID: 37546 Summary: We should output error messages alongside error codes for z39.50 errors Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When performing a z39.50 search during cataloging, there are various errors that can be returned from ZOOM.. these have errors codes, but they also have nicer strings too.. which we're hiding! We should return both in the result. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 31019] New: UNIMARC field help link when cataloguing - default location needs updating
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31019 Bug ID: 31019 Summary: UNIMARC field help link when cataloguing - default location needs updating Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When cataloguing on a UNIMARC installation, clicking on the ? for field help now goes to https://www.ifla.org/, for example for 500: https://www.ifla.org/#500. This looks like a redirect from https://archive.ifla.org/#500 (the MarcFieldDocURL system preference indicates that http://archive.ifla.org is used if nothing is entered in the system preference). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38