If you use the system preference FailedLoginAttempts and a patron becomes blocked after reaching x failed login attempts, the user is prompted to reset their password. The system preference for OPACresetpassword must be turned on to allow patron to reset their password. If a patron experiences an issue resetting their password and needs staff intervention, it would be helpful to make staff aware that the account has been locked due to too many failed attempts on the patron’s detail page. Staff can click the change password button on circulation.pl or moremember.pl to reset the password. However, if staff click the edit button on circulation.pl or moremember.pl to reset the password, it does not change the password for the patron. It would be helpful to prompt staff to use the Change Password link in the staff UI and/or have the ability to update the password from the edit menu.
I agree, staff need both the information that it's locked, and also need a reminder to use the Change Password button - at least until that is fixed. Why does edit - change password not work? Is this intended behaviour?
I'm not sure why edit - change password doesn't unlock the account, but it should. My understanding is that it should work regardless of whichever path Staff take. That being said, some sort of communication to the staff member looking at the patron's account to notify them that the account is locked would be awesome for customer service.
This is still an issue. Even if we're not able to make changing the patron's password via editing, some sort of notification to staff that the patron's account is locked on circulation.pl or moremember.pl would be incredibly helpful.
Locks are now displayed as of 19.05 - the remaining issues are the logging and resetting of login attempts
This is no longer valid as of 19.05. Changing the password via memberentry.pl now resets login_attempts to zero.
(In reply to Nick Clemens from comment #4) > Locks are now displayed as of 19.05 - the remaining issues are the logging > and resetting of login attempts Lock is currently only displayed in the details page. It is not displayed on any other patron page. Should be displayed in edit, change password, check out, accounting, etc. Doesn't make sense that you have to be on a specific page in the patron account to be notified. I see this being worked on, but there should be more: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23979
Library staff took a while to figure out what 'locked' means - especially as it seems to appear on newly created accounts and those where no password has ever been set. Is that the expected behaviour, or was it meant to appear only after failed login attempts? I added this observation to 23979, repeating here to reach the wider audience.
(In reply to Agnes Rivers-Moore from comment #7) > Library staff took a while to figure out what 'locked' means - especially as > it seems to appear on newly created accounts and those where no password has > ever been set. Is that the expected behaviour, or was it meant to appear > only after failed login attempts? I added this observation to 23979, > repeating here to reach the wider audience. I seem to remember a problem with the initial value of the field. Which version are you using exactly?
(In reply to Katrin Fischer from comment #8) > (In reply to Agnes Rivers-Moore from comment #7) > > Library staff took a while to figure out what 'locked' means - especially as > > it seems to appear on newly created accounts and those where no password has > > ever been set. Is that the expected behaviour, or was it meant to appear > > only after failed login attempts? I added this observation to 23979, > > repeating here to reach the wider audience. > > I seem to remember a problem with the initial value of the field. Which > version are you using exactly? 19.11.07 - the new patrons start out locked was really noticeable when we started letting people register through the OPAC after COVID...
I think you might be seeing bug 24379 which was fixed in 19.11.09 To verify you could check what the value is in your database for locked, null or 0.
(In reply to Katrin Fischer from comment #10) > I think you might be seeing bug 24379 which was fixed in 19.11.09 > > To verify you could check what the value is in your database for locked, > null or 0. Good to know, thanks, but ... the examples I tested that were blocked when new, now do have 8 failed attempts. Hard to prove what they had when they were first added, and we are now having staff add new records again. Definitely would like checkout to show if blocked, whatever the reason.
Yes and it will soon with the other bug you commented on.
Hi all! This issue has been resolved in later versions of Koha. I'm closing this bug. Feel free to reopen as needed.