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?

In T228950#5570107, @dbarratt wrote:

@Tchanders & @Niharika when the UI says: "global users list" is that just Special:GlobalUsers ? If so, it looks like GlobalUsersPager::getQueryInfo to ensure that only users who are not hidden in any way are shown:

$conds = [ 'gu_hidden' => CentralAuthUser::HIDDEN_NONE ];

or are we talking about some other page?

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

In T226995#5569731, @dbarratt wrote:

In T226995#5568090, @Niharika wrote:

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

It's about ~60% completed, but honestly I'm fine dropping it for now. I can always pick it back up later. :)
https://github.com/wikimedia/InteractionTimeline/pull/101

@thcipriani I'm only using it on one device, my laptop. I primarily use Safari as my browser on a Macbook (macOS Mojave).

Roger that. Thanks a lot, Andre. I think we won’t need the Herald rule.

In T160233#5569369, @DannyS712 wrote:

How do I identify the "product owner"?

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.
Thank you!

In T160233#5568988, @DannyS712 wrote:

@Niharika I think this is the second time where I finished coding something, only to then be told it needed consensus/approval (see previously T207577). To ensure that developer time isn't wasted, is there a way to get approval before people begin work?

In T160233#5568099, @DannyS712 wrote:

In T160233#5568022, @Niharika wrote:

@DannyS712 Thank you for your work here! I'm sorry, this missed my radar until now.
Taking a look at the Wishlist proposal and discussion, it is very clear that this is very much a community decision and 20 out of the 48 votes were Strong oppose/Oppose/Neutral to this idea. We should not be enabling this until there is a larger buy-in from the community about this. This proposal should go through an RfC on the wikis and the outcome of that should inform what is built.
As it stands, I don't think it is a good idea to build this functionality.

Well, I already wrote the code; what about having it be a configuration option that is disabled by default?

In T233594#5563962, @Tchanders wrote:

@Niharika We should be able to close T227901 once all WMF sites are on 1.35.0-wmf.1. The logs will still be recording that warning until then.

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

In T228950#5568071, @dbarratt wrote:

@Niharika there is an open question from @Tchanders, I think we talked about it but didn't come to a resolution:

With this change, the account is no longer hidden when an admin chooses "Account is hidden from the global users list" in Special:CentralAuth.
If we wanted to allow a user to be hidden but not blocked, we'd need to reintroduce something like the UserIsHidden hook, and set the mHideName flag directly on the User, without setting a block.
I don't think we should do that - the fact that a user cannot now be hidden without a block is not a regression, but an intended consequence of deprecating the UserIsHidden hook (explained in T228948).

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/534849#message-4ea3c3988f99592353e78565ede94973db385139
I think that option only effects that single page, so we can either remove the option completely, or fix the patch.

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

Ping @dbarratt @Tchanders - is there anything blocking this ticket?

@DannyS712 Thank you for your work here! I'm sorry, this missed my radar until now.

In T227901#5560609, @Tchanders wrote:

@Krinkle Sorry should have clarified - this should be fixed in 1.35.0-wmf.1

In T233594#5559135, @dom_walden wrote:

We also modified BlockManager::trackBlockWithCookie which has caused us problems in the past (e.g. T226777 and T227901). Just in case, I attempted to reproduce the bugs in T227901 and T226777, but could not.

@dom_walden Should we close T227901: PHP warning on attempting to set a block cookie after CentralAuth auto login in that case?

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

In T233594#5556842, @dbarratt wrote:

It looks like instances of RedirectSpecialPage and ActionRaw are not getting the block cookies. For RedirectSpecialPage I'm not sure this is an issue because the user will get the cookies after the redirect is complete. For ActionRaw it looks like it sets its own headers rather than using OutputPage, perhaps a new task should be created for one or both of these issues.
I don't think either of these are a big deal, but I defer to @Niharika. :)

In T233594#5556878, @dom_walden wrote:

In T233594#5556842, @dbarratt wrote:

It looks like instances of RedirectSpecialPage and ActionRaw are not getting the block cookies. For RedirectSpecialPage I'm not sure this is an issue because the user will get the cookies after the redirect is complete...

Sorry, bit of miscommunication. The cookie is not set even after the redirect completes.

@Ladsgroup Your thoughts on this ticket are also welcome!

In T234980#5557869, @Huji wrote:

T184075 was an attempt in this regard. I have the result of that analysis somewhere.

In T233595#5558131, @dbarratt wrote:

In T233595#5558130, @Niharika wrote:

Thanks for the explanation, @dbarratt and @Tchanders. Is there a reason we want to change the existing behavior (hard 24 hours expiry)?

I don't have a reason to change it.

Thanks for the explanation, @dbarratt and @Tchanders. Is there a reason we want to change the existing behavior (hard 24 hours expiry)?

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!

In T225774#5539697, @aezell wrote:

Who is the primary audience for these reports? Where do they end up?

In T231577#5541625, @dom_walden wrote:

Testing on:

• https://nl.wikipedia.beta.wmflabs.org MediaWiki 1.34.0-alpha (0174952) 1 okt 2019 10:34
• https://test.wikipedia.org MediaWiki 1.34.0-wmf.24 (9d74db9) 17:04, 25 September 2019

• The features added work as expected in different languages

Adds and removes a user from the email and notification blacklists

• The features added work as expected in wikibase betas (commons and wikidata beta wikis)

Not on Commons or Wikidata yet.

Oh I meant on https://commons.wikimedia.beta.wmflabs.org and https://wikidata.beta.wmflabs.org/

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

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.

In T227199#5325646, @Tchanders wrote:

I think we should keep this open, because it is still technically possible to make this type of block with JavaScript disabled.

On second thoughts, we already have a task for that work (T224468), so I think we can close this.