It has been a long-standing issue how we should handle forcible autocreations via Special:CreateLocalAccount in relation to AbuseFilter.
The main challenges are:
- AbuseFilter cannot currently distinguish between normal autocreations and CreateLocalAccount autocreations.
- For the latter type of autocreation, there is no way to reference the actual auto-creator using the user_ variables.
- Because of this limitation, sysops using Special:CreateLocalAccount have to temporarily disable filters that would otherwise prevent CreateLocalAccount actions before performing them.
As far as I can tell, there are four possible approaches to this problem.
1. Compute user_ variables for CreateLocalAccount actions (see also T366858: AbuseFilter does not report user_group or user_name when CreateLocalAccount is performed)
This would allow filters to be written in a way like:
action === "autocreateaccount" & !(user_rights contains "centralauth-createlocal") & ...
2. Separate CreateLocalAccount actions from autocreateaccount (see also T307828: Separate Special:CreateLocalAccount from autocreateaccount in abuse filters)
We could introduce a new action such as createlocalaccount.
However, this approach would likely require significant developer effort, as creating a new action is often not straightforward.
A conceptual concern is that no other actions would belong to this new type, since it is purpose-specific and essentially a “closed-set” action.
3. Allow AbuseFilter to ignore CreateLocalAccount actions
This could be reasonable because the centralauth-createlocal permission is restricted to sysops and stewards (by default).
However, another question arises: What if a project intentionally assigns this permission to a local user group?
For example:
- nlwiki assigns centralauth-createlocal to vrt-agent.
- zhwiki assigns centralauth-createlocal to event-organizer and ipblock-exempt-grantor.
Would it be acceptable for these local groups to unconditionally bypass AbuseFilter for forcible autocreations? If the answer is yes, then this approach becomes a viable option.
4. Add a "Bypass AbuseFilter" UI to Special:CreateLocalAccount
This would allow the performer to choose whether the autocreation should be evaluated by existing filters.
We could introduce a new user right, such as abusefilter-bypass-createlocal, and assign it to sysops and stewards to control who is allowed to use this flexibility.