Bug 3032 - Enhancement: ability to deny some patrons password resets
Summary: Enhancement: ability to deny some patrons password resets
Status: RESOLVED DUPLICATE of bug 21890
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P3 enhancement (vote)
Assignee: MJ Ray (software.coop)
QA Contact: Bugs List
URL: http://opac/cgi-bin/koha/opac-passwd.pl
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-12 05:17 UTC by Chris Cormack
Modified: 2019-02-20 16:08 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 Chris Cormack 2010-05-21 01:05:36 UTC


---- 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.

Comment 1 Owen Leonard 2012-07-31 13:25:39 UTC
I wonder if a pre-configured patron attribute would work in this case? Something like the SHOW_BCODE authorized value?
Comment 2 Katrin Fischer 2013-09-30 21:43:12 UTC
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)
Comment 3 Tomás Cohen Arazi 2019-02-20 16:08:47 UTC
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 ***