@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

In T197117#4323873, @dbarratt wrote:

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.

In T197117#4325195, @TBolliger wrote:

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?

In T197117#4323873, @dbarratt wrote:

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

In T197117#4325603, @dbarratt wrote:

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.

In T197117#4325724, @TBolliger wrote:

In T197117#4325603, @dbarratt wrote:

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.

In T197117#4325819, @jrbs wrote:

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

In T197117#4325724, @TBolliger wrote:

In T197117#4325603, @dbarratt wrote:

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.

In T197117#4325866, @dbarratt wrote:

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.

👍

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?

@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)?

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?

In T197117#4536468, @dmaza wrote:

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! :)

In T197117#4536614, @dbarratt wrote:

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.

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.

In T197117#4545630, @dbarratt wrote:

@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 T197117#4545607, @dmaza wrote:

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.

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

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

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

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.