Someone else will need to test this, still broken on beta
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 6 2023
Dec 4 2022
Jun 27 2021
May 10 2020
May 9 2020
Mar 15 2020
Feb 4 2020
Oct 1 2019
Aug 28 2019
Jul 24 2019
Apr 7 2019
Apr 5 2019
Apr 4 2019
Mar 15 2019
@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!
Mar 14 2019
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
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. 😆
Mar 13 2019
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?
Mar 12 2019
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:
Mar 8 2019
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.
Mar 7 2019
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!
Mar 6 2019
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
Mar 5 2019
OK, I emailed techsupport@. Thank you!
Mar 4 2019
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.
Mar 1 2019
Our team has published our recommendations here: https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements#March_1,_2019