Page MenuHomePhabricator

Users can still edit their talk pages when partially blocked from them
Closed, ResolvedPublic

Description

Partially-blocking a user from their own talk page does not prevent them from editing it. I'm thinking this is colliding with the existing setting for enabling/disabling this already baked into the block functionality.


Example

Action: User:Craig is partially blocked from the page User talk:Craig.
Expected result: Craig cannot edit User talk:Craig.
Actual result: Craig can in fact edit User talk:Craig.

Event Timeline

jrbs created this task.Nov 1 2018, 9:33 PM
Restricted Application added subscribers: MGChecker, Aklapper. · View Herald TranscriptNov 1 2018, 9:33 PM
TBolliger closed this task as Declined.Nov 1 2018, 9:54 PM
TBolliger triaged this task as Lowest priority.

Good find! You're kicking the really hard-to-find tires. :)

The AHT team briefly talked about this and decided that this falls into the domains of "garbage in, garbage out" and extremely uncommon edge cases.

The good news — if a user is blocked from the entire User_talk: namespace (in which case, in my opinion, probably deserves a sitewide block) the "allow user to edit their own talk page" will still work.

jrbs added a comment.Nov 1 2018, 10:22 PM

Thanks for the explanation.

I do think this may be worth keeping in mind when considering how this functionality will coexist with the existing, baked-in functionality. I know that's a big sticking point for other reasons.

dbarratt reopened this task as Open.Nov 2 2018, 1:07 AM
dbarratt added a subscriber: dbarratt.

No... we talked about this and decided that the page block should take precedence and the Namespace block should not. This does not appear to be implemented correctly. We should at least have a test for this scenario to ensure that it is what the user would mostly expect to happen (do what I mean).

dmaza added a subscriber: dmaza.EditedNov 2 2018, 3:57 AM

No... we talked about this and decided that the page block should take precedence and the Namespace block should not. This does not appear to be implemented correctly. We should at least have a test for this scenario to ensure that it is what the user would mostly expect to happen (do what I mean).

We do have in fact multiple tests[1] regarding this edge cases. I can't reproduce this locally.

@jrbs can you try this again? after you create the block, do you mind editing it and making sure that the "User Talk" page was properly saved as part of the block?

[1] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/master/tests/phpunit/includes/BlockTest.php#667

We do have in fact multiple tests[1] regarding this edge cases. I can't reproduce this locally.
[1] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/master/tests/phpunit/includes/BlockTest.php#667

Unless I'm missing something, that test does not cover the use case which is:
allowUsertalk => true but a partial block with a restriction of User_talk:Craig

jrbs added a comment.Nov 14 2018, 12:05 AM

@jrbs can you try this again? after you create the block, do you mind editing it and making sure that the "User Talk" page was properly saved as part of the block?

I tested this with Practical peanut@testwiki, and indeed it seems to be working as normal now. I performed this block (with and without the "allow user to edit own talk page" checkbox checked):


... both times it resulted in the block message as expected with partial blocks:

I think we can resolve this.

TBolliger closed this task as Resolved.Nov 14 2018, 12:10 AM
TBolliger claimed this task.

Thanks for testing again!