Fri, Apr 19
I did notice that blocks which don't block editing (i.e. only block account creation or emailing) are counted as partial.
Thu, Apr 18
Tue, Apr 16
I think it sends a misleading message that that option will be applied, e.g. that autoblocks would be applied for this block (and you can't prevent that from happening):
Here's a suggestion for multiple iterations of the BlockManager, broken down in to manageable chunks that can fit around our Block refactoring work (T206163):
- Factor out the innards of User::getBlockedStatus, along with the helper methods (this task).
- Move over methods from Block that belong in the BlockManager - filed as T221066.
- Remove the block-related methods from User - filed as T221067. User::getBlockedStatus will need refactoring at that point. User::trackBlockWithCookie and User::getGlobalBlock interact with these methods, so this is the time to move those.
Mon, Apr 15
Copying from gerrit, a question about the acceptance criterion:
Wed, Apr 10
Thu, Apr 4
@MarcoAurelio We have documented the partial blocks params wpEditingRestriction, wpPageRestrictions and wpNamespaceRestrictions at https://www.mediawiki.org/wiki/Manual:Block_and_unblock
NB this problem is specific to wpCreateAccount - the fix makes sure we don't override the status of the "Create account" checkbox if the wpCreateAccount parameter is present.
Wed, Apr 3
I've had a look into these issues:
What do we see the as eventual scope for the BlockManager?
AHT are discussing implementing a BlockManager: https://phabricator.wikimedia.org/T219441
Tue, Apr 2
For testing (and reviewing), here's how everything behaves before the fix:
Mon, Apr 1
We're at the tail-end of the project here and won't be looking for feedback beyond a month or two. Hence putting it in core doesn't make sense.
Sun, Mar 31
After more discussion, it seems there are concerns with adding any sort of feedback link in the core software. It's definitely worth resolving that question at some point, but since this task is blocking deployment to more wikis, and since we're (probably) more interested in WMF feedback in this case, it might be better to keep to the less controversial path.
Fri, Mar 29
After some discussion, it seems that we need to distinguish between WMF-specific feedback and general mediawiki-related feedback.
@Mooeypoo Do you expect this to be fixed now? It appears to behave according to the acceptance criteria as far as I can tell.
Thu, Mar 28
Undeleting is complicated by the fact that, once a page is deleted, the block no longer has a restriction against it, because the page ID is no longer in the page table. That means that a user blocked from Foo could undelete the page Foo if it is deleted.
The patch links to https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback, but it looks like this hasn't been created yet?
Wed, Mar 27
@dom_walden It sounds like nobody else has been able to reproduce this, so would be great to know if this fix works for you once it gets to testwiki.
Tue, Mar 26
Mon, Mar 25
Mar 22 2019
Mar 21 2019
Mar 20 2019
Thanks for pointing that out @dom_walden - it needed an additional patch in core.
Mar 19 2019
Mar 18 2019
A community representative has been in touch with @SPoore to indicate the community's approval for partial blocks to be enabled on Persian Wikipedia.
Mar 14 2019
There's a similar failure here: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/UploadWizard/+/494934/
Mar 12 2019
The proposal is to change User::getBlockedStatus to return a merged block combining the features of all blocks that apply to the user. This method is called from many places, and in the following ways:
Mar 6 2019
Mar 5 2019
@matmarex Is there some reason for these differences in the radio options?
Mar 4 2019
@Volker_E Thanks for explaining about the precedence of <a> and <label>.
On the patch, @dbarratt points out that clicking on the help text selects the associated option. This is a problem because we have a "Learn more" link in the text for the "partial" option, and it doesn't seem user friendly that clicking on that link selects the option.
Feb 28 2019
Feb 27 2019
@TBolliger The patch addresses all pages in your list except for AbuseLog and UploadWizard, since they extend SpecialPage, instead of FormSpecialPage. It sounds like AbuseLog is already working. It looks like UploadWizard should be fixed in SpecialUploadWizard::isUserUploadAllowed.
Feb 26 2019
Feb 25 2019
Feb 22 2019
Our collective bad - it should've been in the acceptance criteria.
@TBolliger They're not actually opposite, though I can see how it sounds that way...
Here's what we discussed in estimation:
Feb 21 2019
The approach of making the ipb_allow_usertalk flag match the behaviour was abandoned (https://gerrit.wikimedia.org/r/488533) in favour of decoupling the block flags/logs/form on the one hand from the block's behaviour on the other hand (https://gerrit.wikimedia.org/r/489662).