Right now various abuse filters are causing unintended hits due to them having to resort to user_groups where user_rights would be more appropriate.
Especially with regards to global user groups granting rights, they can sometimes be really intrusive and unexpectedly causing someone to be unable to make an edit on a local wiki.
Version: unspecified
Severity: enhancement
aravikn wrote:
I'd like to work on this bug but would someone explain how this works?
In AbuseFilter.class.php there are variables defined.
user_groups, for example, is populated from User::getEffectiveGroups.
You'd add a similar one that is populated with the user rights.
Raising priority. This is making maintenance of rules very hard because we have to hardcode all user groups that contain a certain right instead of being code the actual intent via the user right.
Plus it is not just annoying to work around, it is causing problems as global sysops, stewards, globalinterface users often get hit by a disallowing abuse filter in routine maintenance because the local wiki doesn't know about these groups.
So, for example, in globaleditinterface, if some wiki (*cough*, en.wiktionary.org) has an abuse filter rule to essentially protect user subpages users from editing by other users (except sysops bots etc. and other whitelisted user groups), I am unable to edit their pages even though I'm supposed to be able to edit protected pages and explicitly user script subpages.
If they were able to look for the "bot" right (instead of bot group), and "edituserjs" or "protect" right (instead of sysop), this would avoid having to update all filters when local groups change, and will automatically also work as expected for global users.