Is this enabled?
[edit]
Allow sysops to grant confirmed
[edit]As of now, this permission can only be given out by a bureaucrat. There isn't much reason why we need to restrict this to bureaucrats only, particularly given that we're far more likely to have at least 1 active sysop most times of the day. //shb (t | c | m) 05:24, 10 February 2025 (UTC)
- Support makes sense to me. Ground Zero (talk) 06:46, 10 February 2025 (UTC)
- Yeah, I totally agree. I was actually unaware of this status. What does it do? Ikan Kekek (talk) 09:23, 10 February 2025 (UTC)
- Basically it allows us to manually give confirmed to users who aren't autoconfirmed for as long as it takes for that user in question to become autoconfirmed. A case-in-point is how Leaderboard's bot has confirmed permissions because it has yet to make at least 3 edits, but the moment it does, we would remove the permission. //shb (t | c | m) 10:42, 10 February 2025 (UTC)
- @SHB2000 Actually, confirmed status is unnecessary for a bot. Bots also have the ability to skip captcha and edit semi-protected pages. Leaderboard (talk) 12:21, 10 February 2025 (UTC)
- Okay yeah I suppose your bot was a bad example, but it would be useful for bots that are allowed to run without the bot flag. //shb (t | c | m) 12:26, 10 February 2025 (UTC)
- Indeed, and I Support the proposal regardless, even though this is a permission that's rarely needed in practice. Leaderboard (talk) 16:53, 10 February 2025 (UTC)
- Okay yeah I suppose your bot was a bad example, but it would be useful for bots that are allowed to run without the bot flag. //shb (t | c | m) 12:26, 10 February 2025 (UTC)
- @SHB2000 Actually, confirmed status is unnecessary for a bot. Bots also have the ability to skip captcha and edit semi-protected pages. Leaderboard (talk) 12:21, 10 February 2025 (UTC)
- Basically it allows us to manually give confirmed to users who aren't autoconfirmed for as long as it takes for that user in question to become autoconfirmed. A case-in-point is how Leaderboard's bot has confirmed permissions because it has yet to make at least 3 edits, but the moment it does, we would remove the permission. //shb (t | c | m) 10:42, 10 February 2025 (UTC)
- Yeah, I totally agree. I was actually unaware of this status. What does it do? Ikan Kekek (talk) 09:23, 10 February 2025 (UTC)
- Support Our admins are sensible, and this is a pretty low-risk user right. WhatamIdoing (talk) 16:40, 10 February 2025 (UTC)
- Support I would also like admins to be able to remove autoconfirmed from a user if they suspect a sleeping vandal. AlasdairW (talk) 21:26, 10 February 2025 (UTC)
- I don't think it's actually possible to remove autoconfirmed, technically speaking (unless it involves filters which becomes messy). //shb (t | c | m) 21:32, 10 February 2025 (UTC)
- Definitely – and all the more so when admins are allowed to assign higher-risk permissions but not what is possibly the most low-risk perm on this wiki. //shb (t | c | m) 06:35, 11 February 2025 (UTC)
- Given the consensus is clear, I will open the phab task sometime later today or tomorrow. //shb (t | c | m) 05:04, 13 February 2025 (UTC)
- Seems this has now been implemented. //shb (t | c | m) 10:44, 21 February 2025 (UTC)
- Given the consensus is clear, I will open the phab task sometime later today or tomorrow. //shb (t | c | m) 05:04, 13 February 2025 (UTC)
- Support I would also like admins to be able to remove autoconfirmed from a user if they suspect a sleeping vandal. AlasdairW (talk) 21:26, 10 February 2025 (UTC)