Fri, Jan 18
Wed, Jan 16
Tue, Jan 15
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?
So here is a proposal for consistency. What if we only show the message if the user is not allow to create the user page or to create the user talk page regardless of the block type?
The only difference from what we have discussed so far is that if the user is sitewide blocked but can create their own talk page, the message will not show on their talk page.
Nov 29 2018
Nov 27 2018
Nov 26 2018
Nov 22 2018
Should the message be displayed if the block is partial and it applies to the page? It could be an explicit Page/Namespace block or the block might prevent the user from editing their own user talk
Nov 20 2018
Nov 19 2018
And maybe these pages too?
- Create https://www.mediawiki.org/wiki/Manual:$wgEnablePartialBlocks and link it to relevant pages like https://www.mediawiki.org/wiki/Manual:Configuration_settings_(alphabetical)
- https://www.mediawiki.org/wiki/Manual:Ipblocks_restrictions_table should be added to https://www.mediawiki.org/wiki/Manual:Database_layout
@Marostegui what about the new column ipblocks.ipb_sitewide? what do we need to do to add that to the current view for ipblocks?