When AbuseFilter prevents a user from creating an account, it is currently impossible for CUs to associated the IP and the user. Here is in example: * IP 1.2.3.4 tries to created the account User:FailedToCreate and this action is prevented by the abuse filter. * If you query 1.2.3.4, you will see this in the CU results * But of course, you don't know which IP to query. * If you query FailedToCreate you get an error saying the account doesn't exist (which is fair) * Without the abusefilter-private right, you have no way to associate FailedToCreate and 1.2.3.4 to each other. WMF has not given the `abusefilter-private` right to its CUs, because if a CU had that right and would use it to lookup the IP of a user associated with this type of abuse log entry, there would be no way to log the CU's action. WMF would like all CU actions to be logged, so other CUs can monitor it. Steps involved: [x] Make it possible to log the retrieval of private details of AbuseLog entries (T152934) [x] Set `$wgAbuseFilterPrivateLog` to true [x] Ensure the new entries in `logging` table are not replicated into the public dumps, and are filtered out of the #cloud-services (or does that happen automatically?) - T187455 [x] Schedule `maintenance/purgeOldLogIPData.php` to be run daily [x] Get legal to sign off on this task [ ] Basic documentation [ ] Final sign off from SuSa/WMF [ ] Add the `abusefilter-private` and `abusefilter-private-log` rights to the set of rights held by the `checkuser` group [ ] Add the `abusefilter-private` and `abusefilter-private-log` rights to the set of rights held by the `ombudsmen` group [ ] Add the `abusefilter-private-log` right to the set of rights held by the `steward` group

When AbuseFilter prevents a user from creating an account, it is currently impossible for CUs to associated the IP and the user. Here is in example: * IP 1.2.3.4 tries to created the account User:FailedToCreate and this action is prevented by the abuse filter. * If you query 1.2.3.4, you will see this in the CU results * But of course, you don't know which IP to query. * If you query FailedToCreate you get an error saying the account doesn't exist (which is fair) * Without the abusefilter-private right, you have no way to associate FailedToCreate and 1.2.3.4 to each other. WMF has not given the `abusefilter-private` right to its CUs, because if a CU had that right and would use it to lookup the IP of a user associated with this type of abuse log entry, there would be no way to log the CU's action. WMF would like all CU actions to be logged, so other CUs can monitor it. Steps involved: [x] Make it possible to log the retrieval of private details of AbuseLog entries (T152934) [x] Set `$wgAbuseFilterPrivateLog` to true [x] Ensure the new entries in `logging` table are not replicated into the public dumps, and are filtered out of the #cloud-services (or does that happen automatically?) - T187455 [x] Schedule `maintenance/purgeOldLogIPData.php` to be run daily [x] Get legal to sign off on this task [x] Basic documentation [ ] Final sign off from SuSa/WMF [ ] Add the `abusefilter-private` and `abusefilter-private-log` rights to the set of rights held by the `checkuser` group [ ] Add the `abusefilter-private` and `abusefilter-private-log` rights to the set of rights held by the `ombudsmen` group [ ] Add the `abusefilter-private-log` right to the set of rights held by the `steward` group

When AbuseFilter prevents a user from creating an account, it is currently impossible for CUs to associated the IP and the user. Here is in example: * IP 1.2.3.4 tries to created the account User:FailedToCreate and this action is prevented by the abuse filter. * If you query 1.2.3.4, you will see this in the CU results * But of course, you don't know which IP to query. * If you query FailedToCreate you get an error saying the account doesn't exist (which is fair) * Without the abusefilter-private right, you have no way to associate FailedToCreate and 1.2.3.4 to each other. WMF has not given the `abusefilter-private` right to its CUs, because if a CU had that right and would use it to lookup the IP of a user associated with this type of abuse log entry, there would be no way to log the CU's action. WMF would like all CU actions to be logged, so other CUs can monitor it. Steps involved: [x] Make it possible to log the retrieval of private details of AbuseLog entries (T152934) [x] Set `$wgAbuseFilterPrivateLog` to true [x] Ensure the new entries in `logging` table are not replicated into the public dumps, and are filtered out of the #cloud-services (or does that happen automatically?) - T187455 [x] Schedule `maintenance/purgeOldLogIPData.php` to be run daily [x] Get legal to sign off on this task [ x] Basic documentation [ ] Final sign off from SuSa/WMF [ ] Add the `abusefilter-private` and `abusefilter-private-log` rights to the set of rights held by the `checkuser` group [ ] Add the `abusefilter-private` and `abusefilter-private-log` rights to the set of rights held by the `ombudsmen` group [ ] Add the `abusefilter-private-log` right to the set of rights held by the `steward` group