@dom_walden good catch. This patch fixes the advertise bug as well. There is a separate issue and that is that the user doesn't get any feedback when they are blocked and try to advertise but that's unrelated to PB.

In T218949#5046885, @alanajjar wrote:

Note: if you want I can make a short video.

@dmaza Did the team ever discuss this? It makes sense to me to update these pages too. I can go ahead and add them to the ticket description if there are no concerns.

That would make sense. IMO I don't think this data is worth keeping. Pinging @Tchanders @dbarratt @aezell for their thoughts.

@Niharika the patch will not remove the data but I'm not sure for how long we keep those metrics around. I can't find anything on wikitech.

In T211621#5026677, @dom_walden wrote:

I notice that users in the "staff" group will have

['MinimumPasswordLengthToLogin'] = [
  'value' => 10,
  'suggestChangeOnLogin' => true,
];

and I believe this will force them to change their passwords.

That means if there is a failed skipLogin check and a failed normal check, both error messages will show, even though the skipLogin one would not show on its own

This is why I said that the same approach as forceChange can't be used. It was my understanding that the warning shouldn't be shown when other policies fail. If this is an accepted behavior then I agree with you that it should work just fine like you described in your last comment.

In T211621#4878804, @Tgr wrote:

Probably should be handled the same way as rMWf15ecc60cd94: Add force option to password policy: add some password policy option like skipLogin, handle merging of different policy options / statuses in UserPasswordPolicy and put the result in a status flag, handle the flag in AbstractPasswordPrimaryAuthenticationProvider::setPasswordResetFlag.

Working on it right now. Will push fix in the next few mins

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?