Change 475952 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Do not ignore the 'Prevent this user from editing his own talk page while blocked' option on partial blocks.

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

@TBolliger This change basically means that specifying User_talk:Apples or checking Prevent this user from editing his own talk page while blocked are treated the same way, which makes sense to me and resolves the edge case.

In T210475#4776769, @dbarratt wrote:

This change basically means that specifying User_talk:Apples or checking Prevent this user from editing his own talk page while blocked are treated the same way, which makes sense to me and resolves the edge case.

Is it possible to automatically convert the former to the latter when the block form is saved?

The OP specifically calls for a user to be blocked from their UTP if the UTP block box is not checked, but they are partial-blocked from the User_talk namespace. However, a cursory reading of @dbarratt's patchset suggests the box will take precedence in this case. It seems counterintuitive to me that a User_talk namespace partial block should prevent a user from editing their own UTP even when the UTP box isn't checked; having the box override all other behavior also matches its current functionality IRT sitewide blocks. What is the actual preferred behavior here?

In T210475#4776808, @JJMC89 wrote:

In T210475#4776769, @dbarratt wrote:

This change basically means that specifying User_talk:Apples or checking Prevent this user from editing his own talk page while blocked are treated the same way, which makes sense to me and resolves the edge case.

Is it possible to automatically convert the former to the latter when the block form is saved?

No. Because you can block a range with the latter, but not with the former.

In T210475#4777135, @Dinoguy1000 wrote:

The OP specifically calls for a user to be blocked from their UTP if the UTP block box is not checked, but they are partial-blocked from the User_talk namespace.

I think this should be resolved in T204988. We can't resolve that problem in this ticket, because namespace blocking doesn't exist.

@Dinoguy1000 I've updated this for namespaces here:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/470656

Basically, a sitewide block, and a namespace block on User_talk will be treated the same way. Does that make sense?

Change 475952 merged by jenkins-bot:
[mediawiki/core@master] Do not ignore the 'Prevent this user from editing his own talk page while blocked' option on partial blocks.

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

You removed this TODO, but didn't really address the question. If a namespace block covers NS_USER_TALK, IMO that probably should not override $block->prevents( 'editownusertalk' ) === false.

This patch does exactly the opposite: if a block covers anything *except* the user's talk page, you're making $block->prevents( 'editownusertalk' ) === true also prevent talk page access. Which to me also seems like the wrong thing to do.

Perhaps I should explain my reasoning a bit more.

A sitewide block blocks the user from everything. The checkbox labeled "Prevent this user from editing their own talk page while blocked" really serves to exempt the user's talk page from that when the checkbox is unchecked, to allow the user an avenue of appeal.

For partial blocks from the whole user talk namespace, I'd expect it to work the same way: To allow appeal the user can still edit their own talk page unless the blocking admin specifically took that away by checking the box. But you've implemented the opposite here.

If the partial block doesn't cover the user talk namespace (e.g. a block from a single article), IMO it doesn't make sense to even have the "Prevent this user from editing their own talk page while blocked" checkbox shown. Even if it is shown, I can't think of any situation where I as a blocking admin would want to check the box for such a block and have it take effect.

If we had category blocks, again I'd expect the user to be able to edit their own talk page for appeals even if their talk page happens to have a blocked category on it.

The only case I can think of where I as a blocking admin actually *would* want the block to ignore "Prevent this user from editing their own talk page while blocked" being unchecked is if it's a specific-page block for the user's talk page. Because in that case it's clear I really am trying to stop the user from editing their talk page.

OTOH, I can't think of any case where I'd use a partial block for removing a user's own talk page access, since if they're misbehaving enough to lose access to their own talk page there's probably no reason not to block them sitewide. So maybe the thing to do would be to hide "Prevent this user from editing their own talk page while blocked" checkbox entirely (forcing it to false) when creating a partial block?

Does that make sense to you?

@Anomie I'm moving your comment from gerrit here so we can involve @TBolliger and @SPoore in the conversation.

We felt that if an admin specifically blocks a UT Page or the UT NS it means that they are intentionally doing so and there is no need for the "Prevent.." checkbox.

You do have a valid point, if a user is partially blocked from UT NS then there is no avenue of appeal but I think that would be a corner case since blocking UT NS kinda falls in the realm of a Sitewide block 'cause it means they are being pretty disruptive. But, If I were an admin and I was blocking UT NS or the Blockee UTP I would expect it to happen even if the "Prevent..." checkbox is not checked. Keep in mind that an admin can "uncheck" this flag and remove any avenue of appeal at their discretion for sitewide blocks, so it is really up to the admin to decide.

I think part of the confusion comes from the name of the checkbox that is inverted. It is not very intuitive to uncheck "Prevent.." when you are blocking via a Page or NS whereas checking "Allow user to edit their own talk page" makes perfect sense in basically all scenarios ( I understand this is the behavior you are suggesting without changing the name )

IMO if we want to respect "Prevent.." checkbox on NS block or UTP blocks we should rename the flag to "Allow...". Otherwise, the current behavior is what IMO is expected in the aforementioned scenarios.

It seems we disagree over what we think admins might expect. While some of us in our volunteer capacities are admins on some of the wikis, it doesn't look like any of us have been heavily involved in actually blocking users (at least not recently).

So perhaps the thing to do here would be to solicit input from admins who actually do a lot of blocking on the wikis, to ask what they would expect? Perhaps ask them the following questions:

1. If you use the per-page blocking feature to block a user from the "Cold fusion" article and checked a checkbox labeled "Prevent this user from editing their own talk page while blocked", what would you expect to happen?
   1. The user would not be able to edit their own user talk page, because that's what the checkbox says, even though they can edit any other page on the wiki (except "Cold fusion").
   2. The user would still be able to edit their own user talk page, because the block doesn't cover their user talk page in the first place.
   3. That checkbox shouldn't even appear when using the per-page blocking feature.
2. If you use the per-page blocking feature to block a user from their own user talk page and did not check a checkbox labeled "Prevent this user from editing their own talk page while blocked", what would you expect to happen?
   1. The user would not be able to edit their own user talk page, despite the "Prevent..." checkbox not being checked.
   2. The user would still be able to edit their own user talk page, because blocks never prevent access to the user's own talk page unless the "Prevent..." checkbox is checked.
   3. That checkbox shouldn't even appear when using the per-page blocking feature. The access should be blocked because the block says so.
   4. That checkbox shouldn't even appear when using the per-page blocking feature. The access should not be blocked because only sitewide blocks should be able to prevent access to the user's own talk page. A per-page block of the user's own talk page shouldn't be allowed in the first place.
3. If you use the per-namespace blocking feature to block a user from the Template namespace and checked a checkbox labeled "Prevent this user from editing their own talk page while blocked", what would you expect to happen?
   1. The user would not be able to edit their own user talk page, because that's what the checkbox says, even though they can edit any other page on the wiki outside of the Template namespace.
   2. The user would still be able to edit their own user talk page, because the block doesn't cover their user talk page in the first place.
   3. That checkbox shouldn't even appear when using the per-namespace blocking feature.
4. If you use the per-namespace blocking feature to block a user from the User talk namespace and did not check a checkbox labeled "Prevent this user from editing their own talk page while blocked", what would you expect to happen?
   1. The user would not be able to edit their own user talk page, despite the "Prevent..." checkbox not being checked.
   2. The user would still be able to edit their own user talk page, because blocks never prevent access to the user's own talk page unless the "Prevent..." checkbox is checked.
   3. That checkbox shouldn't even appear when using the per-namespace blocking feature. The access should be blocked because the block says so.
   4. That checkbox shouldn't even appear when using the per-namespace blocking feature. The access should not be blocked because only sitewide blocks should be able to prevent access to the user's own talk page.

IMO if we want to respect "Prevent.." checkbox on NS block or UTP blocks we should rename the flag to "Allow...".

I would have no objection to that UI change in Special:Block.[1] I do think that "if" should indeed be the case, rather than the current situation after the merged patch.

We could also survey admins about that option.

[1]: I note that in the API the corresponding option for action=block is already named "allowusertalk" and is output as such by list=blocks. Internally it seems to generally be treated that way as well. It appears that it was that way in the web UI too until rSVN83786, where it was inverted "so that every checkbox makes the block more severe".

BTW, the current code answers 1A, 2A, 3A, 4A. The code before the patch answered 1B, 2A, 3B, 4A. I'd answer 1C, 2D, 3C, 4D, or if "shouldn't appear" isn't possible then 1B, 2B, 3B, 4B.

Honestly, "Prevent ..." should be the only way to prevent users from editing their own talk page. If page blocks will be able to disable talk page access, then it should function as if "Prevent ..." is checked.

If "Prevent ..." is checked (or the user is partially blocked from their own talk page (page, not namespace)), I would expect them to not be able to edit their talk page. Otherwise, they should be able to.

Blocks should not ignore what is explicitly specified (check or not checked) by the blocker. If "Prevent ..." is not going to function in a certain situation, it should be disabled on the web UI and issue a warning in the API.

Speaking as a Wikipedia administrator (and not as a staff member):

• If I am blocking someone from a certain page and nothing else, regardless of the namespace, I would not want to prevent this person from editing their own talk page. I cannot think of a single reason why this would make sense. Topic bans, which admittedly are social, never prevent the person from using their own talkpage (unless they were using it to circumvent the topic ban - like if someone were topic-banned from "bananas" broadly construed and used their talk page to rant about bananas).
• If I am blocking someone from their own user talk page only, it makes no sense to show the checkbox IMO. Honestly, a better solution might be to detect if the blocking admin is trying to do this and show some kind of warning (or auto-check that checkbox if it remains on the page).
• However, if I'm blocking someone from the whole user talk namespace, it still makes sense to have this box there, since whatever they're doing that requires them to be blocked from the whole namespace may also be happening on their talk page (thus you'd want to block that off too).

So basically I can see validity in keeping and removing the checkbox. I think ultimately if we have to make a call, it's much less likely that someone would want to apply user talk page exclusions for partial blocks, so I'd just hide it when setting partial blocks.

I agree that we need to re-think changes introduced with the patch.

My thinking is:

-Partially blocking from any named pages (outside of a talk namespace block) shouldn't introduce the option of a user talk page being blocked. This is introducing extra restrictions beyond a page block.
-Check box shouldn't appear for pb except for user talk page or talk namespace blocks.
-Checkbox should be pre-filled for user talk page blocks.

-I have mixed feeling about talk namespace blocks that includes their user talk page. I lean toward not blocking it UNLESS the page is added as part of the actual partial block. And then pre-fill the checkbox.
-I would make them list it in the block itself not with a simple check or to assume a talk namespace block would include their talk page. This would take away errors that would be difficult to resolve if talk page access is gone. This would still allow for the flexibility to do a rare user talk page or namespace block that includes their talk page.
-That said, it is a corner case that we could eliminate by allows allowing them to edit their own talk page with all pb. There would be no big loss by eliminating it since it is not available now.

@TBolliger I see why you prefer option 1. It follows traditional on wiki values and is the safe approach. The only reason that I might consider including their talk page is that some users get stuck in a rut and spend all of their time ranting on talk pages, even their own. Block all talk page access might bring them back to productive editing again. I wouldn't be opposed to a wiki experimenting with this approach. to see if it helps some users.

In T210475#4790231, @TBolliger wrote:

Proposal 1

• The "Prevent [...] own talk page" checkbox should only be active if the block is configured to sitewide.
• The input for Page block should reject the block target's user_talk page
• The input for Namespace block should reject the User_talk: namespace

Agreed with Sydney, this follows community norms and makes sense. I likewise agree that a User_talk: namespace blocks seems almost impossibly unlikely and arguably not even really a valid usecase.

Proposal 3

• The "Prevent [...] own talk page" checkbox should only be active if the block is configured to sitewide OR if the admin has configured the Partial Block to include the User_talk: namespace
• The Page and Namespace inputs should not change (i.e. allow for the block target's talk page and/or the entire User_talk: namespace)

This is my second choice, if we decide to allow User_talk: namespace blocks for some reason.

Post-script notes:

• If we want to flip "Prevent this user from editing their own talk page while blocked" to "Allow this user to edit their own talk page while blocked" we should do so in another ticket, taking into account that many users have long-ingrained habits of using Special:Block.

Yeah, while I agree that "prevent..." is strange wording, at this point it's very much expected wording and changing it would require strong community consensus (or at the very least a ton of research).

• The "Prevent [...] own talk page" checkbox should only be active if the block is configured to sitewide OR if the admin has configured ?the Partial Block to include the User_talk: namespace
• The Page and Namespace inputs should not change (i.e. allow for the block target's talk page and/or the entire User_talk: namespace)

Based on the comments so far, @TBolliger 's proposal #3 is what we all kinda agree on.
One thing to point out with #3 is that if $wgBlockAllowsUTEdit is disabled for the wiki, any user with a partial block will be allowed to edit their UT page unless User_talk: namespace or their User Talk Page is part of the restrictions

With that said, I'm gonna start working on this now.

Thank you all for your feedback. Any more comments are very welcome.

👍

Good deal. I've updated the acceptance criteria to reflect this.

I've numbered the bullets for easier discussion:

1. The "Prevent [...] own talk page" checkbox should only be active if:
   1. the block is configured to sitewide OR
   2. the admin has configured the Partial Block to include the User_talk: namespace
2. The "Prevent [...] own talk page" checkbox should be inactive for all other block configuration.
   1. On submission (via UI or API) this option should be ignored — and the user should be able to edit their own talk page
3. If a wiki has wgBlockAllowsUTEdit set to false, the (e.g. T11073) the user should be allowed to edit their own talk page while partially blocked — unless the partial block is specifically configured to prevent them from the entire user talk namespace or their UTP.
4. The Page and Namespace inputs should continue to allow for the block target's talk page and/or the entire User_talk: namespace)

Note: If an admin puts the target's talk page into the Page field, then per #1 and #2 the "Prevent ..." checkbox will not be active and per #2.A the user will be able to edit their own talk page. That seems likely to be unexpected.

We could fix that by changing #1 to activate the checkbox if the Page field includes the target's talk page, or #2.A to say that the Page input containing the target's talk page should instead act like the checkbox was checked, or change #4 to say that the Page input is not allowed to contain the target's talk page. Personally I'd go for the last option, but I won't complain further if you pick one of the other two.

Thank you @Anomie for helping us be so thorough.

I think we'll go with your middle proposal — [change] #2.A to say that the Page input containing the target's talk page should instead act like the checkbox was checked — for the most straightforward DWIM behavior. I'll update the acceptance criteria. T

Change 477447 had a related patch set uploaded (by Dmaza; owner: Dmaza):
[mediawiki/core@master] Add new rules when user is blocked for UTP

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

In T210475#4795055, @TBolliger wrote:

I think we'll go with your middle proposal — [change] #2.A to say that the Page input containing the target's talk page should instead act like the checkbox was checked

How should this work in the case where there's a partial block for some IP range, involving specific user talk pages?

1. Act like "Prevent [...] own talk page" is checked: nobody in that IP range can edit their own user talk page, whether or not their talk page was specified in the block
2. Act like "Prevent [...] own talk page" is unchecked: everyone in that IP range can edit their own user talk page, even if their talk page was specified in the block
3. Ignore "Prevent [...] own talk page": nobody in that IP range can edit any of the user talk pages that were specified in the block, whether their own or someone else's - in other words, some users at that IP can edit their own user talk page; some cannot
4. Don't allow partial blocks for an IP range to specify particular user talk pages

Great question, Thalia. Is there a significant difference in the complexity to implement any of these? If there is a "clean" way to program this we should go that route. This is very unlikely corner case that we shouldn't fret too much over.

All other things the same, #3 sounds preferable, followed by #1.

Unless @dmaza disagrees, I don't think any of these options should be particularly complex.

#1 and #2 are the most straightforward to implement, but probably make the least sense to a user.

I agree #3 makes the most sense. Annoyingly it's also the least "clean" because there is a flag on every block to say whether the block prevents the target of the block from editing their own talk page - corresponding to the "Prevent [...] own talk page" checkbox. The flag has to be true or false, but that would be misleading in this case. If we go with #3, we will always have to remember to ignore the flag (for this type of block) when checking if a user is blocked from editing their own talk page. It might still be the best option despite this awkwardness.

I feel unqualified to judge whether #4 is great or terrible, but it would at least mean that we wouldn't have blocks with the misleading flag.

I don't like #4 because it adds logic to the Pages input field to prohibit specific, contextual inputs. I'd prefer to keep the input requirements universal.

If #3 proves too messy we can go with #1, because the log entry will still display cannot edit own talk page, correct? (example)

If there is a partial block for an ip range, the same rules will apply. It will all work the same as what's described in the acceptance criteria (Unless I'm missing something) . The Target of the block makes no difference for this. The moving parts are the block type (sitewide|partial), the "Prevent ..." checkbox, and the restrictions (for now only pages).

• If the block is partial and there is a page restriction for the IP trying to edit, it will work as if "Prevent ..." was checked. Otherwise it will be ignored.
• If the block is partial and there is a namespace restriction on the User_talk, the value of "Prevent ..." will be honored
• When creating the block, the checkbox will be disabled unless a restriction for User_talk: namespace is in place

In T210475#4799401, @dmaza wrote:

If there is a partial block for an ip range, the same rules will apply. It will all work the same as what's described in the acceptance criteria (Unless I'm missing something) . The Target of the block makes no difference for this. The moving parts are the block type (sitewide|partial), the "Prevent ..." checkbox, and the restrictions (for now only pages).

• If the block is partial and there is a page restriction for the IP trying to edit, it will work as if "Prevent ..." was checked. Otherwise it will be ignored.
• If the block is partial and there is a namespace restriction on the User_talk, the value of "Prevent ..." will be honored
• When creating the block, the checkbox will be disabled unless a restriction for User_talk: namespace is in place

Perfect. 👍

Change 477447 merged by jenkins-bot:
[mediawiki/core@master] Add new rules when user is blocked for UTP

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