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

[mediawiki/extensions/CheckUser@master] Add preference to view temp account IPs

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

Also, should we be doing this? Is there some kind of need to log enabling this sort of like we did for IP Info?

I believe not for checkusers - @Niharika?

@STran Does this documentation help with this task? https://www.mediawiki.org/wiki/Manual:Hooks/GetPreferences#Default_preferences

After discussing with @Niharika , we're removing this from the MVP and may return to it later based on user feedback.

In T327061#8790110, @Tchanders wrote:

After discussing with @Niharika , we're removing this from the MVP and may return to it later based on user feedback.

This is definitely something that should be a part of the MVP. If I understand this correctly, if this task is not completed, everyone (including global and local functionaries) would have to check the preference option to gain access to IP masking data. If that is right, it would mean the Stewards would have to manually enable their access on Every Single Wiki (and we have over a thousand of them). Because of that, not completing this task would significantly disrupt the usability of the temporary account IP reveal interface for the Stewards, up to the point of making it virtually useless (it is not fair to assume Stewards to enable their access independently on all projects). This is the current state for IP Info (which behaves exactly like this), and while it is annoying, IP Info is not (given we still have undisturbed access to the IP data) a critical part of the Steward workflows. It would be very much problematic if the same approach was chosen for IP Masking.

Furthermore, I do not believe completing this task is technically challenging in any way. Currently, the checkuser-temporary-account user right is the only one that guards IP Masking data access, both for functionaries and other users with access. For users with this right assigned, a preference (false by default) appears in Special:Preferences, which can be then checked. What I believe was the considered implementation pathway for this task is splitting the preference's default value to be different per-user (I think so, because DefaultUserOptions was linked by Thalia). This would be indeed fairly challenging and likely error-prone.

Fortunately, splitting the preference defaults is not actually necessary to complete this. Introducing a second right, along the lines of checkuser-temporary-account-functionary, would solve this perfectly. When checking if an user has access to IP Masking data, has checkuser-temporary-account-functionary OR (has checkuser-temporary-account AND has preference) would be the condition to check. While it is slightly longer and more complex, it can be easily masked behind a separate class responsible for determining user access to IP Masking and then reused from any place where this logic is needed.

Last but not least, I'd like to suggest consulting the Stewards before making a decision that mostly affects the Stewards. We're happy to help AHT (or any other team) with making product decisions that are both acceptable/helpful for the Stewards while being reasonably easy to implement, but this is challenging to do if we're not consulted on the decisions. Unfortunately, this is not the first time when this happened (a random Steward stumbling upon a task that seems to present significant difficulties for the group). I believe T&S folks would be always happy to relay any question any WMF team has to the Stewards. We've also steward communication channels (some) staff are a part of, and requesting additional staff to be added is always an option.

In addition to what I mentioned above, the //Access to temporary account IP addresses policy// explicitly stipulates that "Access is automatically granted to users who are members of the steward and checkuser user groups", while admins and lower needs to opt-in (and agree to the policy). While this is a formal argument, not completing this task goes against the expectations stated in the relevant policy.