I think this needs to be a Community decision and should require more (public) discussion, so we should probably make this task public (there's nothing super-sensitive here IMO). Implementing this as an additional technical control should be fairly trivial, but there should already be a Community workflow control in place, if that is deemed appropriate.

In T356044#9495296, @sbassett wrote:

I think this needs to be a Community decision and should require more (public) discussion, so we should probably make this task public (there's nothing super-sensitive here IMO). Implementing this as an additional technical control should be fairly trivial, but there should already be a Community workflow control in place, if that is deemed appropriate.

Sure, as you wish.

@JJMC89, I do not understand your edit. It has no sence now.

I see now. You changed my words too, not just title. Itbrakes also the facts and my thoughts. I don't know why did you do this, but if you think the opposite of my suggestion, you can always create another task. I return my request back.

You're actually asking to restrict it to someone with the autopatrol right as opposed to the autoconfirmed user group?

If so, I'd decline the task since the two are used for unrelated purposes.

I suggest to restrict someone without autopatrol rights to get interface admin, because that means the local community does not trust them. Autoconfirmed is just automatic rights, not related to my suggestion.

A user having autopatrol does not mean they are "trusted". Having autopatrol simply means that someone thought their edits (or just page creations, depending on config) do not need to be patrolled, i.e., they write good content.

As an example, administrators on the English Wikipedia do not have autopatrol unless explicitly granted separately from sysop, but they are certainly trusted by the community. 2/8 of their (non-bot) interface admins do not have autopatrol.

I'm not talking about autopatrol group, but about autopatrol rights. The user's edits should not be manually patrolled. Sysops have this included for there group too.

In T356044#9495595, @IKhitron wrote:

Sysops have this included for there group too.

Not on the English Wikipedia.

It is also beside the point. autopatrol is not a measure of general trust. autopatrol is for one specific purpose.

You mean, each sysop's edit is patrolled by a human patroller? The page https://en.wikipedia.org/wiki/Special:ListGroupRights claims otherwise, see "Have one's own revisions automatically marked as "accepted"" in sysop chapter.

In T356044#9495659, @IKhitron wrote:

You mean, each sysop's edit is patrolled by a human patroller?

No, only page creations since the English Wikipedia doesn't use change patrol.

The page https://en.wikipedia.org/wiki/Special:ListGroupRights claims otherwise, see "Have one's own revisions automatically marked as "accepted"" in sysop chapter.

That is autoreview for Extension:FlaggedRevs, not autopatrol.

What do you mean by "autopatrol"? (in enwiki, to be more clear)

Because as far as I understand, not being a regular on enwiki, just from reading that page, autoreview and autopatrol are synonims. If they are not, I can always change the task title to be "Avoid the possibility to give the interface-admin rights to users without autopatrolled or autoreviewed rights", to fit both cases.

The autoreview and autopatrol rights are unrelated, not synonyms. Neither of them are a measure of general trust.

On the English Wikipedia, only bots and specific autopatrolled users have autopatrol while autoreview is given to autoconfirmed users allowing them to bypass Pending Changes protection ('weaker' than semiprotection) from Extension:FlaggedRevs. (autoreview serves a different purpose on wikis like dewiki that use the more standard FlaggedRevs configuration.)

Very well. Changing to "Avoid the possibility to give the interface-admin rights to users without autopatrolled or autoreviewed rights" will by OK for you? So that user must have at least one of these two.

I would still decline the task. Neither right is a measure of general trust, and neither one is necessary to be qualified or trusted as an interface admin.

Also, a core user group cannot depend on something defined in an extension.

In T356044#9495871, @JJMC89 wrote:

Also, a core user group cannot depend on something defined in an extension.

Our wiki has no extension, so I started with autopatrol, tbat everyone have.

In most WMF projects "autopatrol" is only in sysop, bot. I can't see why we would want to prevent a community from assigning someone this group if they want to without also making them one of those other groups. Additionally, the assertion that "everyone has" autopatrol is false. For example, see ruwiki. Not only do they have non-admin/non-bot intadmins, but they also do not have anygroup with autopatrol. dewiki is deprecating patrol as well (see T316393).

This is not a software security concern, and is not a globally supported default setting. Task should be declined.

In T356044#9587090, @Xaosflux wrote:

In most WMF projects "autopatrol" is only in sysop, bot. I can't see why we would want to prevent a community from assigning someone this group if they want to without also making them one of those other groups. Additionally, the assertion that "everyone has" autopatrol is false. For example, see ruwiki. Not only do they have non-admin/non-bot intadmins, but they also do not have anygroup with autopatrol. dewiki is deprecating patrol as well (see T316393).

This is not a software security concern, and is not a globally supported default setting. Task should be declined.

Once again, this word means different thing in different wikis, this is why I suggested to make it one of possibilities, depends on wiki. Please read the comments, @Xaosflux, before you suggesting to decline the task. You'll see you do need to be concerned.

There is no software security issuehere.

Conceptually if a project wants to add someone to a group that contains the default permissions that interface-administrator has while also wanting to not include them in some other group I can't see any reason why they shouldn't be allowed to.

Now if some project wanted to try to build some sort of warning system for this, they may be able to build a gadget that pops a warning (trivially able to be bypassed purposefully).

This is something else, of cource. For me, if some user can't be trasted to make their one edits in articles, they for sure can't be trusted to have an Interface admin flag, which was created just because the Foundation didn't think the admins (sic!) were trusted enough to have. You definitely can have different ipinion.

That sounds like a local community concern, which can be addressed by policies and procedures.

Note also that the largest WMF wiki (English Wikipedia) does have autopatrolled configured and specifically does not have the autopatrol permission bundled with their administrators group - having decided that being competent in one technical area doesn't necessarily mean you are good at authoring new content pages without review.

Well, I tried a couple of times to explain you it has nothing to do with all this, with new pages for example, only with any edit in any article. I can see no way to explain more.

A pity.