In T213101#4990298, @dbarratt wrote:

@TBolliger Can we change the message text to this?

• Sitewide: Every page on the wiki and all other contribution actions.
• Partial: Specific pages or namespaces. Learn more.

I think the form makes it clear that you can configure it, it makes it clear what option is which, so you don't need to restate it, it also makes it clear that it applies to the target and that this is specific to editing. That means the only thing we need to do is explain what "Sitewide" and "Partial" mean.

In T217283#4989377, @alanajjar wrote:

Community Consensus open on 27 Feb and I'll put the result between 6-10 March 2019

Sydney and Joe — please review the pages when you get a chance

In T209097#4988294, @dbarratt wrote:

In T209097#4988170, @TBolliger wrote:

Good deal — sounds like we need a new Phab task to address SpecialUploadWizard::isUserUploadAllowed ?

That would be fantastic.

In T209097#4987919, @Tchanders wrote:

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

In T214508#4988086, @dom_walden wrote:

I programmatically generated as many combinations of blocks that I could think of via the API, for users and IPs.

I imported the data in Special:Log?type=block and Special:BlockList into a spreadsheet and checked that the "cannot edit own talk page" was (not) stated correctly for each block (depending on the value of ipb_allow_usertalk).

EDIT: And for a sample of Special:Block/$username I checked that the "Editing own talk page" was (un)checked as appropriate.

The bug from T214508#4981423 no longer occurs. Just in case, I am systematically attempting to edit (via the API) the user_talk of each blocked username from each blocked IP. It might take a while. I will report in T211578 (probably). EDIT: So far I have not seen anything that looks like a problem, nor any exceptions in the server logs.

Otherwise, I don't have anymore work to do for this bug specifically.

In T191549#4983573, @Prtksxna wrote:

Make the 'Items' dropdown 50% width and add a dropdown to its right (on LTR lang wikis)

Lets add the Type dropdown to its left though, its a more important filter and should surface earlier.

In T214628#4979612, @chelsyx wrote:

The large number of IP block looks very suspicious to me. It's not even IP range block if my interpretation is correct...

There are a couple of options in the block that the admin can configure for IP blocks.

• Account creation — Default checked. Prohibits people at that IP address from creating new accounts
• Prevent logged-in users from editing from this IP address — Default unchecked. Prohibits existing user accounts from editing from that IP range.

Good catch!

In T208355#4976570, @Tchanders wrote:

When the form is submitted, only the accepted tags are submitted, not the text left in the input - so the invalid contents aren't actually being submitted at this point. On the non JS version, however, all the text entered is submitted - hence the error message. I suppose in the first example, we might hope that the invalid styling would indicate that the page Special:Block was not accepted, so will not be submitted, even though the form itself doesn't complain... Do we think this UI needs improving?

There is only one tool (to my knowledge) that prohibits a user from logging-in to an existing accounts: the WMF and steward tool called "account lock" which is used very infrequently that scrambles the password and disallows password resets.

In T208355#4976060, @dom_walden wrote:

I can submit the block with a page like "Special:BlockList" and this creates the block, but "Special:BlockList" is not in the BlockList nor in the database (ipblocks_restrictions).

If there are valid pages in the "Pages" input field before the "Special:BlockList", these are added to the block as per usual. Anything that comes after "Special:BlockList", however, are considered invalid and not included in the block.

Good find! Harmless, but could lead to long-term confusion and complication.

In T212391#4975942, @Tchanders wrote:

Here's what we discussed in estimation:

Where the checkbox is never visible to a particular admin because they don't have the correct permissions, it should remain never visible to them.

Where a checkbox can be visible to an admin if they enter certain parameters, it should go between enabled/disabled instead of shown and hidden. (It should probably also be appropriately checked if disabled, so that the admin can understand what the block will do.)

https://www.mediawiki.org/wiki/Help:Blocking_users and https://www.mediawiki.org/wiki/Manual:Block_and_unblock#Blocking have been updated but need to be submitted for translation.

make sure nothing jumps

@SPoore — should the link point to https://meta.wikimedia.org/wiki/Community_health_initiative/Partial_blocks/Feedback or to https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback

Timebox to 2-3 hours

Also doesn't drop a cookie on mobile web:

I tested this again today. The description is still correct. If an IP is hardblocked and if a user attempts to edit via VisualEditor (e.g. the wiki is configured to allow for IP editors to use VisualEditor or the user's preference is set to VE) the block cookie is not set:

I'm happy with the design in the attached screenshot, as long as Prateek and the rest of AHT can get the build to pass.

As discussed in today's standup, let's enable this on Wednesday 2/20.

This may have been fixed in T117781#4595049

In T216075#4962453, @Tchanders wrote:

@Mooeypoo I think it makes sense to change to item.getLabel() in MenuTagMultiselectWidget because the label is what is exposed in the menu, so most users of this widget are probably more used to interacting with labels than data.

I've created T216533: Mobile web "you are blocked" notice should truncate long block reasons to document the long block reason. Not worth addressing for now.

In T216065#4962455, @MarcoAurelio wrote:

I am not sure we need partial blocks on Meta to be honest. Will projects be allowed to opt-out from partial blocks? Thanks.

Ugh, templates for block reasons. Such a pain, and a tax that someone someday will have to pay.

No longer needed.

Let's SWAT for Meta Wiki and MediaWiki.org on Tuesday Feb. 19.

Works as expected! Here are the error messages: