In T214215#4894705, @Tgr wrote:

In T214215#4894170, @Reedy wrote:

We shouldn't be enforcing anything just yet as https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/479570/ isn't publicised/deployed yet

Also it's going to force password change, not reset. (Same as the current nag screen except there won't be a Skip button.)

Yeah the message could be improved (although gerrit 479570 as written now will remove this check entirely). Also it does not prevent non-fatal errors from being displayed, which results in the weird duplication (since MinimalPasswordLength also runs and has the same message). Not sure if that's worth the effort though.

In T214215#4894365, @Reedy wrote:

In T214215#4894326, @Anomie wrote:

I'm guessing this was your account in the "staff" global group?

If so, this is invalid and can be made public

In T212391#4836562, @JJMC89 wrote:

In T212391#4836552, @dmaza wrote:

@JJMC89 Unless I'm missing something, you can't create an account if you are already signed in.

Yes, you can. (I do it all the time.)

@JJMC89 Unless I'm missing something, you can't create an account if you are already signed in.

In T191922#4827648, @daniel wrote:

In T191922#4540021, @Jdforrester-WMF wrote:

Let's do it.

Uh, right. Who is doing it?

In T211276#4803503, @Anomie wrote:

FYI: The value is passed to the UserIsBlockedFrom hook, where MediaWiki-extensions-LiquidThreads tries to make use of it.

Right. And UserIsBlockedFrom signature will need to change for this. LiquidThreads can be fix accordingly.

If there is a partial block for an ip range, the same rules will apply. It will all work the same as what's described in the acceptance criteria (Unless I'm missing something) . The Target of the block makes no difference for this. The moving parts are the block type (sitewide|partial), the "Prevent ..." checkbox, and the restrictions (for now only pages).

Is it safe to assume that we only need to check on those 4 extensions ( CirrusSearch, WikibaseQualityConstraints, Wikibase, EducationProgram ) ?
I still think that @Addshore's patch should be merged regardless.

@Addshore @Legoktm are we ready to move forward with the patch on wikibase? What do we need to get https://gerrit.wikimedia.org/r/c/mediawiki/core/+/471993 (or a version of it) back on wmf.6?

• The "Prevent [...] own talk page" checkbox should only be active if the block is configured to sitewide OR if the admin has configured ?the Partial Block to include the User_talk: namespace
• The Page and Namespace inputs should not change (i.e. allow for the block target's talk page and/or the entire User_talk: namespace)

You removed this TODO, but didn't really address the question. If a namespace block covers NS_USER_TALK, IMO that probably should not override $block->prevents( 'editownusertalk' ) === false.

This patch does exactly the opposite: if a block covers anything *except* the user's talk page, you're making $block->prevents( 'editownusertalk' ) === true also prevent talk page access. Which to me also seems like the wrong thing to do.

---

Perhaps I should explain my reasoning a bit more.

A sitewide block blocks the user from everything. The checkbox labeled "Prevent this user from editing their own talk page while blocked" really serves to exempt the user's talk page from that when the checkbox is unchecked, to allow the user an avenue of appeal.

For partial blocks from the whole user talk namespace, I'd expect it to work the same way: To allow appeal the user can still edit their own talk page unless the blocking admin specifically took that away by checking the box. But you've implemented the opposite here.

If the partial block doesn't cover the user talk namespace (e.g. a block from a single article), IMO it doesn't make sense to even have the "Prevent this user from editing their own talk page while blocked" checkbox shown. Even if it is shown, I can't think of any situation where I as a blocking admin would want to check the box for such a block and have it take effect.

If we had category blocks, again I'd expect the user to be able to edit their own talk page for appeals even if their talk page happens to have a blocked category on it.

The only case I can think of where I as a blocking admin actually *would* want the block to ignore "Prevent this user from editing their own talk page while blocked" being unchecked is if it's a specific-page block for the user's talk page. Because in that case it's clear I really am trying to stop the user from editing their talk page.

OTOH, I can't think of any case where I'd use a partial block for removing a user's own talk page access, since if they're misbehaving enough to lose access to their own talk page there's probably no reason not to block them sitewide. So maybe the thing to do would be to hide "Prevent this user from editing their own talk page while blocked" checkbox entirely (forcing it to false) when creating a partial block?

Does that make sense to you?

So here is a proposal for consistency. What if we only show the message if the user is not allow to create the user page or to create the user talk page regardless of the block type?
The only difference from what we have discussed so far is that if the user is sitewide blocked but can create their own talk page, the message will not show on their talk page.

Should the message be displayed if the block is partial and it applies to the page? It could be an explicit Page/Namespace block or the block might prevent the user from editing their own user talk

And maybe these pages too?

• https://www.mediawiki.org/wiki/Manual:Block_and_unblock
• https://www.mediawiki.org/wiki/Help:Blocking_users
• Create https://www.mediawiki.org/wiki/Manual:$wgEnablePartialBlocks and link it to relevant pages like https://www.mediawiki.org/wiki/Manual:Configuration_settings_(alphabetical)
• https://www.mediawiki.org/wiki/Manual:Ipblocks_restrictions_table should be added to https://www.mediawiki.org/wiki/Manual:Database_layout

In T209819#4758709, @bd808 wrote:

This table does not contain any private data and it should be exposed to the replicas.

@dmaza, can you be the person in charge of getting someone from the Security team to validate this claim on this ticket?

@Marostegui what about the new column ipblocks.ipb_sitewide? what do we need to do to add that to the current view for ipblocks?

In T209549#4757473, @Marostegui wrote:

That is not correct.
Tables do not get exposed by default to prevent accidental data leaks.
Note that "exposed" is different from "sanitized".

Exposed means that there are no views on that table, so it can not be read from labs views. If you need a new view on that table (which exists on labs already) you need to talk to cloud-services-team. Please talk to Security before to make sure it is ok to expose the table.
Sanitized means that that table has some data that SHOULD NOT be on labs (not even present), if that is the case, you need to add the columns that need to be redacted to filtered_tables.txt. If you are not sure if the data should be present, talk to Security please.

In T209549#4757436, @Marostegui wrote:

I don't really understand what filtered_tables.txt you guys expect to get from adding the table there. This file is only used to generate triggers and sanitize columns on labs.