Okay, the answer is simple and somewhat disturbing: the new parser just failed to parse the filter in question with the syntax error, so it presumably never got executed. I've expected this to fail more loudly than silently failing open, but I am not sure how the filter edit hooks actually handle this.
Oct 8 2019
Oct 4 2019
Sep 6 2019
Jan 10 2019
Jan 24 2017
Dec 18 2016
Nov 10 2016
Nov 7 2016
So, my current understanding is that the reason why we are hitting this is
(1) There is no recursion limit in the new parser (definitely a bug),
(2) Previously the tree for same operations were flat, meaning that the trees we now get are much deeper. I'd need to think how to work this fact around.
Oct 20 2016
The specific change which happened, as far as I understand it, is that the precedence remained the same, but apparently the new parser treats boolean operators as right-associative, whereas it used to treat them as left-associative. This is an oversight on my part. I will write a patch to fix that and add tests.
Sep 4 2016
What I meant is the traditional power structure of Wikimedia projects ask bureaucrats are the ones to grant sensible rights. Independantly with their sysop status, they are also used to grant sensible rights,
No, they're not different. They all have the same purpose: unbundling from
the sysops the privs to edit css and js site files and other things. That
the permissions are a bit different across the sites is nothing new and it
happens with some non standard groups such as patrollers, rollbackers, etc.
Sep 3 2016
So, there seems to be a security concern expressed here about allowing sysops to delegate editinterface permission. However, the more I think about it, the more unconvinced I become that there is any actual difference between the existing situation and the proposed one. Could someone elaborate what the suggested threat model is?
Nov 2 2015
Well, I clearly cannot reproduce it locally then. Unassigning myself from this.
Will take a look.
Jul 27 2015
Jul 14 2015
Mar 13 2015
Mar 11 2015
Mar 4 2015
Mar 3 2015
Jan 7 2015
I am fairly skeptical about the requested change. The situation for as long as I remember have been (and correct me if that changed) has been that the account usurpation policy is up to each individual project, and some projects never allowed usurpation under any circumstances. I am concerned that we might be possibly circumventing local policies with this decision.