---- Reported by mjr@ttllp.co.uk 2009-03-12 05:17:21 ---- We don't want some patrons to be able to reset their passwords. Is a permission the best way to implement this? ---- Additional Comments From oleonard@myacpl.org 2009-03-12 05:43:23 ---- There is a system preference: OpacPasswordChange. "Enable/Disable password change in OPAC (disable it when using LDAP auth)." ---- Additional Comments From mjr@ttllp.co.uk 2009-03-12 08:23:49 ---- Isn't that system preference a global choice? We want most patrons to be able to reset their passwords (because they're posted out) and just a few to be forbidden (because they're linked to other things). ---- Additional Comments From oleonard@myacpl.org 2009-03-12 08:28:14 ---- Yep, sorry I was hasty in my response. The preference is a global one, not one that can be configured for only certain patrons. --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:05 UTC --- This bug was previously known as _bug_ 3032 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3032 Unknown Component Authentication Using default product and component set in Parameters Actual time not defined. Setting to 0.0 The original reporter of this bug does not have an account here. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. Previous reporter was mjr@ttllp.co.uk.
I wonder if a pre-configured patron attribute would work in this case? Something like the SHOW_BCODE authorized value?
Hm, I have started working on this, but will not be able to finish before the deadlines for 3.14. I am using a new column in categories, so tying it to the patron category. (bug 10796)
I'm closing this one as duplicate because it implements on top of the OpacPasswordReset functionality that is what this bug aims to accomplish. *** This bug has been marked as a duplicate of bug 21890 ***