I don't think foundationwiki wants this.

See InitialiseSettings.php:
DO NOT DISABLE WITHOUT CONTACTING PHILIPPE / LEGAL!
Installed by Andrew, 2011-04-26

In T106067#1458079, @Glaisher wrote:

I don't think foundationwiki wants this.

Actually this extension is not installed on foundationwiki.

In T106067#1458109, @Bugreporter wrote:

In T106067#1458079, @Glaisher wrote:

I don't think foundationwiki wants this.

Actually this extension is not installed on foundationwiki.

Aye, these are on a couple specific highly confidential private wikis (currently arbcom_enwiki, checkuserwiki, legalteamwiki, ombudsmenwiki & stewardwiki) and was there mostly because at the time engineering told us that BlockDisablesLogin would not be completely usable (and may have not even existed at the very start) . After T54453 is closed then most of those issues may be gone and we can reevaluate.

I'd quite like for us to figure out what is needed to get rid of this now, to add to the list with T54453.

As an user on two WMF wikis which do use this tool, I can say that this is hardly used; thankfully. This was designed as aditional security for compromised accounts and other situations where we really wanted to remove access to a wiki. However mistakes using this tool require sysadmin intervention. Perhaps, if we worry about wrong unblocks and users regaining access to information they ain't cleared no more to view, with the fix of T54453, we can think about granting the 'unblock' rights on those wikis to the bureaucrats? Meanwhile and as @Jalexander say, better to keep this for now IMHO; but if we want to get rid of this extension $wgBlockDisablesLogin needs to work as block + disable and totally remove access from blocked accounts.

In T106067#1460810, @MarcoAurelio wrote:

This was designed as aditional security for compromised accounts and other situations where we really wanted to remove access to a wiki.

Sure, $wgBlockDisablesLogin should do this.

In T106067#1460810, @MarcoAurelio wrote:

However mistakes using this tool require sysadmin intervention.

And presumably ordinary reverts? But still, ugh.

In T106067#1460810, @MarcoAurelio wrote:

we can think about granting the 'unblock' rights on those wikis to the bureaucrats?

We don't have a separate 'unblock' right... I don't understand why you would want to do that anyway?

In T106067#1460810, @MarcoAurelio wrote:

Meanwhile and as @Jalexander say, better to keep this for now IMHO

Yes, there is one known issue preventing us from getting rid of it right now, it's the email task marked as a blocker

In T106067#1460810, @MarcoAurelio wrote:

if we want to get rid of this extension $wgBlockDisablesLogin needs to work as block + disable and totally remove access from blocked accounts.

It should do that already other than the aforementioned email issue.

The patch for T54453 (the email blocker bug here) is being merged now.
I think we also need a blocker about writing (and then running) a script to migrate current users who have been disabled via DisableAccount to blocks.

In T106067#1535731, @Krenair wrote:

I think we also need a blocker about writing (and then running) a script to migrate current users who have been disabled via DisableAccount to blocks.

T109060: [DisableAccount] Write a script to migrate disabled accounts with DisableAccount to blocked account

In T106067#1461194, @Krenair wrote:

In T106067#1460810, @MarcoAurelio wrote:

we can think about granting the 'unblock' rights on those wikis to the bureaucrats?

We don't have a separate 'unblock' right... I don't understand why you would want to do that anyway?

But there is a block right and actually, I support MarcoAurelio's idea... On the Checkuser wiki accounts are being maintained by the CU-l list admins. They are the only ones with bureaucrat rights, and thus the only ones to create accounts there. It seems logical to make the bureaucrats the only ones with the ability to block accounts as well.

On the steward wiki every steward has bureaucrat rights, so it's not a problem there either. Maybe on the other private wikis, but I doubt that, to be honest. @Jalexander: can you shed some light here?

T54453: Accounts blocked on wikis with wgBlockDisablesLogin enabled should not continue to receive email notifications is now fixed (and T129738: Blocked accounts on BlockDisablesLogin wikis aren't logged out as well). So is this now in the "just do it" phase?

Can/Should the 'inactive' user group go as well? If so it should be removed
from the accounts that have it first.

Also, is the maintenance script (T141954) ready?

Change 338792 had a related patch set uploaded (by Reedy):
Disable DisableAccount on two wikis were no disabled users

https://gerrit.wikimedia.org/r/338792

Both legalteamwiki and ombudsmenwiki have no users in the inactive group. So proposing we disable the extension there in the first instance

As for everywhere else...

@Reedy Our internal tracking page on stewardwiki differs on the number of people whose accounts were removed using DisableAccount. Is that count correct? I'd be surprised that it were. If so, is it possible to know who did it? Thanks.

In T106067#3041335, @MarcoAurelio wrote:

@Reedy Our internal tracking page on stewardwiki differs on the number of people whose accounts were removed using DisableAccount. Is that count correct? I'd be surprised that it were. If so, is it possible to know who did it? Thanks.

I did it, just before posting them (and that's what I used to decide where to disable the extension now)... Based on who is in the 'inactive' user group... Which is what the migration script in T141954 uses for working out who needs migrating

select count(*) from user_groups where ug_group = 'inactive';

At least, for stewardwiki, that is not correct @Reedy. We have been adding the 'inactive' flag to all blocked accounts manually. You should check who in those private wikis do not have an email and password: those will be the ones really in need to be migrated.

In T106067#3041378, @MarcoAurelio wrote:

At least, for stewardwiki, that is not correct @Reedy. We have been adding the 'inactive' flag to all blocked accounts manually. You should check who in those private wikis do not have an email and password: those will be the ones really in need to be migrated.

Based on that...

In T106067#2901995, @MarcoAurelio wrote:

Also, is the maintenance script (T141954) ready?

The answer to that is no then, based on your comment above?

Any accounts already blocked etc, will just be reblocked if in that group. So no harm done in those cases

mysql:wikiadmin@db1078 [stewardwiki]> select count(*) from user where user_password = "" OR user_email = "";
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)

My on-wiki count is 2. Can you run it with AND user_email instead of OR?

Change 338792 merged by jenkins-bot:
[operations/mediawiki-config@master] Disable DisableAccount on wikis where there are no disabled users

https://gerrit.wikimedia.org/r/338792

@MarcoAurelio is your on-wiki count still at two, or has it changed?

Change 452181 had a related patch set uploaded (by Amire80; owner: Amire80):
[translatewiki@master] Move DisableAccount and RelatedSites to the Legacy group

https://gerrit.wikimedia.org/r/452181

Change 452181 merged by jenkins-bot:
[translatewiki@master] Move DisableAccount and RelatedSites to the Legacy group

https://gerrit.wikimedia.org/r/452181

Change 461726 had a related patch set uploaded (by Reedy; owner: Reedy):
[operations/mediawiki-config@master] Disable DisableAccount on all wikis

https://gerrit.wikimedia.org/r/461726

Change 461726 merged by jenkins-bot:
[operations/mediawiki-config@master] Disable DisableAccount on all wikis

https://gerrit.wikimedia.org/r/461726

Change 461731 had a related patch set uploaded (by Reedy; owner: Reedy):
[operations/mediawiki-config@master] Remove DisableAccount from CommonSettings.php

https://gerrit.wikimedia.org/r/461731

Change 461732 had a related patch set uploaded (by Reedy; owner: Reedy):
[operations/mediawiki-config@master] Remove DisableAccount from InitialiseSettings.php and extension-list

https://gerrit.wikimedia.org/r/461732

Mentioned in SAL (#wikimedia-operations) [2018-09-20T19:57:49Z] <reedy@deploy1001> Synchronized wmf-config/InitialiseSettings.php: Disable DisableAccount T106067 (duration: 00m 51s)

Change 461733 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/tools/release@master] Stop branching DisableAccount

https://gerrit.wikimedia.org/r/461733

Change 461731 merged by jenkins-bot:
[operations/mediawiki-config@master] Remove DisableAccount from CommonSettings.php

https://gerrit.wikimedia.org/r/461731

Mentioned in SAL (#wikimedia-operations) [2018-09-24T22:43:16Z] <reedy@deploy1001> Synchronized wmf-config/CommonSettings.php: Bye bye DisableAccount T106067 (duration: 00m 51s)

Change 461732 merged by jenkins-bot:
[operations/mediawiki-config@master] Remove DisableAccount from InitialiseSettings.php and extension-list

https://gerrit.wikimedia.org/r/461732

In T106067#4613112, @Reedy wrote:

Extension is undeployed... T158594 doesn't block it, that's only in wmf-config, and isn't particularly dependant on the extnesion

I removed {{OnWikimedia}} from https://www.mediawiki.org/wiki/Extension:DisableAccount and removed the entry from https://www.mediawiki.org/wiki/Developers/Maintainers#MediaWiki_extensions_deployed_by_WMF

Thanks Andre! :)

Change 461733 merged by jenkins-bot:
[mediawiki/tools/release@master] Stop branching DisableAccount

https://gerrit.wikimedia.org/r/461733