Last modified: 2012-01-16 10:10:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T15177, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 13177 - Give 'reset-passwords' right to bureaucrats on Wikimedia private wikis
Give 'reset-passwords' right to bureaucrats on Wikimedia private wikis
Status: RESOLVED WONTFIX
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
unspecified
All All
: Lowest enhancement with 7 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-27 21:11 UTC by Guillaume Paumier
Modified: 2012-01-16 10:10 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Guillaume Paumier 2008-02-27 21:11:48 UTC
Hello,

Following the discussion in bug 13165 and a chat with Cary, we came to the conclusion we needed a proper way to close accounts on private Wikimedia wikis when a user is no longer part of the organization / group / committee etc. I thus request that the Password Reset extension <http://www.mediawiki.org/wiki/Extension:Password_Reset> be enabled on some private Wikimedia wikis, namely the internal wiki, the OTRS wiki and the office wiki (provided that you judge the extension safe enough, of course).

I suggest the 'passwordreset' privilege be set to bureaucrats, not to sysops.
Comment 1 Casey Brown 2008-02-27 21:36:15 UTC
(In reply to comment #0)
> be enabled on some
> private Wikimedia wikis, namely the internal wiki, the OTRS wiki and the office
> wiki (provided that you judge the extension safe enough, of course).

It would probably be best to enable this on all private wikis by default if there are no problems with that.

> I suggest the 'passwordreset' privilege be set to bureaucrats, not to sysops.
> 

(Good suggestion.)
Comment 2 Guillaume Paumier 2008-02-28 08:16:48 UTC
On a second thought, I wonder if this is workable along with SUL. This may work as long as logins and passwords are different for all wikimedia wikis, but  I don't know if this would work once SUL is enabled. Well, in this case this bug will be a WONTFIX and I'll reopen bug 13165.
Comment 3 Cary Bass 2008-02-29 17:44:34 UTC
I would add as an addendum that this be enabled in officewiki and boardwiki as well.
Comment 4 Tim Starling 2008-06-05 13:21:40 UTC
The GetBlockedStatus hook is a very odd fit into this extension. I'd like to see that part moved into the core. I think it's good enough for private wikis as it is, but I'd definitely like to see this missing core functionality merged in at some point.
Comment 5 Tim Starling 2008-06-11 13:43:56 UTC
Crikey!

global $wgHooks, $IP;
require_once "$IP/includes/QueryPage.php";

Imagine doing a review and missing that!
Comment 6 Cary Bass 2008-06-25 22:22:25 UTC
Is there a status update on this?  I hate to keep asking the devs to scramble email/passwords :)
Comment 7 Chad H. 2009-02-25 22:23:19 UTC
As of r47569 (bug 15876, pending review), this can be done on-wiki with the 'reset-passwords' right. Could be a simple config change then.
Comment 8 Guillaume Paumier 2009-02-26 13:53:09 UTC
Changing the title of the request accordingly.

Summary of the wikis that would need this:
* internalwiki
* otrs_wikiwiki
* officewiki
* boardwiki

Perhaps auditcomwiki, chairwiki, chapcomwiki, collabwiki, execwiki & wikimaniateamwiki should be added to the batch; Cary would know.

I'm going to ask people from arbcom_enwiki, arbcom_dewiki & arbcom_nlwiki if they want to be included as well.
Comment 9 FT2 2009-02-26 13:58:58 UTC
Worth checking - that a user who /was/ logged in, and whose account is then deactivated by a wiki-crat stops being able to read the wiki from the point their account is deactivated. 

Users whose computer is not accessed by anyone else may leave themselves logged-in, and effectively have indefinite access if this isn't the case.
Comment 10 Andrew Garrett 2009-02-26 14:00:54 UTC
Wouldn't it be more sensible to have an 'approved' group, to which people can be added/removed -- and reassign all the rights assigned to 'user' to that group?

Then you could approve and unapprove people at will.
Comment 11 Cary Bass 2010-03-09 23:48:28 UTC
Is this a matter of simple config change now?  If so, let's make sure we add all the ones that guillom listed under "perhaps", above.
Comment 12 oscar 2010-03-10 00:00:13 UTC
there may be arbcomwikis where this is needed too.
bureaucrats seem the right group to assign this right to indeed.

BUT: is the reset reversible? in other words, can a user later be allowed to resume activities, e.g. when re-elected etc? or must then a new account be made, which is rather un-wiki? i think reversibilty is important here.
Comment 13 Chad H. 2010-03-10 00:41:51 UTC
(In reply to comment #11)
> Is this a matter of simple config change now?  If so, let's make sure we add
> all the ones that guillom listed under "perhaps", above.

The change in bug 15876 was reverted due to some issues. I never got a chance to go back and work on it again.
Comment 14 Nemo 2010-04-18 08:19:05 UTC
I'm still able to read Internal... 

You should set wgBlockDisablesLogin to true in internalwiki, officewiki, boardwiki, auditcomwiki, chairwiki, collabwiki, execwiki, wikimaniateamwiki (otrs_wikiwiki and chapcomwiki already done in bug 22319). This is the most simple solution.
Comment 15 MZMcBride 2010-04-18 08:29:11 UTC
(In reply to comment #13)
> (In reply to comment #11)
> > Is this a matter of simple config change now?  If so, let's make sure we add
> > all the ones that guillom listed under "perhaps", above.
> 
> The change in bug 15876 was reverted due to some issues. I never got a chance
> to go back and work on it again.
Because this user right was reverted in r48780, I'm closing this bug as LATER.

(In reply to comment #14)
> You should set wgBlockDisablesLogin to true in internalwiki, officewiki,
> boardwiki, auditcomwiki, chairwiki, collabwiki, execwiki, wikimaniateamwiki
> (otrs_wikiwiki and chapcomwiki already done in bug 22319). This is the most
> simple solution.
Please file a separate bug for this (preferably adding Cary and Guillom to the CC list for input).
Comment 16 p858snake 2012-01-16 10:07:30 UTC
I'm willing to WONTFIX this, its from 2008, and several other methods have been introduced to "kill off"/disable old accounts on the private wikis.
Comment 17 Effeietsanders 2012-01-16 10:10:30 UTC
yeah, the additional methods validate a wontfix by now. The bug has become obsolete.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links