generalize conditions for TicketSubmitPolicy

[Jeff Hammel]

currently, conditions for the application for a rule are at best "<field> <comparitor> <value_of_field>"; more generalized conditions would allow the plugin to be much more useful.

The first step is to define the shape of conditions. The second step is to make these pluggable. These steps are contingent upon one another.

[Jeff Hammel]

I think some insight can be gleamed from the query view: (e.g.)

​http://trac-hacks.org/query

this is still basically in the form of "<field> <comparitor> <rhs>", but the type of the rhs (right hand side) is dependent on the type of the field. Also, comparitors can be grouped together with "ands".

Replicating this behavior TTW shouldn't be difficult once the infrastructure is in place (see #3126), but of course nonsense can be entered in the .ini file. I'm envisioning something like

policy1.condition = type == defect && component == website && state != closed

The first step seems to be figuring out what operators are available and what the right hand side can be for each operator. A simple stab:

• ==: is equal to; one argument
• !=: is not equal to; one argument
• in: is in a list; multiple arguments (e.g. version in 0.1, 0.2, 0.3
• not in: is not in a list; multiple arguments
• >: greater than. Probably really, "version greater than", as this wouldn't apply to other fields; one argument
• >=, <=, <: the rest; all one argument
• contains: for things like keywords or CC; "is the value given one of the keywords?"; one argument

Not all of these would have to be invented up front. Just defining the behavior, writing an extension point, and re-doing == and != would put the code in better shape. At that point, in and not in should be trivial as well.

The or operator (||) should be considered as well (notably absent from the /query interface). I'd like to keep things as simple as possible and, for instance, not parse parentheses if I don't have to.

[Jeff Hammel]

the notation for the .ini file could or could not differ from the proposed webadmin interface (#3126). There is also the function (later, maybe class) names that the JS uses.

Proposal:

.ini	web interface	JS
==	is	is
!=	is not	isNot
in	in	in
not in	not in	notIn

Alternatively, they could be kept the same or as close to the same as aesthetically pleasing which has a nice aspect as there is a rule to describe (say) english -> camelCase conversion. &&, or maybe and would have to be treated separately (say, split on first in parsing) and adding an or probably necessisates parentheses, for readability if for nothing else (of course, how complex should a policy be?). for simple policies, or-s could also be accomplished by having another policy with the same actions but alternate conditions (if #3128 were fixed).

[Jeff Hammel]

I'm closing this ticket; the basics are done. In short:

• conditions all use "english" syntax (is in, is not in, etc); the JS functions are camelCase versions of these (isIn, isNotIn)

• multiple conditions are joined by &&s; I've decided ors are YAGNI

I think there is some need for these to be pluggable components, much as I have done policies (and there's certainly need to make the conditions better, which may happen in accomplishing #3126). But this general ticket is closed; please open another for more specific issues regarding conditions