In T17294#9529206, @Bugreporter wrote:

My proposed simple guide...

In T17294#9528943, @Dreamy_Jazz wrote:

In T17294#9527056, @Sj wrote:

@Dreamy_Jazz thank you for working through this. Do you need feedback on some of those comments from one of the stewards requesting this?

It would be useful to know how much of a use-case there is for allowing local wikis to disable a global block on an account.

This is the point :P

In T357118#9528544, @Xaosflux wrote:

This doesn't appear to be a bug; "appeals" of blocks are not a technical function and the blocking admin appears to be able to add any information, such as project specific appeal information, to the "Reason" field if they wish. Other than having the default message say something like "Contact your project administration" - where would this even go?

In T355286#9471605, @Tgr wrote:

People clearly want global locking to work like global blocking (e.g. T333244: Warn and confirm for self global locks, T19929: CentralAuth account locks should trigger global autoblocks). It doesn't make sense to maintain two parallel blocking infrastructures, especially when one of them doesn't integrate with MediaWiki's blocking system at all. Especially for something highly sensitive such as preventing account access (which the block system can also do, it's just not used on public Wikimedia wikis). The potential for conflict between local and global blocks was a problem, but the multiblocks migration resolves that, so we can just axe global locks and have GlobalBlocking (and normal blocking for non-SUL wikis, if there is any interest in that) take over the functionality.

In T355286#9471519, @Bugreporter wrote:

In T355286#9471514, @Xaosflux wrote:

In T355286#9471508, @Tgr wrote:

I think we should generally get rid of global locking and extend GlobalBlocking to non-anonymous users instead (T17294: Allow blocking of global accounts). It's on my todo list to see if the WIP patch on that task can be fixed up with limited effort.

In standard practices perhaps, though locking is still relevant for scenarios such as account compromises, deceased users, etc.

In this case Tgr propose to replace it with a variant of T222281: Add a way to prevent user from log in and disable a users session when blocking. Note if block-disable-login is available, in SUL wikis we need to prevent it be used locally, i.e. such option may only be enablable with a global block, not a local one, since it does not make sense if we lock out a user in wiki A but not wiki B.

+1 to Xaosflux. Global locks are a necessary tool, though global blocks should also be an option.

@sgrabarczuk: Would you be okay if I remove that line from the banner text? It won't affect translations of the other line, as they're two separate units.

In T340275#9143053, @Niharika wrote:

In T340275#8960404, @Bugreporter wrote:

I think T17294: Allow blocking of global accounts should be fixed instead.

Quick update - we are discussing this actively and there is a good chance we will end up working on T17294: Allow blocking of global accounts instead of this task. I will have another update within a couple of weeks. Thanks all for the helpful comments.

In T340275#9129585, @Sj wrote:

I would certainly be able to work with a semi-soft block. As it's possible to assign confirmed flags to new accounts, a variation could also allow running editing workshops through such blocked ranges. [schools often being subject to such blocks]

In T341414#9119218, @Ciell wrote:

Step 1-7 is needed to navigate to the translations starting from the Admin panel, I think to remember this specific section of the interface is visible for all, just not every user has access to change anything (read-only, as to say). Vermont is referring to step 8 in the process in their comment.

Yes, but you don't need to do all 7 steps every time you want to check on a banner you're supporting. When you setup a message group, you'll have a link to translate the message group, often to be included in the banner. From that link, click message group statistics, change which boxes are checked, and then there's the list of translations which you can then review and approve. Yes it's technically 8 steps in from just the search bar, but I'm not sure if there's any better way to navigate to message group stats for a specific message group besides through that chain of related pages. I'm certainly interested to know if there are thoughts on a better layout for these pages, though. My opposition to changing this is largely because, if we do get any development time (volunteer or staff) put towards this problem, there are more pressing things to work on. It's not great, but it's usable.

In T341414#9112530, @Frostly wrote:

I think that there are four distinct and actionable tasks here:

• Encourage the use of plain wikitext instead of HTML by default in banners

I'm a bit confused here; I don't think I've seen anyone including html markup in a banner translation unit. Generally, if there's a line of text, we'll just put a localizable message there, and then add the translations through the Translate extension. Because there's rarely differing formatting within a line, it's just one plain text line inside a <p> tag. Additionally, CN banners are not parsed as wikitext, it's just HTML.

• Make the interface for approving banner translations simpler and more intuitive

I'm also confused on this point. Approving translations are as simple as opening the drop-down (on the review page) and then clicking "publish" for each translation.

• Allow translation administrators to approve banner translations
• Provide banner requesters with temporary, limited translation adminship (similar to limited adminship)

These two should be relatively easy to implement, depending on how the CN and Translate extensions bundle actions into their relevant userrights. Once the former is done, the latter is just a matter of a Meta-Wiki RfC, if we think that's even necessary.

The idea of allowing any two users to approve translations for CN banners is not a workable idea. This would make global CN banners incredibly susceptible to vandalism on a global scale, and far less protected than any random translatable page.

To maintain current capabilities, we would need to be able to set global blocks that only apply to temporary accounts (curently soft blocks), and global blocks which also apply to logged-in users (hard blocks).

I gave this ticket a more thorough read, and there are some points I would like to clarify.

In T309328#9058626, @valerio.bozzolan wrote:

Premising that, as far as I understand, the community of CheckUsers very much like the current "bug" that "blocks everyone in the damn planet including registered users, including autopatrolleds, including ...". So, while the situation could be improved (that is not acceptable honestly to me as-is) as compromise we should think about how to still give to our dear CheckUsers the ability to monitor the situation of registered users (so, CU should be able to "spy" whatever sysop that is exiting from non-predictive Internet nodes like "open proxies", for whatever is their weird legitimate investigative reason to explain such invasive eye on trusted "coworkers"...)

In T313446#8094343, @RoySmith wrote:

Perhaps that could be formalized, with a little help from the software. Imagine a work flow like this:

It appears that the many users affected by T-Mobile range blocks, which of course will (for the most part) only affect mobile devices, are not able to see any of the helpful templates intended to be viewed in the block notice on mobile, because of this issue.

It hasn't worked for the Spanish Wikipedia's CopyPatrol since the 4th of January, it seems. Same with the French version.

Another complaint about this account at https://meta.wikimedia.org/wiki/Talk:Steward_requests/Permissions#Strange_administrator_wikiquote:de:user:Missbrauchsfilter

In T150826#4778796, @Bawolff wrote:

There's discussion on enwiki about also having a rate limit on blocking users. Seems like a reasonable enough idea, but we'd want it high, as we really only want it in cases of truly malicious users.

I believe this should be handled by a meta RfC rather than discussion at the enwiki Village Pump and a Phab ticket. (Unless, of course, the WMF wants to act on it immediately as a security issue)

In T181848#3910896, @awight wrote:

In T181848#3852728, @Halfak wrote:

Oh this is done. It has been reviewed by @Adotchar

@Halfak @Adotchar can either of you confirm that this task can be closed? I remember some confusion on IRC when Aaron's comment went through. I would assume that experimentation would have to be done on the beta cluster, which doesn't have the models enabled yet, so unsure how this task would be completed. I'll update the task description per my understanding, please edit if I'm off-base.

In T181848#3805841, @Halfak wrote:

OK so here's what I suggest you do.

1. Disable the new recent changes filters in your preferences.
2. Edit your "/common.js" to look like mine: https://simple.wikipedia.org/wiki/User:EpochFail/common.js
3. Go back to Special:RecentChanges and wait a little bit. ORES should highlight changes that are likely to be damaging.
4. Tell us how it goes!

I did a little bit of testing and I was able to catch some damaging edits :)