Bug 20460

Summary: Changing password through the patron edit form does not reset failedloginattempts or log change
Product: Koha Reporter: Jessie Zairo <jzairo>
Component: PatronsAssignee: Bugs List <koha-bugs>
Status: CLOSED WONTFIX QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: andrew, arm, cbrannon, gmcharlt, kyle.m.hall, mfuerst, nick, sally.healey
Version: 17.11   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21312
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Jessie Zairo 2018-03-22 14:25:27 UTC
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.
Comment 1 Agnes Rivers-Moore 2018-06-18 20:56:33 UTC
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?
Comment 2 Martha Fuerst 2018-10-11 16:45:33 UTC
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.
Comment 3 Martha Fuerst 2019-06-12 19:21:49 UTC
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.
Comment 4 Nick Clemens (kidclamp) 2019-06-21 17:12:53 UTC
Locks are now displayed as of 19.05 - the remaining issues are the logging and resetting of login attempts
Comment 5 Andrew Fuerste-Henry 2019-11-06 13:51:45 UTC
This is no longer valid as of 19.05. Changing the password via memberentry.pl now resets login_attempts to zero.
Comment 6 Christopher Brannon 2020-10-26 17:33:46 UTC
(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
Comment 7 Agnes Rivers-Moore 2020-10-26 18:27:25 UTC
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.
Comment 8 Katrin Fischer 2020-10-26 19:39:28 UTC
(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?
Comment 9 Agnes Rivers-Moore 2020-10-26 19:50:29 UTC
(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...
Comment 10 Katrin Fischer 2020-10-26 19:53:49 UTC
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.
Comment 11 Agnes Rivers-Moore 2020-10-26 22:07:34 UTC
(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.
Comment 12 Katrin Fischer 2020-10-26 22:08:32 UTC
Yes and it will soon with the other bug you commented on.
Comment 13 Andrew Fuerste-Henry 2021-06-23 12:46:22 UTC
Hi all! This issue has been resolved in later versions of Koha. I'm closing this bug. Feel free to reopen as needed.