Fri, Mar 22
@dom_walden good catch. This patch fixes the advertise bug as well. There is a separate issue and that is that the user doesn't get any feedback when they are blocked and try to advertise but that's unrelated to PB.
Thu, Mar 21
@dmaza Did the team ever discuss this? It makes sense to me to update these pages too. I can go ahead and add them to the ticket description if there are no concerns.
Wed, Mar 20
Tue, Mar 19
@Niharika the patch will not remove the data but I'm not sure for how long we keep those metrics around. I can't find anything on wikitech.
Mon, Mar 18
Fri, Mar 15
Wed, Mar 13
Tue, Mar 12
Fri, Mar 8
Feb 21 2019
Feb 14 2019
Feb 12 2019
That means if there is a failed skipLogin check and a failed normal check, both error messages will show, even though the skipLogin one would not show on its own
This is why I said that the same approach as forceChange can't be used. It was my understanding that the warning shouldn't be shown when other policies fail. If this is an accepted behavior then I agree with you that it should work just fine like you described in your last comment.
Feb 6 2019
Feb 4 2019
Working on it right now. Will push fix in the next few mins
Feb 1 2019
Jan 25 2019
Jan 21 2019
Jan 18 2019
Jan 16 2019
Jan 15 2019
Dec 21 2018
Dec 20 2018
@JJMC89 Unless I'm missing something, you can't create an account if you are already signed in.
Dec 17 2018
Dec 14 2018
Dec 13 2018
Dec 11 2018
Dec 10 2018
Dec 6 2018
Right. And UserIsBlockedFrom signature will need to change for this. LiquidThreads can be fix accordingly.
Dec 5 2018
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).
Dec 4 2018
Dec 3 2018
Is it safe to assume that we only need to check on those 4 extensions ( CirrusSearch, WikibaseQualityConstraints, Wikibase, EducationProgram ) ?
I still think that @Addshore's patch should be merged regardless.
@Addshore @Legoktm are we ready to move forward with the patch on wikibase? What do we need to get https://gerrit.wikimedia.org/r/c/mediawiki/core/+/471993 (or a version of it) back on wmf.6?
Dec 1 2018
- 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)
Nov 30 2018
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?