Summary
After Temporary Accounts go into effect, we want to make sure that users who need IP address access to patrol effectively are able to do so. This task articulates the workflow for non-advanced right holders to get access.
Background
- This task is about granting temporary accounts IP-viewing privileges to users who do not qualify for automatic access per the current policy.
- Global access and Local access to checkusers, oversighters, admins and bureaucrats has been previously implemented in other tasks. This task is not for that.
User story
As an Admin or Steward, I want to know if a user meets the criteria for gaining access to view IPs, so that I can successfully evaluate a request and grant access.
Specifications
- How should it look? (design)
- What should it do when used correctly? (workflows)
- What should it do when used incorrectly? (workflows)
Design
| Scenario | Mockup |
|---|---|
| User meets access criteria |  |
| User does not meet access criteria |  |
Workflow 1: Access granting
- Users not holding these advanced rights but needing access to IPs for anti-vandalism purposes will be able to get this access through a community-defined process that grants them the right to view temp accounts IPs.
- Through a community-maintained page on wiki, a user can request access to view IPs with a legitimate reason for doing so.
- How do permissions work? (local groups, global groups)
- An admin or a steward can evaluate this request and grant access to the user through Special:UserRights.
- Admins can evaluate and grant access on their own wiki.
- Stewards can evaluate and grant access on any individual wikis (not global access).
- The user has to meet the following basic criterion for obtaining this access:
- A minimum of 300-edits on the project
- A minimum of 6-months old account
- If either of the above criteria is not met, the user cannot be granted the right to view IPs.
- If both of these criteria are met and the user is successfully granted the permission to view IPs, they will be able to go to Special:Preferences and opt-in to viewing IPs after agreeing to the terms of use
- A user who does not have the right to opt-in to viewing IPs will not see the preference in their Special:Preferences (as opposed to a disabled preference in accordance with Codex guidelines)
- The IP reveal right cannot be assigned to any existing groups.
- This is to reduce the amount of risk associated with IP reveal right. We would like for those who have this right to have specifically requested it and understood the risks and responsibilities that come with having access to personally identifying information.
Workflow 2: Access revocation
- Admins can revoke access locally from users through Special:UserRights
- Stewards can revoke access from everybody (status quo)
Logs
- Logs:
- Does this need logs?
- Where should logs go?
- Who needs to see the logs?
- Do logs need to be retained?
- How should metrics work: what needs to be measured, and why?
No additional logging or metrics needed for this feature beyond what is captured in T325658.
Technical notes
While figuring out how to do this, we should assume that what we build may also need to allow an exemption to checking the thresholds, for certain groups granting the global group: T389808: Allow stewards to assign IP Reveal to cross-wiki patrollers who do not meet the thresholds defined for technical enforcement.
Acceptance criteria
Identify how we will know the task is done. Make these checkboxes specific, so that QA can meaningfully review completion.
- Implement the access granting and revocation workflows as described above (see the specifications section)