Bug 29211 - Simplify options in CheckPrevCheckout system preference
Summary: Simplify options in CheckPrevCheckout system preference
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Staff interface (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 6906
Blocks:
  Show dependency treegraph
 
Reported: 2021-10-12 14:01 UTC by Andrew Fuerste-Henry
Modified: 2021-10-22 13:17 UTC (History)
3 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 Andrew Fuerste-Henry 2021-10-12 14:01:34 UTC
The CheckPrevCheckout system preference gives 4 options: On, Off, On w/ possible override in patron categories, and Off w/ possible override in patron categories. One only sees the override options in category setup if one of the override-permitting options is selected in the syspref. 

In contrast, the BlockExpiredPatronOpacActions syspref only has On and Off and one always sees the override options in the syspref. OPAC password changes and resets work similarly.

The arrangement we've used for CheckPrevCheckout makes the per-category use of this feature too easy to overlook.
Comment 1 Jonathan Druart 2021-10-19 09:56:42 UTC
It has been designed like that for flexibility. I think it's great.
Comment 2 Andrew Fuerste-Henry 2021-10-19 11:53:33 UTC
Compared to the structure used in OpacPasswordChange, I do not see how this adds flexibility, only how it adds complexity.

In both cases, we're able to set a default behavior system-wide and make individual categories override that default (whether the default is Yes and we've setting some exceptions to No or vice versa).

With CheckPrevCheckout, one gets the very questionable bonus of being able to completely hide the override option from the patron category setup. I can see how that's appealing for a user who's actively chosen not to use it. But on the other hand it greatly reduces the likelihood of new users finding this feature.
Comment 3 Kelly McElligott 2021-10-19 12:01:12 UTC
I agree with Andrew, hiding the option unless the system preference is set a specific way is not helpful and could be very confusing to new users and seasoned Koha users.  We should make the option visible and construct it like other options set at the Patron Category level.
Comment 4 Jonathan Druart 2021-10-19 12:40:30 UTC
(In reply to Andrew Fuerste-Henry from comment #2)
> Compared to the structure used in OpacPasswordChange, I do not see how this
> adds flexibility, only how it adds complexity.
> 
> In both cases, we're able to set a default behavior system-wide and make
> individual categories override that default (whether the default is Yes and
> we've setting some exceptions to No or vice versa).

You cannot turn on/off the behaviour globally.

If you have some categories using different values for change_password and you want to disable it globally, you cannot. The pref is used as the default value.
Comment 5 Andrew Fuerste-Henry 2021-10-22 13:07:45 UTC
Do you mean that if I want to make sure patrons don't change their passwords via the OPAC I need to make sure it's disabled BOTH at the syspref and at the category levels? 
I guess I see your point that this makes disabling OpacPasswordChange a bit more complicated than disabling CheckPrevCheckout. I'd counter that CheckPrevCheckout is a bit more complicated to enable and configure. Looking at the relative strengths and weaknesses of the two constructions, I prefer the way OpacPasswordChange works.
Comment 6 Jonathan Druart 2021-10-22 13:17:30 UTC
(In reply to Andrew Fuerste-Henry from comment #5)
> Do you mean that if I want to make sure patrons don't change their passwords
> via the OPAC I need to make sure it's disabled BOTH at the syspref and at
> the category levels? 
> I guess I see your point that this makes disabling OpacPasswordChange a bit
> more complicated than disabling CheckPrevCheckout. I'd counter that
> CheckPrevCheckout is a bit more complicated to enable and configure. Looking
> at the relative strengths and weaknesses of the two constructions, I prefer
> the way OpacPasswordChange works.

Don't forget that CheckPrevCheckout can be define at patron's level.
If you follow how OpacPasswordChange works you will have to check all patron accounts...