rEGUP includes/GlobalUserPage.php uses two methods of the ones listed in T326759:

• User::getName() – it just uses it as a cache key, doesn’t make any assumptions about whether it refers to a named or a temp user; should be okay.
• IPUtils::isIPAddress() – performance optimization: anons cannot have global accounts and thus global user pages. The question is whether temp users can have global user pages.
  • If they can, this should be left as-is.
  • If they can’t, but they can have global accounts, it should be updated to reject temp accounts as well.
  • If they can’t have global accounts either, it’s safe to leave it as-is, but updating it to reject temp accounts would save some DB queries.

In T326920#9881772, @Tacsipacsi wrote:

Thank you for your notes, @Tacsipacsi !

The question is whether temp users can have global user pages.

• If they can, this should be left as-is.

@Niharika this is a product specification question. I would say "yes", they should be able to have global user pages, given that temp accounts can exist across projects.

In T326920#10539193, @kostajh wrote:

In T326920#9881772, @Tacsipacsi wrote:

Thank you for your notes, @Tacsipacsi !

The question is whether temp users can have global user pages.

• If they can, this should be left as-is.

@Niharika this is a product specification question. I would say "yes", they should be able to have global user pages, given that temp accounts can exist across projects.

I would advocate for the opposite. We do not link to the user page of a temporary account in the UI, instead linking the contributions page. As such, I don't see why a temporary account would be linked to their user page to create it. Plus, a temporary account expiring after 90 days means that the global user page would disappear after 90 days for that user too.

In T326920#10605966, @Dreamy_Jazz wrote:

In T326920#10539193, @kostajh wrote:

In T326920#9881772, @Tacsipacsi wrote:

Thank you for your notes, @Tacsipacsi !

The question is whether temp users can have global user pages.

• If they can, this should be left as-is.

@Niharika this is a product specification question. I would say "yes", they should be able to have global user pages, given that temp accounts can exist across projects.

I would advocate for the opposite. We do not link to the user page of a temporary account in the UI, instead linking the contributions page. As such, I don't see why a temporary account would be linked to their user page to create it. Plus, a temporary account expiring after 90 days means that the global user page would disappear after 90 days for that user too.

I agree with this. It doesn't make sense to let temporary accounts claim user pages or global user pages.

In T326920#10612845, @Niharika wrote:

It doesn't make sense to let temporary accounts claim user pages

Please note that IP users can have local user pages, so I think temp accounts should also be able to have local user pages for consistency, even if they’re of limited use (they are somewhat hidden, but not unreachable – for example, clicking on the talk page link and then the User page tab brings there).

or global user pages.

On the other hand, IP users cannot have global user pages, so not enabling them for temp users either makes sense (even though the contrary would also make sense – I don’t have a strong opinion on the matter).

In T326920#10614341, @Tacsipacsi wrote:

In T326920#10612845, @Niharika wrote:

It doesn't make sense to let temporary accounts claim user pages

Please note that IP users can have local user pages, so I think temp accounts should also be able to have local user pages for consistency, even if they’re of limited use (they are somewhat hidden, but not unreachable – for example, clicking on the talk page link and then the User page tab brings there).

or global user pages.

On the other hand, IP users cannot have global user pages, so not enabling them for temp users either makes sense (even though the contrary would also make sense – I don’t have a strong opinion on the matter).

Supporting local user pages does make some sense, for example sock blocks where the temporary account has a tag on their user page. I'm not sure that any use-case I can think of would apply to global user pages. It's been my experience that IP user pages are only ever created by a registered user to indicate abuse.

In T326920#10614384, @Dreamy_Jazz wrote:

Supporting local user pages does make some sense, for example sock blocks where the temporary account has a tag on their user page.

That’s actually a use case for global user pages as well: if the user has been global-blocked, the tag applies globally.

In T326920#10614606, @Tacsipacsi wrote:

In T326920#10614384, @Dreamy_Jazz wrote:

Supporting local user pages does make some sense, for example sock blocks where the temporary account has a tag on their user page.

That’s actually a use case for global user pages as well: if the user has been global-blocked, the tag applies globally.

Are there examples of this on WMF wikis? I've not seen global user pages be used for this for normal accounts (when I've been reporting users for global locks).

It's been my experience that IP user pages are only ever created by a registered user to indicate abuse.

This example is probably only on my mind because I saw it fairly recently, but https://en.wikipedia.org/wiki/User:135.180.130.195 is an example of a userpage for an IP address that’s been built by (someone editing from) the IP address itself, rather than being created by someone else for anti-abuse purposes.

That said, I feel like I also don’t really have a strong opinion on the matter of whether global user pages should be enabled for temporary accounts. (As another idea to throw into the mix, if there are arguments both for and against temp accounts being able to have global user pages, maybe the option to enable/disable global user pages for temporary accounts could be added as a config variable?)

In T326920#10614632, @Dreamy_Jazz wrote:

Are there examples of this on WMF wikis? I've not seen global user pages be used for this for normal accounts (when I've been reporting users for global locks).

I don’t have any examples at hand, it just feels logical that if this is done for local blocks, it could be done for global ones as well (if the person imposing the global block feels like that, has time etc.).

Change #1143812 had a related patch set uploaded (by Máté Szabó; author: Máté Szabó):

[mediawiki/extensions/GlobalUserPage@master] Introduce GlobalUserPageManager service

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

Change #1143813 had a related patch set uploaded (by Máté Szabó; author: Máté Szabó):

[mediawiki/extensions/GlobalUserPage@master] Don't allow temporary accounts to have global userpages

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

Change #1143814 had a related patch set uploaded (by Máté Szabó; author: Máté Szabó):

[mediawiki/extensions/GlobalUserPage@master] Simplify logic in GlobalUserPageManager

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

Change #1143812 merged by jenkins-bot:

[mediawiki/extensions/GlobalUserPage@master] Introduce GlobalUserPageManager service

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

Change #1143813 merged by jenkins-bot:

[mediawiki/extensions/GlobalUserPage@master] Don't allow temporary accounts to have global userpages

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

Change #1143814 merged by jenkins-bot:

[mediawiki/extensions/GlobalUserPage@master] Simplify logic in GlobalUserPageManager

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

QA Notes

1. To test this ticket, you need a multi-wiki setup with CentralAuth.
2. Load and configure the GlobalUserPage extension to point to one of your wikis:

wfLoadExtension( 'GlobalUserPage' );
// update DB name and URL to reflect local setup
$wgGlobalUserPageDBname = 'metawiki';
$wgGlobalUserPageAPIUrl = 'https://metawiki.wmf.home.arpa/w/api.php';

1. Verify that if a global user page exists for a named user on the configured wiki, nonexistent user pages for that user show the rendered content of that page.
2. Verify that temporary accounts and IP users cannot have such global user pages.

I can confirm T326920#10811851 on beta.