Summary

The AbuseFilter protected variables access log debounces logs, but fails to do this if the target has a space in their username. This also occurs in the CheckUser implementation of the logging.

Background

• The AbuseFilter extension debounces logs related to viewing the value of protected variables for a given target user
• This log debounces based on checking if an associated logging row already exists
  • However, this check does not properly format the target username into a DB form
  • This leads to the check always failing if the username includes a space
• CheckUser overrides the logging to put the logs in the same place as other IP reveal logs, and the associated code has the same problem

Steps to reproduce

1. Either:
   1. When testing the AbuseFilter part of the bug: Make sure that CheckUser is not installed, and if it is installed then temporarily uninstall it (commenting out wfLoadExtension( 'CheckUser' ); is enough for this step)
   2. When testing the CheckUser part of the bug: Make sure that CheckUser and AbuseFilter are installed
2. Modify your temporary account creation config to include spaces in the username. For example, temporarily set $wgAutoCreateTempUser['genPattern'] = "~ $1";
3. Create a test AbuseFilter where the filter includes the user_unnamed_ip variable such that it matches against edits made by temporary accounts on your wiki. For example, something like user_unnamed_ip = '172.20.0.1' for a local wiki
4. Make a test edit using a temporary account that should cause a log entry for a match against the filter from step 2
5. Open an account which can view protected variables and navigate to the Special:AbuseLog page
6. Press details for the log entry created by the edit in step 3
7. Refresh the page a couple of times
8. Either:
   1. When testing AbuseFilter: Go to Special:Log and filter for the "Abuse filter protected variables log" type
   2. When testing CheckUser: Go to Special:Log and filter for the "Checkuser temporary account log" type

What happens
There is more than one log for the temporary account editing in step 3

What should happen instead
Only one log entry should exist for the temporary account editing in step 3

Acceptance criteria

• The steps to reproduce no longer produce the unexpected behaviour