Change Details

Special:GlobalContributions caches its external permissions lookups because they're expensive but necessary. This cached value relies on being invalidated if the user ever gains or losses permissions in order to ensure that if the permission can affect their lookup permissions, Special:GC will accurately reflect that. The only way to programmatically declare this invalidation is on user group change (local and global). However, rights can be added/removed to groups via config and if a relevant right is added/removed this way, the cache invalidation has no way of seeing this. The only protection against this drift is policy and institutional knowledge not to do the thing. If policy changes or a config changes, we need to decide and document: 1. what to do preemptively (eg. in case of policy change and we have time to prepare) 2. what to do reactively (eg. in case of a config change we need to respond to) Acceptance Criteria: - [] recovery plan exists and is documented somewhere we can find - [] where reasonable in config files, a note referring back to this task asks people be careful when dealing with the relevant rights

==== Background Special:GlobalContributions permissions checks assume that the groups with IP reveal rights never change. This is currently the case according to the [[ https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Access_to_Temporary_Account_IP_Addresses_Policy | IP reveal access policy ]]. If the policy ever changes, then more technical work is needed in order to keep Special:GlobalContributions permissions check accurate. ==== Technical notes Special:GlobalContributions caches its external permissions lookups because they're expensive but necessary. This cached value relies on being invalidated if the user ever gains or losses permissions in order to ensure that if the permission can affect their lookup permissions, Special:GC will accurately reflect that. The only way to programmatically declare this invalidation is on user group change (local and global). However, rights can be added/removed to groups via config and if a relevant right is added/removed this way, the cache invalidation has no way of seeing this. The only protection against this drift is policy and institutional knowledge not to do the thing. If policy changes or a config changes, we need to decide and document: 1. what to do preemptively (eg. in case of policy change and we have time to prepare) 2. what to do reactively (eg. in case of a config change we need to respond to) ==== Acceptance Criteria - [] recovery plan exists and is documented somewhere we can find - [] where reasonable in config files, a note referring back to this task asks people be careful when dealing with the relevant rights

==== Background Special:GlobalContributions permissions checks assume that the groups with IP reveal rights never change. This is currently the case according to the [[ https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Access_to_Temporary_Account_IP_Addresses_Policy | IP reveal access policy ]]. If the policy ever changes, then more technical work is needed in order to keep Special:GlobalContributions permissions check accurate. ==== Technical notes Special:GlobalContributions caches its external permissions lookups because they're expensive but necessary. This cached value relies on being invalidated if the user ever gains or losses permissions in order to ensure that if the permission can affect their lookup permissions, Special:GC will accurately reflect that. The only way to programmatically declare this invalidation is on user group change (local and global). However, rights can be added/removed to groups via config and if a relevant right is added/removed this way, the cache invalidation has no way of seeing this. The only protection against this drift is policy and institutional knowledge not to do the thing. If policy changes or a config changes, we need to decide and document: 1. what to do preemptively (eg. in case of policy change and we have time to prepare) 2. what to do reactively (eg. in case of a config change we need to respond to) ==== Acceptance Criteria: - [] recovery plan exists and is documented somewhere we can find - [] where reasonable in config files, a note referring back to this task asks people be careful when dealing with the relevant rights