Overview

The general need is to be able to define constraints on trackers that would allow to identify artifacts given a time. For instance:

• I want that all artifacts that are not "Done" 1 week before the due date to be flagged as "Late"
• I want that all artifacts that are not "Done" 2 days before the due date to be flagged as "Emergency"

There are several approach to this problem:

1. Dedicated interface
2. Generic approach
3. Limited generic approach

Dedicated interface

As the original request is well defined (ie date based constraints and list based consequences) we can propose a dedicated interface that covers exactly the use case. For instance:

The advantage of this approach is that we only have a well defined set of constraints and consequences (triggers).

The drawbacks are:

• The interface and interactions are already complex despite a quite simple use case
• If we ever want to enrich the condition or the consequences, the interface will be even more complex so harder to use.

Generic approach

The generic approach is the reverse of the first proposal. Instead of having a dedicated interface we would have the possibility to define a TQL like query for the condition:

• Either with a "language" like: IF(status NOT IN ("Done") AND due_date <= NOW() - 1 week) THEN status = "late"
• Or with 2 parts, a "query" that define the constraint:
  • status NOT IN ("Done") AND due_date <= NOW() - 1 week
  • and a way to select the a trigger. For instance a field + value selector

In both cases it simplify the interface as rich constraints can be easily defined (as long as you are power user enough to grasp TQL).

The main drawback of this approach is to keep the things under control:

• Avoiding loops in the triggers:
  1. IF(status = "todo") THEN status = "on going"
  2. IF(status = "on going") THEN status = "todo"
  3. 💣
• Avoiding clashes or constraints with other constraints/features
  1. Workflow
  2. Field dependencies
  3. Hierarchy based triggers
  4. "Required"

Limited generic approach

A third possibility would be to create the feature with a very limited set of possibilities but with the generic approach in mind for extensibility. In this context that would mean:

• Ability to define the constraints as TQL queries BUT
  • Limited to "date" and "status" (as per semantic) fields
• Limit the trigger to select box or radio button fields (only one value can be selected)
  • Not source of the workflow (value in post actions is OK)
  • Not in field dependencies (neither source nor target)
  • Not "Required"
• Introduce a mechanism that would prevent 2 modifications made by "time based trigger" withing a given timeframe (for instance 1 day)
  • That would prevent to have loops in the changes

With this approach we would be able to define triggers like:

• status NOT IN ("Done", "Archived") AND due_date <= NOW() - 1 week ➡️ card_highlight = "warning"
• status NOT IN ("Done", "Archived") AND due_date <= NOW() - 2 day ➡️ card_highlight = "emergency"

With "card_highlight" as select box field with 2 values "warning" & "emergency" with a default value to "None" (no highlight).