Someone else will need to test this, still broken on beta

@dom_walden — Thanks for testing so thoroughly! Based on your comment, it sounds like there are no regressions or oddities found and we're safe to deploy!

The public password policy states that passwords must not be from the top 100k passwords, and Chris already informed a lot of large channels about this change: T205931

Blocked by: T218322: Uncaught Error: Circular dependency! mw-input-wpExpiry on beta environment (March 14, 2019)

UBN as this is on the current train.

There are only four pages on Wikibooks beta, so I won't test that. The Expiration section is missing from all beta wikis (these four + wikipedia) so I can't set a block until that's been resolved:

@Wargo suggests changing the UI, too: https://meta.wikimedia.org/wiki/Talk:Community_health_initiative/Partial_blocks#My_proposals

Thank you @Aklapper — I certain did not mean to improvise. 😆

Dupe of T218265: Mute: Add links to disable email and mute specific user to emails sent via Special:EmailUser

In T218270#5022807, @dbarratt wrote:

Before doing this, I think we should merge the list, that way we can just say "Mute this user" and "Unmute this user" which is similar to other systems.

I'll test

In T216185#5019841, @dbarratt wrote:

From my user experience perspective, the interaction is wrong, so the reason why is irrelevant since the implementation was wrong in the first place.

My assumption would be, that if you are being bothered by a user on one medium, you are going to go add them to that mute list. There's no need to go add them to the other list unless they start bothering you there as well. Also, if you have emails disabled, there's no need to add anyone at all to that list.

In T209097#5021714, @dom_walden wrote:

@TBolliger Special:MassMessage does not seem to respect blocks (partial or sitewide). For example, if you are blocked from someone's user_talk page you can still send a message to it.

It would require someone who is blocked also having the massmessage right. Unlikely to be given to a user who is sitewide blocked, but could happen if they are only partially blocked.

Separate bug?

In T216185#5019204, @dbarratt wrote:

In T216185#5018754, @TBolliger wrote:

Whelp, it looks like we won't want to merge the lists!

I'm not sure why that would change anything. Just because a user fills out one list, doesn't mean they did not want the user to also be on the other.

Whelp, it looks like we won't want to merge the lists! (Unless — and this would require some research from Claudia — people are only aware of one list. We don't want to conflate usage with expectation. Regardless for now we can delay on merging the lists.)

Wonderful wonderful. The underscores are not a concern of mine.

👍

In T196575#5012772, @MER-C wrote:

FYI: T216245: VisualEditor, MobileFrontend, and other tools using action=edit do not auto-block IP addresses

In T211578#5010741, @dom_walden wrote:

CheckUser:

After searching for username or IP, it allows you to block a single user or IP by sending you to the URL Special:Block/$user. I did not test this.

You can mass block users after you have found them by IP by posting a list of their usernames. This is a sitewide, autoblock block (no option) but you can choose to block users from sending email and their user talk. I checked that these were applied in the database and were effective in the UI when logged in as those users. Also checked that the autoblock was applied to the last IP the user used (and had the same parameters except duration and email block).

Cannot mass block IPs, that I could see.

If you search for the edits of a blocking user/IP, the block appears in the list with the correct parameters reported.

No apparent way to edit blocks via CheckUser. If you mass block users, any users who are already blocked have their current block left untouched.

I believe this covers all the relevant functionality of CheckUser, unless I have missed something.

I also checked that the page Special:CheckUser was not blocked for someone with a partial block.

• https://en.wiktionary.beta.wmflabs.org/wiki/Wiktionary:Main_Page
• https://en.wikibooks.beta.wmflabs.org/wiki/Main_Page
• https://en.wikisource.beta.wmflabs.org/wiki/Main_Page
• https://commons.wikimedia.beta.wmflabs.org/wiki/Special:Block

Confirmed fixed on local dev env

There are now CI checks for performance, and we'll just send an email to the Performance team as a courtesy. No need for a task to track this work.

If we're going to remove this from the API we should also remove them from the public wiki page, and obfuscate them to some degree

Partial blocks were only enabled on Italian Wikipedia in January of this year, so the only historical data would be from the past 2 months.

We're going live today. Thank you!

We will not do this, as we have other methods of gathering this data.

We will not do this, as we have other methods of gathering this data.

This comment is partially CYA, but lets not forget about T194301: Introduce temporary element on Special:Block UI to invite users to participate in the Partial Block consultation which ran from July 19-23 in multiple languages.

• T173838: Enable EchoPerUserBlacklist on all Wikimedia wikis with Echo enabled was merged August 28, 2017
• T177437: Update Echo and Run Maintenance Script ran on October 10, 2017
• T177319: Enable Email Mute on all Wikimedia wikis was merged October 25, 2017

OK, I emailed techsupport@. Thank you!

Sounds good to me Thalia!

I think we can remove the 'Learn more' link out of the help label.

@dom_walden — Of all these extensions and your comments, I think CheckUser is the one that could benefit from some additional testing of both Sitewide and Partial Blocks.

Our team has published our recommendations here: https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements#March_1,_2019