Summary: | Changing password through the patron edit form does not reset failedloginattempts or log change | ||
---|---|---|---|
Product: | Koha | Reporter: | Jessie Zairo <jzairo> |
Component: | Patrons | Assignee: | 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
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. |