Deprioritizing this task in favor of our upcoming work on CheckUser.
Deprioritizing this task in favor of our upcoming work on CheckUser extension.
I believe all known defects with Partial blocks have been filed already. @dom_walden would you like this to be kept open?
@Tchanders I don't have a good recollection of why I moved this ticket to In progress (maybe during a meeting discussion?). Do you think it's okay if we drop it from the board?
@Tchanders I like the idea. Another thing we can do to solve #2 is to change it to be Your username or IP address is blocked instead of has been blocked. That reduces the implication that their editing attempt caused the block, I think.
So something like Your username or IP address is blocked from doing this. You may still be able to do other things on this site, such as editing certain articles.
Tue, Oct 15
@thcipriani I'm only using it on one device, my laptop. I primarily use Safari as my browser on a Macbook (macOS Mojave).
Sat, Oct 12
Roger that. Thanks a lot, Andre. I think we won’t need the Herald rule.
Closing this task as this task is not needed anymore - CommTech has been working on this project for a while now. The research in this task is still valid though.
Hey Andre, I'd like to keep this task open and continue to work on it for future hackathons. Added a relevant tag.
@dbarratt Looks like there's a comment on the patch for you.
@dbarratt Are you still working on this task? We could drop it from the board, otherwise. I'd rather wrap up blocks and get started with CU now.
The problems with global prefs should be fixed in beta with https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/542644/
@Tchanders - I made the config patch ^, don't worry about it. :)
@DannyS712 Thank you for your work here! I'm sorry, this missed my radar until now.
Thu, Oct 10
@dom_walden Should we close T227901: PHP warning on attempting to set a block cookie after CentralAuth auto login in that case?
Wed, Oct 9
@Tchanders That sounds like it would be ideal. Let's file a ticket. I would prioritize it low at this time since we need to get on to CheckUser soon, but having this documented is desirable.
@Tchanders, I agree that all attempts should be treated as equal. My first thought when reading this ticket was that the cookie should be set when the block is and the edit/other attempts should not affect it at all. Is that possible to do?
@Tchanders Looking at this another way -
- User A makes an attempt to edit every 6 hours, hoping their block has been lifted
- User B makes an attempt once but doesn't try again for a couple days
Three days days later, User A is still blocked but User B is not. In this scenario, one could say that we are punishing User A for trying to repeatedly edit and rewarding User B for not attempting to edit for 24 hours. User A might be trying to edit in good faith but because the cookie is repeatedly reset, they can potentially be blocked for days/weeks just because they keep trying.
Leaving this in until commons and wikidata betas have been tested.
@Ladsgroup Your thoughts on this ticket are also welcome!
Tue, Oct 8
Thanks @AnonManning. This project has been deprioritized until next year in favor of making improvements to CheckUser and other anti-vandalism tools.
I appreciate the page you put together. It will be very helpful when this project is taken on!
Fri, Oct 4
@dbarratt This task is more like a "rolling task" for deploying Special:Mute everywhere. It is only on betas and testwiki for now.
My apologies for the confusion but the Anti-Harassment tag is actually for the projects being actively worked on by the Anti-Harassment Tools team and not an umbrella project tag for all anti-harassment issues.
Thu, Oct 3
Tue, Oct 1
Mon, Sep 30
From my perspective as the PM on Anti-Harassment which is currently responsible for Special:Block, I do not mind if we remove it from that page. It was not an intentional feature.