Opened 8 years ago

Closed 8 years ago

# generalize conditions for TicketSubmitPolicy

Reported by: Owned by: k0s k0s high TicketSubmitPolicyPlugin normal 0.11

### Description

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.

### comment:1 Changed 8 years ago by k0s

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

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.

### comment:2 Changed 8 years ago by k0s

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).

### comment:3 Changed 8 years ago by k0s

• Resolution set to fixed
• Status changed from new to closed

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