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.
It has been designed like that for flexibility. I think it's great.
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.
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.
(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.
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.
(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...