We intend to grant the ipinfo and ipinfo-view-basic rights by default to X

@Niharika: IIRC you said that X here was all logged-in users. Am I remembering correctly?

Edit: This is a question for another task. I'll ping you on it once it's written.

@phuedx that is correct.

Dumb question: why do you need a new group here?

In MediaWiki core and in all key extensions, the default choice is that "Bureaucrat" group is the one who assigns and revokes all other groups.

In WMF, this is often overridden (e.g. we have a custom "steward" group that can assign/revoke many other groups).

Point being: why not use Bureaucrat as the default assigner/revoker of IP Info related groups?

In T296085#7517937, @Huji wrote:

Dumb question: why do you need a new group here?

This isn't a dumb question.

In MediaWiki core and in all key extensions, the default choice is that "Bureaucrat" group is the one who assigns and revokes all other groups.

In WMF, this is often overridden (e.g. we have a custom "steward" group that can assign/revoke many other groups).

Point being: why not use Bureaucrat as the default assigner/revoker of IP Info related groups?

I'll happily admit to being a journeyman in MediaWiki's user rights and groups system (and the autopromote mechanism, and $wgAutoPromoteOnce!) but I think that in that scenario we still need to define a group that grants the ipinfo* rights, which bureaucrats can add users to/remove users from. We would be able to close T296186: Create a group that revokes all ipinfo* rights as Invalid though.

AIUI an alternative approach to creating a distinct group to grant basic ipinfo* rights, would be to assign them to pre-existing groups directly, e.g.

// See T292755
$wgGroupPermissions[ 'user' ] = 'ipinfo';
$wgGroupPermissions[ 'user' ] = 'ipinfo-view-basic';

foreach ( [ 'sysop', 'bureaucrat', 'checkuser', 'oversight', 'steward' ] as $group ] {
  $wgGroupPermissions[ $group ] = 'ipinfo-view-full';
}

I opted not to take this approach because I think that creating a separate group keeps things clearly separated. Regardless, we'd require T296186: Create a group that revokes all ipinfo* rights so that a user's access to the tool can be revoked (by whoever).

I'll defer to @Niharika to add detail about why the rights are being assigned to the groups outlined above and in T292755: Epic: IP Info access.

Then I guess you are not looking to create a group that "assigns" (or "revokes") the rights. You are looking to create a group that can be assigned/revoked from users, and the group would have the appropriate ipinfo* rights.

In other words...

$wgGroupPermissions[ 'ipinfo-all' ] = 'ipinfo';
$wgGroupPermissions[ 'ipinfo-viewer' ] = 'ipinfo-view-basic';

// $wgAddGroups['bureaucrat'] = true; // implied as the default setting
// $wgRemoveGroups['bureaucrat'] = true; // implied as the default setting

Which means bureaucrats can assign the ipinfo-all or ipinfo-viewer group to the desired user, or revoke these groups from the undesired user.

In T296085#7523151, @phuedx wrote:

[...]
I opted not to take this approach because I think that creating a separate group keeps things clearly separated.

Honestly, I'd prefer the "no new group" approach, as we've too many groups already (see https://analytics.wikimedia.org/published/datasets/one-off/urbanecm/humans-by-user-group/permanent-users-per-group.json for a list of all groups at all wikis). I'd focus on "roles" of the individual users rather than technical capabilities, if possible.

Regardless, we'd require T296186: Create a group that revokes all ipinfo* rights so that a user's access to the tool can be revoked (by whoever).

T296186: Create a group that revokes all ipinfo* rights should not actually be needed. If you use wgAutopromoteOnce, anyone who is able to remove the automatically granted group will be able to remove the right. MediaWiki will not attempt to grant it again. This is used with groups like extendedconfirmed at the English Wikipedia.

In T296085#7523548, @Urbanecm wrote:

In T296085#7523151, @phuedx wrote:

[...]
I opted not to take this approach because I think that creating a separate group keeps things clearly separated.

Honestly, I'd prefer the "no new group" approach, as we've too many groups already (see https://analytics.wikimedia.org/published/datasets/one-off/urbanecm/humans-by-user-group/permanent-users-per-group.json for a list of all groups at all wikis). I'd focus on "roles" of the individual users rather than technical capabilities, if possible.

404 Not Found but your point is taken.

Regardless, we'd require T296186: Create a group that revokes all ipinfo* rights so that a user's access to the tool can be revoked (by whoever).

T296186: Create a group that revokes all ipinfo* rights should not actually be needed. If you use wgAutopromoteOnce, anyone who is able to remove the automatically granted group will be able to remove the right. MediaWiki will not attempt to grant it again. This is used with groups like extendedconfirmed at the English Wikipedia.

AFAICT the autopromote once mechanism is currently only running when a user makes an edit. I understand that it can run when a logged in user views a page but is that acceptable from a performance perspective?

In T296085#7523510, @Huji wrote:

You are looking to create a group that can be assigned/revoked from users, and the group would have the appropriate ipinfo* rights.

Yes. I'll try to clarify the task description.

In T296085#7523833, @phuedx wrote:

In T296085#7523548, @Urbanecm wrote:

In T296085#7523151, @phuedx wrote:

[...]
I opted not to take this approach because I think that creating a separate group keeps things clearly separated.

Honestly, I'd prefer the "no new group" approach, as we've too many groups already (see https://analytics.wikimedia.org/published/datasets/one-off/urbanecm/humans-by-user-group/permanent-users-per-group.json for a list of all groups at all wikis). I'd focus on "roles" of the individual users rather than technical capabilities, if possible.

404 Not Found but your point is taken.

Sorry, the updating cron appears to think it can just delete the JSON files :). Fixed.

Regardless, we'd require T296186: Create a group that revokes all ipinfo* rights so that a user's access to the tool can be revoked (by whoever).

T296186: Create a group that revokes all ipinfo* rights should not actually be needed. If you use wgAutopromoteOnce, anyone who is able to remove the automatically granted group will be able to remove the right. MediaWiki will not attempt to grant it again. This is used with groups like extendedconfirmed at the English Wikipedia.

AFAICT the autopromote once mechanism is currently only running when a user makes an edit. I understand that it can run when a logged in user views a page but is that acceptable from a performance perspective?

Do we need to run it on a page view though? If the autopromotion conditions require a certain number of edits, then to satisfy the conditions, you need to make an edit. If the autopromotion is age-only, then an edit is not necessary strictly speaking, but I cannot imagine a scenario in which a zero-edit user or a few-edit user would need to access the IP info stuff. But maybe I'm missing something?

In T296085#7525927, @Urbanecm wrote:

Do we need to run it on a page view though? If the autopromotion conditions require a certain number of edits, then to satisfy the conditions, you need to make an edit. If the autopromotion is age-only, then an edit is not necessary strictly speaking, but I cannot imagine a scenario in which a zero-edit user or a few-edit user would need to access the IP info stuff. But maybe I'm missing something?

You're correct IMO. Thanks. @Niharika: Can you confirm that this is acceptable from a Product perspective?

In T296085#7526073, @phuedx wrote:

In T296085#7525927, @Urbanecm wrote:

Do we need to run it on a page view though? If the autopromotion conditions require a certain number of edits, then to satisfy the conditions, you need to make an edit. If the autopromotion is age-only, then an edit is not necessary strictly speaking, but I cannot imagine a scenario in which a zero-edit user or a few-edit user would need to access the IP info stuff. But maybe I'm missing something?

You're correct IMO. Thanks. @Niharika: Can you confirm that this is acceptable from a Product perspective?

This sounds acceptable. I agree with @Urbanecm brand new users probably don't need to access IP Info. We can autopromote users when they make their first edit for now and re-consider this in the future, as needed.

Moving to blocked until we figure out a deployment timeline

Change 766878 had a related patch set uploaded (by STran; author: STran):

[mediawiki/extensions/IPInfo@master] Add ipinfo group

https://gerrit.wikimedia.org/r/766878

Change 766878 merged by jenkins-bot:

[mediawiki/extensions/IPInfo@master] Add ipinfo-viewer user group

https://gerrit.wikimedia.org/r/766878

I see on my local and on beta that there is a new group called "IP info viewers" (in English).

You can see this in Special:ListGroupRights.

After granting a user that right, I checked they could enable IPInfo and then see IPInfo in the popup and Special:Contribs. The info appeared to be only the "basic" info (e.g. they couldn't see ASN).

You can see the list of users in this group by going to Special:ListUsers?group=ipinfo-viewer.

I believe that only bureaucrats can grant users this right. I was not able to grant it as any other type of user. Nor is it listed in an "Add group" in Special:ListGroupRights.

Test environments:

• local docker IP Info 0.0.0 (0f63a8b) 07:11, 7 March 2022.
• https://en.wikipedia.beta.wmflabs.org IP Info 0.0.0 (a0351d5) 18:08, 4 March 2022.

In T296085#7523833, @phuedx wrote:

AFAICT the autopromote once mechanism is currently only running when a user makes an edit. I understand that it can run when a logged in user views a page but is that acceptable from a performance perspective?

@Niharika is looking into whether we can use the 'onView' mechanism for autopromote once.

However, as @phuedx mentions, it doesn't appear that we currently use this on production. @Krinkle have we intentionally avoided using autopromote once on page view due to performance concerns?

In T296085#7756986, @dom_walden wrote:

[...]
I believe that only bureaucrats can grant users this right. I was not able to grant it as any other type of user. Nor is it listed in an "Add group" in Special:ListGroupRights.

If it's not listed anywhere under "Add group" (which matches patch uploaded), then only people with either the userrights or the userrights-interwiki permission can add/remove the group. In Wikimedia's environment, that means (mainly) the Wikimedia Stewards. Bureaucrats have that right by default in MediaWiki, but Wikimedia wikis override that default configuration, as we give bureaucrats a different role.