I did notice that blocks which don't block editing (i.e. only block account creation or emailing) are counted as partial.

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):

1. Factor out the innards of User::getBlockedStatus, along with the helper methods (this task).
2. Move over methods from Block that belong in the BlockManager - filed as T221066.
3. 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.

Copying from gerrit, a question about the acceptance criterion:

@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.

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

For testing (and reviewing), here's how everything behaves before the fix:

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.

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.

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.

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.

Thanks @SPoore!

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?

@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.

@Niharika @dom_walden - The URL bug has been filed here: T218554

Thanks for pointing that out @dom_walden - it needed an additional patch in core.

A community representative has been in touch with @SPoore to indicate the community's approval for partial blocks to be enabled on Persian Wikipedia.

There's a similar failure here: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/UploadWizard/+/494934/

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:

@matmarex Is there some reason for these differences in the radio options?

@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.

Thanks @dom_walden - I'll leave it to @TBolliger and/or any extension maintainers to request more testing

@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.

@dom_walden Thanks for finding that so quickly - it should be fixed by this: https://gerrit.wikimedia.org/r/492747

Our collective bad - it should've been in the acceptance criteria.

@dom_walden Ah, nasty - looks like it's is a new bug introduced by: T208510, merged not long before this. The JavaScript unchecks the checkbox because it's a partial block (with JavaScript disabled, it is checked). Filed as T216845.

@TBolliger They're not actually opposite, though I can see how it sounds that way...

Here's what we discussed in estimation:

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).