[Bug 29211] New: Simplify options in CheckPrevCheckout system preference
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29211 Bug ID: 29211 Summary: Simplify options in CheckPrevCheckout system preference Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client Assignee: koha-bugs@lists.koha-community.org Reporter: andrew@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29211 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |6906 CC| |jonathan.druart+koha@gmail. | |com Status|NEW |In Discussion --- Comment #1 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- It has been designed like that for flexibility. I think it's great. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6906 [Bug 6906] Show 'Borrower has previously issued $ITEM' alert on checkout -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29211 --- Comment #2 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29211 Kelly McElligott <kelly@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kelly@bywatersolutions.com --- Comment #3 from Kelly McElligott <kelly@bywatersolutions.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29211 --- Comment #4 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29211 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=29272 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29211 --- Comment #5 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29211 --- Comment #6 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- (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... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org