Nov 26 2018
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?
Nov 5 2018
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.
Aug 5 2018
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.
Jul 10 2018
Thanks. I have no concerns if this is left to individual users to decide what hoops they want to create for themselves.
Jul 9 2018
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.
Jun 27 2018
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.
Jun 5 2018
May 29 2018
Yes, please. Certainly not a "need to have" but useful from a user perspective.
Mar 15 2018
Jan 5 2018
Tagging as resolved - completed 30 Nov.
Jan 4 2018
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)
Nov 4 2017
Sep 21 2017
I'm in Pacific Standard Time, like California. I'm available during the day most of the time.
Sep 15 2017
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.
Sep 14 2017
Feb 23 2017
Ok, how can that be accomplished?
Feb 6 2017
Jan 23 2017
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.
Dec 30 2016
Oh yes, that was me trying to reboot. But then I realized that it wasn't a server issue.
Nov 14 2016
I'm not really sure how to fix this either. George?
Oct 4 2016
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.
Sep 21 2016
Jul 23 2016
Jul 15 2016
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.
Jul 9 2016
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?
Jun 10 2016
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.
Jun 5 2016
Hi. This is already done for user renaming now. Can the same be done for at least userrights-interwiki uses?
May 31 2016
May 30 2016
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.
May 17 2016
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.
May 16 2016
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.
May 11 2016
I don't think extra time will be needed. Go ahead and process when ready, thanks.
May 10 2016
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.
Apr 25 2016
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.
Set to normal priority. No/few cases of needed use so far, but should be built in.
Apr 23 2016
Apr 22 2016
Apr 18 2016
Apr 1 2016
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.
Nov 3 2015
Oct 28 2015
So I'm still not sure why we need two groups. Two very obvious options:
- Add flow-suppress to the oversight group, which makes the most sense. Changing it over to suppress can be done at any time.
- Change the oversight group to suppress right now and add flow-suppress to it.
Apr 8 2015
Yes, thanks Krenair. The global renameuser.
Apr 3 2015
Feb 11 2015
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.
Dec 19 2014
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.