Was this the only right that wasn't present in a grant?

Any updates on this being addressed? This is needed for a number of user scripts and gadgets.

Thanks for mocking up the options.

I don't think the change in T429258 an improvement to the UI. It makes the target for opening the Tools menu uncomfortably small, replaces a clear label with a vague and overused "three dots" icon, and reduces consistency with the adjacent controls. I don't think saving a small amount of horizontal space justifies the loss in clarity and ease of use. Space is much less constrained on the desktop site than on a mobile device.

I don't think this change is an improvement to the UI. It makes the target for opening the Tools menu uncomfortably small, replaces a clear label with an ambiguous and overused "three dots" icon, and reduces consistency with the adjacent controls. I don't think saving a small amount of horizontal space justifies the loss in clarity and ease of use. Space is much less constrained on the desktop site than on a mobile device.

I think it will be the right call to have the summary field following the same permissions as the filter. If the filter is not private, there's no reason to hide it. If the filter is private, then the description will be the only public information (like it is now).

@kostajh It's hard to know without that information (difficulty level) being present in abuse filter logs.

To clarify, the new hook I'm proposing would be orthogonal to wikipage.content. It would be for dialogs, sidebars, etc. that add content like user links, page links, etc. which would want to be processed in user scripts and gadgets that perform function such as user group highlighting, block/lock marking, hover popups, etc.

There are many good arguments against using wikipage.content for this purpose and I agree with them.

The toolbar Info includes content that's almost always part of #mw-content-text: various standard links for the page creator, and the page history. Scripts that use and modify those elements generally monitor the wikipage.content hook.

One approach that might help is to scope these messages more to debugging and development contexts:

• Emit the "out of sample" and other warnings from this code only when a debug flag or development mode is enabled (e.g., via a mw.config option, query parameter, user option, or localStorage setting). Perhaps the debug=true URL parameter would work for this?
• Keep the more verbose logging on beta and development environments, while suppressing it on production.

Limit UserInfoCard to showing blocks within the past year

Image of the minimal example from above:

A discussion about this has been opened at https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard#Addition_of_abusefilter-modify-restricted_right_to_EFMs.

There has not been an RFC.

In T405312#11204074, @Pppery wrote:

Unchecking "Unlock further protect options" has to do something; without it checked the "edit" and "move" protections are forced to be the same level.

Other information (browser name/version, screenshots, etc.):

The up and down buttons on the numeric fields are:

Another idea that has been discussed is the idea of being able to set a random failure rate for CAPTCHAs. This would only be used for highly accurate filters targeting severe abuse.

In T399351#10997090, @Pppery wrote:

I don't think the concept of CAPTCHA difficulty exists at all right now.

In T360592#10836006, @MusikAnimal wrote:

I think this is a misconception of the wikipage.content hook. It is not restricted to solely #mw-content-text. I've filed T394707: Do something about misconceptions of the wikipage.content hook.

In T377620#10244075, @TheDJ wrote:

Most of the times, scripts don't need this as they can simply be root relative. In the rare cases where it is required (URL constructor for instance), MediaWiki core scripts indeed use window.location or document.location.

In T195318#9784442, @Ahecht wrote:

I would vote for removing Rule 3 entirely. Skipping it for latin languages would solve the problem for users of latin languages, but not for users of non-latin languages. I would think that, except for the fallbacks explicitly laid out in fallbacks.json, showing the native name is preferable to a random name that happens to use the same script.

This problem is becoming worse and worse over time. Major place names in Manhattan are almost entirely Serbian at this point because name:sr-Latn is prioritized higher than the default name (which is English). The latinization code should probably not do anything if the default text is already entirely Latin characters.

I've been working on some user scripts that deal with custom signatures and it is a serious design flaw that there is nothing wrapping custom signatures and, more broadly, it's an issue that nothing indicates where a comment ends and the signature starts. This is especially the case given how many signatures are: