Note once IP Masking is deployed there will be three classes of users to differ: named users, temporary users and anonymous users that yet to have edits on the project.

Adding some context behind the ticket:

Until recently, the rights=purge filter in gadget definitions was a popular/infamous hack for restricting default gadgets to logged-in users. This broke with T291316 that made the purge right available to IPs as well.

In T291316#9278652, @daniel wrote:

Ah, I was unaware of this mechansim in Gadgets. Thank you for the explanation.

If the intent is to load the gadget for registered users, perhaps it would be best to introduce a groups parameter for the gadget definition.

In T291316#9279294, @gerritbot wrote:

Change 968633 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/extensions/Gadgets@master] Experiment: introduce groups parameter

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

In T291316#9279296, @daniel wrote:

I made a patch that allows groups to be specified in a gadget definition, e.g.

*bar[ResourceLoader|groups=autoconfirmed,sysop]|bar.js'

Someone (tm) would need to approve this approach from a product perspective. Who owns the Gadgets extension these days, anyway?

In T291316#9281157, @Izno wrote:

In T291316#9279296, @daniel wrote:

I made a patch that allows groups to be specified in a gadget definition, e.g.

*bar[ResourceLoader|groups=autoconfirmed,sysop]|bar.js'

I think generally |rights= is a bit more flexible if a bit less intentional. In some cases anyway, since it can more intentionally say "I don't care who has this right" since sometimes rights are allocated to more than one group. And at this point in time, I wouldn't personally want to add another axis of customization that is as similar as it is to an existing one. I'm sure this question was discussed around the time that |rights was originally discussed too, but that's history now and I don't want to dig. :)

I think mostly you just got unlucky and happened to pick the right to adjust/fix that we had settled on informally to indicate "registered users". If I take look at Special:ListGroupRights I see a few others that could also potentially use in user, I'm just not sure which is most stable for the moment. Probably (view|edit)mywatchlist has the least likelihood of being removed or reframed into multiple rights or having this task happen again, as well as being a right provided in the default installation and not likely to be removed from the group to be added to some sort of "extended user" group?

I hadn't gotten around to looking at that list before I commented earlier, but that list is why I said that I'm pretty sure a User-notice about this change would be an acceptable outcome instead of adjustment of the extension (whether supporting |rights=purge or adding something like your |groups). A global interface editor could change all the definitions everywhere regarding User-notice or individual wikis can take care of themselves, etc. etc.

Someone (tm) would need to approve this approach from a product perspective. Who owns the Gadgets extension these days, anyway?

No one owns it according to https://www.mediawiki.org/wiki/Developers/Maintainers . That one lists a few names as individual maintainers (from WMF folk in that list, I think @Krinkle has been the most responsive on the Phab project).

Change 968633 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/extensions/Gadgets@master] Experiment: introduce groups parameter

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

MediaWiki has always permitted anyone to do the "purge" action, including unregistered users. The unused "purge" right was removed from the software two weeks ago, and that meant rights=purge now correctly matches all users (details at T291316#9281771).

I used my global interface-admin rights to remove rights=purge from over 100 HotCat definitions on various wikis, where it was used on a non-default gadget, and thus didn't actually do anything, since only logged-in users can enable non-default gadgets in the first place.

This leaves us with, across a thousand WMF wikis and many thousands more gadgets, a mere ~50 gadgets that use rights=purge as a hack to enable a gadget by default for logged-in users only.

https://global-search.toolforge.org/?namespaces=8&q=rights[%20%2C%3Da-z]%2Bpurge&regex=1&title=Gadgets-definition

Of these 50, about 30 are copies of geonotice and other watchlist-related gadgets. There is an appropiate user right for those already, namely viewmywatchlist, so I've updated those to use those instead.

That leaves us with about ~20. Of these several enhance action=history with RC information fetched from the API. These queries return the empty set unless you also have the patrolmarks right. I've fixed these to use that user right instead, and in doing so also made pages faster by not loading this code for most logged-in users.

There were also several gadgets that add buttons within the "Advanced" section of the WikiEditor toolbar on the action=edit, behind a collapsed-by-default button "Advanced". This section exists by default, but these gadgets would add additional buttons to them. I suspect these were either restricted as crude performance reasons (compromising between giving editors the option to find local wiki conventions and improving page load time), or were predate the current way WikiEditor works (eg. from a time where these edittools were dumped underneath the textarea directly, which is no longer the case, and no longer has that potentially confusing effect on new users). I removed the redundant rights=purge filter from these and limited them to actions=edit instead.

That left us with 13. Of these:

• 6 wikis enabled "purgetab" for logged-in users (mw:Snippets/Purge_action): fa.wikinews, fa.wikivoyage, it.wikisource, ps.wikivoyage, vec.wikisource, www.wikidata.
• 5 wikis enabled "HotCat" for logged-in users: ge.wikimedia, hy.wikipedia, or.wikipedia, pa.wikipedia, pnb.wikipedia.
• 2 wikis enabled Prosesize for logged-in users: hi.wikipedia, hi.wikisource.

Regarding "purgetab", this seems very much a power feature that anons and new users alike are not likely helped by during their first few days/edits on the wiki. See also T56902: Deprecate and remove the purge action from MediaWiki about how this should generally very rare for end-users. I haven't done this yet, but I would recommend limiting these to autoconfirmed instead. Note that the vast majority of users are on wikis where no such gadget is enabled by default either way. Among the smaller communities, default settings tend to lean towards the small group of admins and their shared preferences. Switching this to autoconfirmed should make no difference in practice.

For HotCat, I suspect these are the wikis that copied HotCat from another wiki where it happened to be in this hacky state. The vast majority of wikis that have HotCat installed either enable it for everyone or leave it opt-in. Enabling a gadget only when logged-in but otherwise literally everyone seems odd to me, as it either disempowers anonymous users, or overestimates how useful and familiar a power tool is to new users. These could trivially be accomodated with any random user right that only logged-in users have if that's truly what these communities want, but given how widely used HotCat is, I imagine these communities might also welcome it being enabled for anons. They may also very well not even know or understand that they copied this restriction when they originally installed the gadget all those years ago.

For Prosesize, this was temporarily enabled for logged-in users in June for a contest in which it the size of articles played a role in the reward (contest page). That contest has since ended.

Conclusion

1. This hack was almost excusively misused (>99% of cases), such that it:

• had no effect,
• or was chosen poorly/lazily as proxy for a different user right that should have been chosen instead. My guess is, given the state of some of those wikis, likely rights is not well understood as a Gadget option, and local admins perhaps only saw examples of rights=purge and copied it because it approximated what they wanted. For example, the watchlist- and patrol-related gadgets are like this. This is the wiki way!
• or chosen soley as performance optimisation (e.g. editor toolbar compromise), where significantly better alternatives are available that most wikis already knew how to use, and in other cases have now been applied by me.

2. Hypothetically, while I see no gadgets in existence today that are enabled by default and make sense (to me) to be enabled for all users (including new sign ups) and yet not be enabled for anons, I guess theoretically this could be a use case in the future. For this, the current hack seems to suffice. Although per the above, it seems very unlikely to me that a gadget really has no more specific user right it should restrict by.

3. With the upcoming introduction of "Temp users", this will become even more tricky. Having gadget suddenly enable themselves after the first edit attempt may be surprising. Making this work correctly is ambigious and requires judgement on a case-by-case basis. A more sustainable outcome, for new gadgets that face this choice, is imho to either make it work well for anons as well, or choose a more specific user right, or make it opt-in.

4. If people want a boolean option that resembles "is registered" (i.e. not a temp user), I think a patch for that would be welcome!

In that case, I would suggest emphasizing in the documentation that options like actions/namespaces/contentmodels are encouraged instead for more precise filtering to ensure a more equitable experience for everyone, or to use more precise rights, or to leave it off by default if it's not helpful to most users.

This last point is important because adding a rights restriction means nobody else can enabled the gadget! We must not encourage performance optimisations that lead to regression in equity. It allows nobody else to opt-in!

I don’t think autoconfirmed is a good right to restrict gadgets to: if a gadget is restricted to purge or any other right users have immediately after registration, it gets enabled on explicit user action (pressing the register button), while if it’s tied to autoconfirmed status, it happens later, out of the blue.

Also, more things change in the interface immediately after registration (other changes include: many new options in the personal menu, watchlist stars, minor edit and watchlist checkboxes in the edit form, etc.) than when getting autoconfirmed (I think the only interface changes – as opposed to behavior changes – are the move tab and the upload item in the left-hand menu).

And, finally, tying it to the autoconfirmed status is also a regression in equity. Not all non-autoconfirmed users are newbies; they may have much experience on non-WMF wikis or even on another WMF wiki (autoconfirmed status is per-wiki, so a Commons admin may not even be autoconfirmed on Meta if they haven’t edited there yet, especially since T211188). On the other hand, it looks like logged-out users are treated as readers who don’t edit (at least hiding he sidebar on Vector 2022 communicates this), so not providing them editing tools may make sense.

I haven't done this yet, but I would recommend limiting these to autoconfirmed instead

The "autoconfirmed" right by itself is a hack: it's a proxy for a group membership, not a permission as such. The fact that it exists indicates that we do have a need to change behavior based on membership in the autoconfirmed group.

In T349792#9290872, @daniel wrote:

I haven't done this yet, but I would recommend limiting these to autoconfirmed instead

The "autoconfirmed" right by itself is a hack: it's a proxy for a group membership, not a permission as such. The fact that it exists indicates that we do have a need to change behavior based on membership in the autoconfirmed group.

I disagree. Groups are entirely a site configuration concept. They can be redefined in any way the site sees fit.

The autoconfirmed right is imho not an exception but in fact proves the point:

• The core software only refers to the right, i.e. User::isNewbie = () => $this->isAllowed( 'autoconfirmed' ). And similarly, this right is referred to from various abuse filters as well.
• The right is granted to multiple groups. On WMF wikis, it is typically granted to the two local "autoconfirmed" and the "confirmed" groups (the latter you can be asked to be added to, metawiki process, enwiki process), and like the example in my previous comment, this right is also granted to various global groups such as Global interface editors, Global sysops, and Global bots.

In T349792#9289204, @Tacsipacsi wrote:

I don’t think autoconfirmed is a good right to restrict gadgets to: […], tying it to the autoconfirmed status is also a regression in equity. […]

Also, more things change in the interface immediately after registration […] than when getting autoconfirmed […]

That's a good point yeah. As I mentioned, adding an option for loggedin or usertype=registered seems fine by me. Those are stable concepts in the platform, and if there's a good use case for them, by all means, that makes a ton of sense to me.

In addition to the instability, correctness, and equitity issues with groups, using groups would also pose portability issues in that it means copying/exporting gadget definitions becomes rather unstable. It encourages coupling in a way we've managed to avoid for nearly twenty years.

Those are stable concepts in the platform

Once IP Masking is enabled any anonymous users will become registered on their first edit. only "named" user is a stable concept.

Looking at my example list of use cases in the original ticket...

• watchlist-notice - can just do rights=viewmywatchlist, doesn't need this feature
• WatchlistGreenIndicators - can just do rights=viewmywatchlist, doesn't need this feature
• WatchlistGreenIndicatorsMono - can just do rights=viewmywatchlist, doesn't need this feature
• geonotice - can just do rights=viewmywatchlist, doesn't need this feature

Here's the remaining ones...

• SubtleUpdatemarker - displays some extra info at ?action=history (Special:PageHistory)
• HotCat - edits pages to add a category

For these two, what makes the most sense? isNamedUser, isNotIP, or an existing right? Whatever answer we decide for these is probably what this feature request should become. (If it's still worth doing this feature request for 2 use cases instead of 6)

In T349792#9293955, @Novem_Linguae wrote:

[…]

• WatchlistGreenIndicators - can just do rights=viewmywatchlist, doesn't need this feature
• WatchlistGreenIndicatorsMono - can just do rights=viewmywatchlist, doesn't need this feature

Here's the remaining ones...

• SubtleUpdatemarker - displays some extra info at ?action=history (Special:PageHistory)

[…]

@Novem_Linguae The SubtleUpdatemarker gadget enhances the marker that outputs the watchlist notification timestamp. While not on Special:Watchlist this is part, this is part of the Watchlist feature. Similar to how the "Watchstar" icon on page views, and "Watch this page" checkbox on action=edit, are also part of the Watchlist feature. I believe these are all guarded by the same viewmywatchlist user right, and can only show information or contain data for accounts having that user right.

HistoryPager.php in MediaWiki calls WatchlistManager->getTitleNotificationTimestamp which in turn retrieves watchlist.wl_notificationtimestamp from the database.

/cc @Izno in relation to this diff.

On the broader question, I'm pretty much still on my previously stated "not worth the complexity and user confusion and loss of emergent behavioral support for global groups" to add user group selection. And for having some sort of easy "unregistered, unnamed, or named" check, I think if all we're supporting on English WP (and several others I suspect) is the 1 gadget, we're not winning anything either for the additional complexity when there are other sufficient rights that can be used as a "work around". (And I hesitate to use the word "work around", because that would be me acknowledging it as such, when I don't really think it is -- it's not a bug we're dealing with, just an edge case outcome to the original decision to use user rights.)

/cc @Izno in relation to this diff.

Yeah, kind of makes it a Gadget-WatchlistOnHistoryPages.css but that's a lot more effort. :)

Change 968633 abandoned by Daniel Kinzler:

[mediawiki/extensions/Gadgets@master] Experiment: introduce groups parameter

Reason:

nvm

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