Modify

Opened 6 years ago

Closed 6 years ago

#3129 closed enhancement (fixed)

generalize conditions for TicketSubmitPolicy

Reported by: k0s Owned by: k0s
Priority: high Component: TicketSubmitPolicyPlugin
Severity: normal Keywords:
Cc: Trac Release: 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.

Attachments (0)

Change History (3)

comment:1 Changed 6 years ago by k0s

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.

comment:2 Changed 6 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 6 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

Add Comment

Modify Ticket

Action
as closed .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from k0s. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.