@matej_suchanek Hi, what will happen with this?

May also want to consider $wgEchoPerUserBlacklist.

In T359677#9617731, @Nikerabbit wrote:

I think they can be enabled, but the reason is that we haven't changed the default settings. Maybe worth trying to change the defaults in MediaWiki?

In T355033#9499833, @Superpes15 wrote:

Indeed I don't see where my proposal (which is the same as the one made in more depth by Martin) violated the community consensus!

@Urbanecm Hello. What you say makes a lot of sense. It is completely equivalent to what the community is requesting and it suits the community needs.

@Superpes15 The vote was clear. The results were towards disabling the magic word INDEX sitewide. It was also clarified that the magic word NOINDEX was out of scope for that vote. Therefore, I suppose that disabling NOINDEX would violate community consensus, and therefore, the configuration change cannot be made.

@MusikAnimal Hi, I hope I'm not bothering you. Just another suggestion to consider: the icon for global-interface-editor should probably be changed to https://commons.wikimedia.org/wiki/File:InterfaceEditorIcon.png to make it clear that it is the global flag and not the local.

@MusikAnimal Hi, I saw you used Crystal_Clear_action_run.png for suppress. Just wanted to make sure if you did it purposely or if it was a mistake, because it is the same icon used for bot and in my opinion it doesn't feel right for oversighters. However, I respect your judgement.

Now a notification is sent to the last editor when a filter matches the emergency throttling conditions, so I think this is resolved now.

In T286513#7206964, @MarcoAurelio wrote:

Noting that the community authorized only granting local oversighters the ability to view deleted edits/revisions (which is just deletedtext) (lit.: ¿Debe permitirse a los supresores ver ediciones marcadas como borradas? transl.: Shall we let oversighters to see deleted edits?). The other permissions where not voted/mentioned and should not be added, especially after the technical insuficiency of the proposal was raised and was not acted upon (the previous wording of the vote which proposed bulk adding all required deletion and block-related permissions to make the group self-sufficient was never adopted and its scope narrowed just to "see deleted edits"). Thanks.

Hi. When will the deployment happen?

In T285167#7163740, @Zabe wrote:

In T285167#7163719, @SRuizR wrote:

@Zabe Hi. I don't know if my question has sense but better safe than sorry. Won't this config change have a conflict with the other config change that we're about to deploy (T284797)?

Just want to make sure to feel safe.

The lines
$wgGroupPermissions['abusefilter']['abusefilter-view-private'] = true; // T262174
and
$wgGroupPermissions['abusefilter']['oathauth-enable'] = true; // T262174
stay untouched and the patch for this task adds a line between those and the patch for the other task adds lines above and below those, so both patches don't touch and there should be no conflict.

@Zabe Hi. I don't know if my question has sense but better safe than sorry. Won't this config change have a conflict with the other config change that we're about to deploy (T284797)?

@Zabe Hi. Someone did this: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/699489/1#message-18916e5b0798dcec319186c6a1c77626d4e49eea

The characters "ª" (A), "º" (O) and "°" (O) should also be included.

In T200036#6948347, @Daimona wrote:

This issue has become a little bit more important now that we send notifications (echo) when a filter is throttled. These notifications are sent out when af_throttled is set, which can happen regardless of throttled actions.

Nevermind. The extension is working correctly.

I think this could be merged with T187686 because I think it's the only possible thing that could be made.

Done at T266298

The only thing I thought about was the regex empty match, but there may be other things. Anyway, I think Daimona's option (2) is the best thing to avoid incidents.

In T262174#6439552, @MarcoAurelio wrote:

In T262174#6439546, @SRuizR wrote:

I think it should be assigned and removed by the group sysop, as interface-admins are also assigned by that group and the group bureaucrat assigns very few permissions.

Well, I don't really mind one way or another. The vote did not mentioned who should be able to, so I default to the bureaucrat user group which traditionally handled user group management. Considering that eswiki sysops are all also bureaucrats, this is purely a no-op.

I think it should be assigned and removed by the group sysop, as interface-admins are also assigned by that group and the group bureaucrat assigns very few permissions.

Nevermind, I restarted my computer and now it's working. Kind regards.

Yes, I'm with the desktop site. I tried with my alternative account SRuizR777 in incognito mode at 1:50 UTC. Surprisingly it worked. I tried with my main account SRuizR in incognito mode at 1:52 UTC and it also worked.

My OS is Windows 7 my browser is Google Chrome. I don't have any cookie blocking or privacy extension.

I'm in Special:UserLogin, I put my password and press Log In, but when I press Log In it doesn't respond and shows the message in MediaWiki:Sessionfailure. Here's the screenshot of the SameSite thing.