I have the electionadmin userright, but I think I need to be added as an admin for that specific campaign before I can see that data. I only see time, username, and domain at the moment.

Hello, I have no access to CU information on votewiki. Is this intentional?

Yes, that is already the case if the unblockself right is removed. Self-imposed blocks can always be self-removed.

There's also a proposal on enwiki to do just this: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Should_administrators_be_able_to_unblock_themselves?

In T197158#4720867, @Krenair wrote:

In T197158#4720826, @Ajraddatz wrote:

And all of this in response to, if I remember correctly, one time in the past year when an attacker gained CU access.

You make it sound like that's not a big deal.

In T197158#4720826, @Ajraddatz wrote:

2FA is not a silver bullet. It can be compromised as well, through phishing sites and the like.

That's something that can be worked on (e.g. U2F instead of TOTP), but just because it doesn't protect against everything doesn't mean it's not going to become required.

This would be a severe security overreaction to a problem that doesn't exist. For stewards, use of the CU tool is routine and happens multiple times during the day. Adding the requirement to authenticate, even every 30 to 60 minutes, would be horrible from a user experience perspective. And all of this in response to, if I remember correctly, one time in the past year when an attacker gained CU access.

I tested it earlier today - without the editsitecss/editsitejs you can't delete the page, even if it is unprotected.

I'm not seeing a huge issue here. Wikis will just need to ensure they have enough sysop + intadmins to delete these pages if they come up (if needed). If the issue of users creating oversightable content in a js/css page exists in the future, we could look at a workaround for oversighters. Otherwise stewards exist as always to act in emergencies or where nobody else can.

Thanks. I have no concerns if this is left to individual users to decide what hoops they want to create for themselves.

I really hope that none of this would be mandatory. I'm personally a fan of efficiency and proportionate security responses, of which this is not one.

In previous cases, the page in question has been blanked instead of deleted. That could probably be done as an interim solution here as well.

In T194605#4259027, @demon wrote:

In T194605#4205086, @MarcoAurelio wrote:

Locked means account disabled, fully; not even able to log-in (and session terminated if locked while logged in fwiw).

Why on earth do we even bother with such a distinction?

Yes, please. Certainly not a "need to have" but useful from a user perspective.

Tagging as resolved - completed 30 Nov.

I've added the new right to the stewards global group, because in the local group it only works on Meta. This is an issue for global renamers, as they don't have a global group. As it stands, they will only be able to send emails from Meta. (or where the user a) has an account with edits and b) has enabled receiving emails)

I'm in Pacific Standard Time, like California. I'm available during the day most of the time.

I'll probably be asleep then! But I'll be around sometime between 1600 and 1700 UTC on Monday, and I'll go on IRC and ask in -ops when I am on.

It's all on enwiki.

Ok, how can that be accomplished?

Agree with Billinghurst. If any IP attempts to create a page that is blocked by an abusefilter, that IP is kept forever in the logs. An IP attempting to create a username (and failing) is no different in that regard. The log could be restricted to sysops, and individual IP --> account connections suppressed out.

Oh yes, that was me trying to reboot. But then I realized that it wasn't a server issue.

I'm not really sure how to fix this either. George?

At some point, it's on the blocking admin to be cognisant of what they are blocking. The same criticism raised here could be raised regarding blocks in general. Keep the cookie for the block length; the issue of IPs being overblocked is separate and not related to this.

Apologies for being technically illiterate, but could the impact of cookie blocks be seen through the front-end interface? This would be useful for those actually giving the blocks, or for CheckUsers investigating block evasion.

https://www.mediawiki.org/wiki/User:Legoktm/Wikimania_2016_steward_tools

I set up the mediawiki message directing people to SRM. Stewards have the technical ability to approve OAuth customers, but have been hesitant to do so and the full "hand-over" still has not happened. But we are helping to approve some requests from trusted sources to reduce the backlog.

Work is needed on the extension, no matter what form that comes in. In terms of the steward workflow, the most useful addition would be a global checkuser - something which would require a rewrite or a new tool anyway. Could a revamp of the existing CU architecture happen in conjunction with this?

The previous page was so unusable for finding information that Pathoschild made a tool which listed the groups and their associated rights on the labs to compensate. I'm not expecting daily viewership here, but it is useful to be able to link to a page that clearly displays which global groups are active and have specific permissions. I would still prefer that it be separated from group management, but I can also understand the duplication concerns.

Hi. This is already done for user renaming now. Can the same be done for at least userrights-interwiki uses?

This sounds more like a want to have than a need to have. Would there be any real benefit for this? We could also include a log count, but I'm not sure that it would add much valuable and useful information.

Option 2 sounds perfect. Thanks for suggesting something better! I'll change the title of this ticket, and focus my initial efforts at modifying the globalgrouppermissions page instead.

Essentially, yes. One page for managing and another for viewing, as is common with wiki extensions. Alternatively, the GlobalGroupPermissions page could be modified to have a more usable interface when reading which permissions a group has. (and preferably still with linking between it and ListGroupRights).

This text is good. Please proceed with implementation.

I don't think extra time will be needed. Go ahead and process when ready, thanks.

Hi, thanks for fixing the location of the bug I opened. I am happy to report that I just got an email through the emailuser system which also pinged me through echo! I'm not sure if the problem is totally fixed, since it appeared to be intermittent anyway, and it doesn't look like any patch is linked here.

Copying my explanation from the merged task:
Currently, global locks cannot apply an autoblock and only prevent users from logging in. It would be beneficial to add a "global block" option to this, so that the autoblock can be applied. Currently stewards need to use CheckUser to find the IP address and then separately globally block it, which is public and usually results in an easy connection of account --> IP.

In T47094#2032102, @MarcoAurelio wrote:

In T47094#1864787, @Luke081515 wrote:

I think we don't need this: If you hide or oversight a account, this account gets blocked at all local projects.

That's not how it works. Global account hidding just removes the account from Special:GlobalUsers and maybe users without the appropriate rights can't access Special:CentralAuth for that user either. When we globally oversight an account, CentralAuth goes wiki-by-wiki where the account exists and blocks the user with with nocreate, noemail, nousertalk, hideuser. Now, what would be the purpose on having an unlocked account but not visible in Special:GlobalUsers? or even worse, an unlocked account but globally oversighted? I've always thought "hidding" options were a complement for a lock. Best regards.

Set to normal priority. No/few cases of needed use so far, but should be built in.

I agree that there should be separate global and local filter limits. With no impact on local projects, this shouldn't need any sort of community approval, other than customary input (perhaps through an RfC?) that allows people to point out concerns and perhaps develop systems through which other individuals can become involved in the process.

So I'm still not sure why we need two groups. Two very obvious options:

1. Add flow-suppress to the oversight group, which makes the most sense. Changing it over to suppress can be done at any time.
2. Change the oversight group to suppress right now and add flow-suppress to it.

Yes, thanks Krenair. The global renameuser.

https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=move&user=Ajraddatz&page=&year=&month=-1&tagfilter=

Potentially not, it was reported by another steward and it looked like it happened after the fix. I can't replicate as I did a rights change since and it worked fine.

FYI: Same bug now occurring again with interwiki rights changes. https://meta.wikimedia.org/wiki/Special:UserRights/Bencmq@zhwiki is an example.

I think links to global contributions for the IP and global block would be very useful for stewards. The former would be good for anyone to check other abuses.