Bug 22854 - Add separate column for administrative locked patron
Summary: Add separate column for administrative locked patron
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-06 06:46 UTC by Marcel de Rooy
Modified: 2023-01-20 01:28 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel de Rooy 2019-05-06 06:46:52 UTC
See bug 21336. This is now arranged by using the same column login_attempts.
login_attempts > pref_value means locked
login_attempts < 0 means admin lock

Do we need one or even two new columns?
[1] locked: regular lock (resulting from entering wrong password), boolean replacing the check attempts > pref. Note that changing the pref might lock or unlock users now. Do we want that?
[2] admin_locked: administrative lock, resulting from e.g. removing GDPR consent, boolean
Comment 1 Marcel de Rooy 2019-05-06 06:48:19 UTC
Any more feedback, Jonathan?
Comment 2 Jonathan Druart 2019-05-06 15:39:15 UTC
I think we could have only 1 more column: the reason of the lock.
If NULL, the account is not locked. The field could be an ENUM with the different reasons.
Comment 3 Katrin Fischer 2019-09-01 22:06:06 UTC
I think that changing the pref resulting in unlocking users makes sense to me. You might figure out you don't want to use the feature after all, so setting a high value will help.

Having 2 columns will allow to have an administrative lock and a too_many_attempts lock at the same time... but it makes me wonder if we could just have 1 new column for the administrative lock as boolean? And keep the failed_attempts behaviour.