Use case	Search terms	Codesearch
Fetaure checks whether a user is registered	->isAnon, ->isRegistered, mw.user.isAnon, mw.user.getId, mw.user.getRegistration	search results
Feature checks a user name (possibly then checking if it is registered)	mw.user.getName, $user->getName, $user->getRealName	search results
IP address utility functions are imported/used (IP addresses may be found via an anonymous username)	use Wikimedia\IPUtils, mw.util.isIPAddress	search results
Feature renders a user name	::userLink, ::revUserLink, ::revUserTools	search results

Potentially affected repos, according to these searches:

Maintainers mostly as listed on https://www.mediawiki.org/wiki/Developers/Maintainers. In a very few cases, unowned repos have been assigned despite not being listed there, e.g. anti-vandalism extensions to AHT, Campaigns extension to the Campaigns Team, etc.

Tasks have been made for all of these - see subtasks of T326816: Update features for temporary accounts

• Work for WMF-owned products is delegated to the owning teams
• Work for unowned products is currently assigned to AHT

Other affected repos:

• MediaWiki core - To do: Investigate which teams own affected parts of MediaWiki core
• operations/mediawiki-config - To do: Does this config need to be updated?
• a couple of other obvious false positives e.g. vendor, etc.

It would be very helpful if, along with the list of "potentially bad" methods in codesearch, there was also documentation about what exactly should be done -- what methods should replace these, what patterns to look for, etc.

In T326759#8540545, @cscott wrote:

It would be very helpful if, along with the list of "potentially bad" methods in codesearch, there was also documentation about what exactly should be done -- what methods should replace these, what patterns to look for, etc.

Hi @cscott! It's honestly difficult to know all the ways in which various things will be affected, but the major one we've identified is that there are now three "types" of user, rather than two. Whether features need updating and how will depend on whether temporary account users should be treated the same as registered users, the same as anon users, or in a different way altogether. Feature owners should make those decisions (though we can help, and cross-team co-ordination may be needed with some things, and also there's a wealth of un-owned products that we're still trying to figure out how to approach...)

Examples of what should be done in some situations:

The equivalents in JavaScript don't seem to exist yet, but we're implementing them in T327317: Create a function that checks if the global session user is a temporary user in JS and T327888: Create a function that checks if a username is a temporary user in JS. (Please bear with us while we catch up! We didn't implement the temporary user accounts so we're figuring out as we go too.)

We included the other search terms in order to cast the net widely, to err on the side of finding cases rather than missing them.

• For mw.user.getName, $user->getName, $user->getRealName, we reason that any uses of these could be checking whether a user is registered via inspecting the name
• For use Wikimedia\IPUtils, mw.util.isIPAddress, we reason that the IP address may have been obtained via the user name (which will not be possible for temp accounts)
• For ::userLink, ::revUserLink, ::revUserTools, we reason that any feature that displays a user name may want to treat registered / temp / unregistered users differently.

Does that help at all?

MediaWiki core - To do: Investigate which teams own affected parts of MediaWiki core

There were lots of hits, some spurious, some fixed, and some that may need fixing. Here's a summary of places that may need fixing.

See T331637: Update features in MediaWiki core for IP Masking for all tasks.

Product questions

Some questions raised about those features that may need fixing, broken into: general questions that may need consistent answers throughout the software, features that are unowned according to https://www.mediawiki.org/wiki/Developers/Maintainers , and features that are owned by particular teams.

General questions

Questions about ownerless features, or general questions that span many features.

Preferences T330815: Disallow preference setting by temporary users

• Should the infrastructure (UserOptionsManager, UserOptionsLookup subclasses, etc) be updated to prevent preferences for temporary users?
• Should features that work via preferences (e.g. Mute, search form options, etc) be unavailable to temporary users?

Notifications

• Which notifications features should temporary users be able to access?

Uploading T331578: File upload defaults for Temporary account should match those for anon users

• Should this be available to temporary users?

Email T331579: Email defaults for Temporary account should match those for anon users

• Should this be available to temporary users?

User groups T330816: [Epic] Temporary users should not be assigned to user groups

• Should it be possible to assign temporary users to user groups?

Rate limits T331576: Rate limits for Temporary account should match those for anon users

• Rate limits are configured per user type. What rate limits should we apply to temporary users? (Same as anon? Same as logged in? A new category?)

Statistics T341228: Update action API to handle temporary users

• Where user edits are counted differently for different users (e.g. recent changes, ApiQueryContributors, ApiQueryUserInfo, etc), how should temporary users be counted?

API T341228: Update action API to handle temporary users

• Where APIs have a user parameter, should there be a separate type for temporary users? (See UserDef::PARAM_ALLOWED_USER_TYPES)
• Where APIs have an assert parameter, used to check the type of accessing user, should there be a separate type for temporary users?

Flags T341228: Update action API to handle temporary users

• Where different user types are flagged differently (some APIs, some logs), how should temporary users be flagged?

Team-specific questions

Questions of various sizes that I encountered while trawling through files. (Unlikely to be exhaustive, in that other teams' products in core may well be affected in ways not discovered here!)

Blocks (AHT) T338836: How should blocks treat temporary users?

• Should blocked IPs defined in DnsBlacklistUrls and SoftBlockRanges apply to temporary account users?
• Should it be possible to suppress a temporary account user? (It's not possible to suppress an IP user.)
• How should autoblocks work for temporary accounts? (Blocked on community consultation as commented here: T300294#8476287)
• If the "Apply block to logged-in users from this IP address" is unchecked, should it block temporary account users?
• Should BlockDisablesLogin prevent a user from making a temporary account?

Growth

• Should Watchlist be available to temporary users?

ContentTransform

• Should ParserOptions for temporary account users be the same as for anonymous users?

Yes - T337042: Temporary account users should have the same ParserOptions as anonymous users

Editing

• Should PageEditStash::checkCache treat temporary users like anon users?

No, it can stay as is.

Performance/Security

• Should Article::showMissingArticle omit logs for temporary users?

No, can stay as is.

Web

• Should ResourceLoaderClientPreferences be used for temporary users?

Technical fixes needed

Authentication T332411: Make some authentication APIs unavailable to temporary users

The following should be unavailable to temporary users:

• ApiChangeAuthenticationData
• ApiRemoveAuthenticationData
• ApiLinkAccount

Technical debt

• Fix some classes to be in sync with the User and Linker classes

Further investigations needed

UI messages T339874: Show more helpful messages when temporary users can't access features

• Various messages have separate versions to display to anonymous vs registered users. Which of these should also have versions for temporary users?

Special pages T344276: Should SpecialPages that return true for ::requireLogin allow access to temporary users?

• Special pages can specify that only logged-in users can use the special page (SpecialPage::requireLogin) - this currently allows temporary users. It's also possible to specify that only named (i.e. registered, non-temporary) users can user the page (SpecialPage::requireNamedUser). Some special pages may need updating to require named users. (Affects core and extensions.)