[BUG] CentralAuth hide/suppress does not block Special:EmailUser
Open, Needs TriagePublicBUG REPORT
Actions

Assigned To

None

Authored By

	dom_walden
	Sep 3 2019, 12:37 PM

Description

What is the problem?

A user who is hidden/suppressed via Special:CentralAuth can still use Special:EmailUser.

Special:EmailUser does not use PermissionManager::getPermissionErrors(), so does not trigger the onGetUserPermissionsErrorsExpensive hook which CentralAuth uses.

When suppressing a user, CentralAuth automatically creates a local database block which blocks the user from email. However, this block could be removed or not created in the first place if the user already has a block.

Steps to reproduce problem

Need to be logged in as a user with centralauth-oversight right

Go to Special:CentralAuth/$user
Click on the "Account is hidden completely" radio button, and then "Set status"
CentralAuth automatically creates local database blocks. To simulate where it has failed to create a local block, go to Special:BlockList, find the newly created block, and unblock it
Login as $user, go to Special:EmailUser

Expected behavior: You are blocked with a message like "You cannot edit because your account is blocked."
Observed behavior: You can send an email.

Related Objects

Mentioned Here: T224341: Locked account can receive password reset email

Event Timeline

dom_walden created this task.Sep 3 2019, 12:37 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 3 2019, 12:37 PM

JJMC89 moved this task from Backlog to User blocking on the MediaWiki-User-management board.Sep 12 2019, 5:45 AM

MarcoAurelio added a project: Stewards-and-global-tools.Nov 4 2019, 5:54 PM

MarcoAurelio moved this task from Untriaged to High priority on the Stewards-and-global-tools board.Nov 4 2019, 5:59 PM

DannyS712 edited projects, added MediaWiki-Blocks; removed MediaWiki-User-management.Apr 25 2020, 12:09 AM

Restricted Application added a project: MediaWiki-User-management. · View Herald TranscriptApr 25 2020, 12:09 AM

Aklapper removed a project: MediaWiki-User-management.Apr 25 2020, 12:23 PM

DannyS712 subscribed.Dec 6 2020, 4:37 AM

Base subscribed.Jan 8 2021, 10:07 PM

Zabe subscribed.Apr 15 2021, 7:30 PM

Bugreporter moved this task from Backlog to Global account management (lock/hide/suppress) on the MediaWiki-extensions-CentralAuth board.Jan 17 2024, 12:53 PM

Johannnes89 subscribed.Apr 14 2025, 7:18 PM

Restricted Application added a project: Trust and Safety Product Team. · View Herald TranscriptApr 14 2025, 7:18 PM

Note, for WMF wikis - in practice we don't hide users unless we are also locking users, which will alleviate the user story

But I'm a bit lost, is this user story "When someone is unblocked (step 3) - they are not blocked" ?

This story leaves off setting "lock" at all - why would you expect an error that you are locked, if you are not locked?

Without having the user story updated, this looks like it can be closed as not a bug.

I have no memory of raising this bug...

In T231867#10741087, @Xaosflux wrote:

Note, for WMF wikis - in practice we don't hide users unless we are also locking users, which will alleviate the user story

Cool.

But I'm a bit lost, is this user story "When someone is unblocked (step 3) - they are not blocked" ?

I guess that step is to simulate where CentralAuth is not able to create the local block (e.g. the user already has a partial block against them).