bugs wrote:

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

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.

bastique.bz wrote:

I would add as an addendum that this be enabled in officewiki and boardwiki as well.

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.

Crikey!

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

Imagine doing a review and missing that!

bastique.bz wrote:

Is there a status update on this? I hate to keep asking the devs to scramble email/passwords :)

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.

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.

FT2.wiki wrote:

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.

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.

bastique.bz wrote:

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.

oscar.wiki wrote:

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.

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

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.

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

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.

yeah, the additional methods validate a wontfix by now. The bug has become obsolete.