Opened 10 years ago

Closed 10 years ago

#3129 closed enhancement (fixed)

generalize conditions for TicketSubmitPolicy

Reported by: Jeff Hammel Owned by: Jeff Hammel
Priority: high Component: TicketSubmitPolicyPlugin
Severity: normal Keywords:
Cc: Trac Release: 0.11


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.

Attachments (0)

Change History (3)

comment:1 Changed 10 years ago by Jeff Hammel

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 10 years ago by 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.


.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 10 years ago by Jeff Hammel

Resolution: fixed
Status: newclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Jeff Hammel.
The resolution will be deleted.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.