Page MenuHomePhabricator

Enforce Partial Blocks from Database and Update desktop Block Notice
Closed, ResolvedPublic3 Story Points

Description

Tasks

  • See if block (from database) is partial or site wide and apply either or as appropriate
  • Update Block Notices (desktop)
  • Ensure that block notices work properly in VisualEditor

Acceptance Criteria

  • When a user attempts to edit an applicable page, they should see a new type of block warning message which include information on their block, modeled off of MediaWiki:Blockedtext
    • reason
    • expiration
    • blocking admin
  • Should appear:
    • For all supported editors on desktop web
    • API edits should also return an appropriate error message

Update for MediaWiki:Blockedtext-partial
<strong>Your username or IP address has been blocked from editing this page. You can still edit other pages on this wiki.</strong> You can view the full block details at [[Special:MyContributions|account contributions]].

The block was made by $1.
The reason given is <em>$2</em>.

* Start of block: $8
* Expiration of block: $6
* Intended blockee: $7
* Block ID: #$5

Details

Related Gerrit Patches:

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
dbarratt claimed this task.Jun 28 2018, 7:07 PM
dbarratt moved this task from Ready to In progress on the Anti-Harassment (AHT Sprint 24) board.
dbarratt added a comment.EditedJun 29 2018, 5:45 AM

@SPoore & @TBolliger

I just noticed this comment in the code:

If a user's name is suppressed, they cannot make edits anywhere

Right now, if the user has a block, and their username is suppressed, then they are prevented from editing on their own talk page (even if the allow setting is enabled).

Two questions:

  1. Should suppressed user names be able to edit a page, regardless of whether a block exists for that user?
  2. If a user has a partial block and their username is suppressed, what should happen? Should we ignore the partial block and impose a hidden sitewide block?

Change 443024 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Enforce Partial Blocks by determing the blocked page dynamiclly.

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

I just noticed this comment in the code:

If a user's name is suppressed, they cannot make edits anywhere

Right now, if the user has a block, and their username is suppressed, then they are prevented from editing on their own talk page (even if the allow setting is enabled).
Two questions:

  1. Should suppressed user names be able to edit a page, regardless of whether a block exists for that user?
  2. If a user has a partial block and their username is suppressed, what should happen? Should we ignore the partial block and impose a hidden sitewide block?

Let's not change how suppression works, let's be sure Suppress functions 100% the same after our project, regardless of if they have any Partial Blocks set against them.

Let's not change how suppression works, let's be sure Suppress functions 100% the same after our project, regardless of if they have any Partial Blocks set against them.

okie dokie.

To clarify, if a suppressed user has a partial block, attempting to edit will invoke a hidden (i.e. not logged) sitewide block if the user has a partial block (which is what happens with allow user talk).

Correct, although I would actually have guessed that they cannot even log in, since suppressing an account is akin to deleting it (while retaining the anonymized contributions and other footprints.)

If an admin blocks User:Bananas from User_talk:Bananas but the admin has the Prevent this user from editing their own talk page while blocked unchecked, what happens? which one wins?

@SPoore & @TBolliger
I just noticed this comment in the code:

If a user's name is suppressed, they cannot make edits anywhere

Right now, if the user has a block, and their username is suppressed, then they are prevented from editing on their own talk page (even if the allow setting is enabled).
Two questions:

  1. Should suppressed user names be able to edit a page, regardless of whether a block exists for that user?
  2. If a user has a partial block and their username is suppressed, what should happen? Should we ignore the partial block and impose a hidden sitewide block?

These accounts should not be able to edit their own talk page with an account whose user name is suppressed. These accounts are almost without exception troll attack accounts that revealed non-public information in the account user name. Or account name was gross attack on a person at a level that it was suppressed. So, these people should not be able to edit even their talk page.

If an admin blocks User:Bananas from User_talk:Bananas but the admin has the Prevent this user from editing their own talk page while blocked unchecked, what happens? which one wins?

I'm pretty sure we're going to make 'Edit their own talk page' inactive unless a Sitewide editing block is selected, it just doesn't make sense by itself.

To answer your immediate question, the user should *not* be able to edit their talk page in that configuration.

jrbs added a subscriber: jrbs.Jun 29 2018, 5:01 PM

If an admin blocks User:Bananas from User_talk:Bananas but the admin has the Prevent this user from editing their own talk page while blocked unchecked, what happens? which one wins?

I'm pretty sure we're going to make 'Edit their own talk page' inactive unless a Sitewide editing block is selected, it just doesn't make sense by itself.
To answer your immediate question, the user should *not* be able to edit their talk page in that configuration.

Is there some way to have the software realise what's going on and just tick that box in the blocking setup rather than invoke this kinda weird partial block? Seems like that'd be cleaner.

Is there some way to have the software realise what's going on and just tick that box in the blocking setup rather than invoke this kinda weird partial block? Seems like that'd be cleaner.

Yes. That will happen in the UI/API if the options are mutually exclusive. However, the potential does exist for that scenario to be in the database (though, it's very unlikely), so I'd prefer to code it in a way that handles it (just in case). :)

If an admin blocks User:Bananas from User_talk:Bananas but the admin has the Prevent this user from editing their own talk page while blocked unchecked, what happens? which one wins?

I'm pretty sure we're going to make 'Edit their own talk page' inactive unless a Sitewide editing block is selected, it just doesn't make sense by itself.
To answer your immediate question, the user should *not* be able to edit their talk page in that configuration.

To summarize:
The Partial Block and Prevent this user from editing their own talk page while blocked can be used together (at this stage at least) unless there is a conflict, in which case, the Partial Block settings win.

To summarize:
The Partial Block and Prevent this user from editing their own talk page while blocked can be used together (at this stage at least) unless there is a conflict, in which case, the Partial Block settings win.

👍

Vvjjkkii renamed this task from Enforce Partial Blocks from Database and Update Block Notices to u3aaaaaaaa.Jul 1 2018, 1:05 AM
Vvjjkkii removed dbarratt as the assignee of this task.
Vvjjkkii raised the priority of this task from Medium to High.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed subscribers: gerritbot, Aklapper.
Vachovec1 renamed this task from u3aaaaaaaa to Enforce Partial Blocks from Database and Update Block Notices.Jul 1 2018, 5:58 PM
Vachovec1 assigned this task to dbarratt.
Vachovec1 lowered the priority of this task from High to Medium.
Vachovec1 updated the task description. (Show Details)
Vachovec1 added subscribers: gerritbot, Aklapper.
dbarratt removed dbarratt as the assignee of this task.Aug 7 2018, 6:20 PM
dmaza claimed this task.Aug 13 2018, 5:09 PM
dmaza added a comment.Aug 27 2018, 9:46 PM

Assuming that the resulting auto-blocks from a partial block will include the same restrictions as the original block, do we need a different message for it like we are adding for partial blocks?

Currently this is what it says

Your IP address has been automatically blocked because it was used by another user, who was blocked by Admin. The reason given is:

    whatever reason 

    Start of block: 17:19, 22 August 2018
    Expiration of block: 17:19, 29 August 2018
    Intended blockee: TestUser

You may contact Admin or one of the other administrators to discuss the block.

Do we want to be more specific on partial autoblocks or is it fine to leave this alone?

dbarratt added a comment.EditedAug 27 2018, 9:55 PM

@dmaza Can this scenario happen?

  • User:Apples and User:Bananas are sitting at a coffee shop together.
  • User:Apples gets a partial block from editing Saturn
  • User:Bananas gets a partial block from editing Neptune
  • User:Apples logs out and edits, but they are autoblocked.
  • User:Bananas logs out and edits, but they too are autoblocked.

If that scenario can happen... what we do? We would merge the blocks? if so what would the parent id be? Or is this a problem that can only be solved by multiblocks (if it's a problem at all)?

dmaza added a comment.EditedAug 27 2018, 10:36 PM

I think it is a valid scenario for partial blocks. Merging the auto-blocks seems like a solution (from the top of my head). Basically the auto-block for User:Bananas will re-use the auto-block created by User:Apples for the coffee shop IP. Actually, considering the unique index constraint merging the auto-blocks is the only solution.

Regardless, my question lies on the default message we should display an auto-blocked user. Should it be more specific like https://phabricator.wikimedia.org/T197117#4305969 or are we OK with what we currently have for autoblocks [ here ] ?

If we merge the autoblocks... then they could have different expirations and the "Intended blockee" would be different...

@TBolliger Would it be ok to not allow autoblocks on partial blocks until we have multiblocks?

TBolliger added a comment.EditedAug 27 2018, 10:41 PM

Assuming that the resulting auto-blocks from a partial block will include the same restrictions as the original block, do we need a different message for it like we are adding for partial blocks?
Currently this is what it says

Your IP address has been automatically blocked because it was used by another user, who was blocked by Admin. The reason given is:
    whatever reason 
    Start of block: 17:19, 22 August 2018
    Expiration of block: 17:19, 29 August 2018
    Intended blockee: TestUser
You may contact Admin or one of the other administrators to discuss the block.

Do we want to be more specific on partial autoblocks or is it fine to leave this alone?

Lets use a new message — but the message should not list the pages, namespaces, or actions blocked, in the case that the page(s) blocked could identify someone using the same IP address/range. Let's go with:

Your IP address has been automatically blocked from editing this page because it was used by another user, who was blocked by Admin. You may be able to edit other pages on this wiki. The reason given is:

[...]

@dmaza oh I guess autoblocks are always 24 hours anyways... so merge away! :)

If we merge the autoblocks... then they could have different expirations and the "Intended blockee" would be different...
@TBolliger Would it be ok to not allow autoblocks on partial blocks until we have multiblocks?

I'm fairly confident there is already a system for handling overlapping multiblocks (e.g. a sockpuppet army is simultaneously blocked.) Can we not use this?

But, for sake for MVP — we can consider autoblocks to be out of scope for MVP. If it's simpler from a technical/sequencing point of view to solve this later, we can create a new Phab ticket to complete this later.

@TBolliger naw.. I think it's ok.. I forget that Autoblocks are short-lived anyways.

dbarratt set the point value for this task to 5.Aug 28 2018, 6:31 PM
dbarratt removed the point value for this task.
dbarratt added subscribers: Frakir, Liuxinyu970226.
TBolliger set the point value for this task to 3.
TBolliger moved this task from Ready to In progress on the Anti-Harassment (AHT Sprint 28) board.
dmaza added a comment.Aug 30 2018, 1:54 PM

In the User Page and User Talk Page we currently display a message if the user is blocked. Do we want to keep this message if a partial block exists or only for sitewide blocks?

This message is the same message we use for block logs in Special:Log so technically once T197108 get's worked on this message should be the same if we decide to keep it.

@dmaza if it's just displaying the log entry, then it should be updated when we do T197108 automatically (I think), so I would keep it there.

dmaza added a comment.Aug 30 2018, 1:58 PM

@dmaza if it's just displaying the log entry, then it should be updated when we do T197108 automatically (I think), so I would keep it there.

I agree. I figured I should mention it before making assumptions. I'll leave it as is if nobody objects

In the User Page and User Talk Page we currently display a message if the user is blocked. Do we want to keep this message if a partial block exists or only for sitewide blocks?
This message is the same message we use for block logs in Special:Log so technically once T197108 get's worked on this message should be the same if we decide to keep it.

Good find, I've completely missed this during initial product testing and planning. I'm sure there will be more places that we haven't found, please create new Phab tickets when we encounter them.

I've taken this to T203171: Do not display "this user is blocked" messages on user & user_talk pages for partial blocks since we'll want to think through how these messages should work for partial blocks. But David is correct for MVP — just show the latest block log entry, regardless of sitewide/partial.

-jkb- removed a subscriber: -jkb-.Aug 30 2018, 5:46 PM
dmaza updated the task description. (Show Details)Aug 30 2018, 7:14 PM
aezell added a subscriber: aezell.Aug 30 2018, 8:00 PM
This comment was removed by aezell.

Change 443024 abandoned by Dbarratt:
Enforce Partial Blocks by determing the blocked page dynamiclly.

Reason:
Replaced by 456666

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

Change 456666 had a related patch set uploaded (by Dbarratt; owner: Dmaza):
[mediawiki/core@master] Enforce partial blocks

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

TBolliger updated the task description. (Show Details)Sep 25 2018, 10:34 PM
TBolliger updated the task description. (Show Details)Sep 25 2018, 10:40 PM
TBolliger renamed this task from Enforce Partial Blocks from Database and Update Block Notices to Enforce Partial Blocks from Database and Update desktop Block Notice.Sep 25 2018, 10:45 PM
TBolliger updated the task description. (Show Details)

Change 456666 merged by jenkins-bot:
[mediawiki/core@master] Enforce partial blocks

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

dbarratt closed this task as Resolved.Oct 24 2018, 3:06 PM
dbarratt moved this task from Review to Done on the Anti-Harassment (AHT Sprint 31) board.

I tested this in the visual editor and it seems to work exactly as expected. Nice work!

I blocked User:Deskana (WMF) (myself) from editing User:Deskana (WMF)/sandbox2 on the beta cluster.

Steps:

  1. Go to User:Deskana/sandbox, which I should not be blocked from editing.
  2. Open the page in the visual editor.
  3. Make some changes.
  4. Save the changes.

Expected:

  • No warning saying I was blocked was shown when the page was edited, and the page saved successfully.

Actual:

  • Exactly the same as expected. :-)

Steps:

  1. Go to User:Deskana/sandbox2, which I should be blocked from editing.
  2. Open the page in the visual editor.
  3. Make some changes.
  4. Save the changes.

Expected:

  • When I open the editor I am shown an edit notice telling me I am blocked, and when I save I am unable to do so due to the block.

Actual:

  • Exactly the same as expected. :-)

@Deskana Thank you so much for testing!

Thank you Dan! We're excited to get this live on production for people to use.