-
Notifications
You must be signed in to change notification settings - Fork 198
Events
Jira has an extensive workflow engine, describing transitions between states along with sophisticated access rights and actions to perform (eg. sending an email).
Youtrack also has an interesting workflow engine, with a DSL and editor specially for the purpose of driving this. https://confluence.jetbrains.com/display/YTD6/Workflow+Overview
Jobsworth currently has only emails which are triggered on certain events (eg. adding a comment to a task) and a couple of other events (eg. closing a milestone when the last task is closed, or updating task scores at the right times).
It would be useful to expand on our events and actions. Some useful goals:
- send different emails for closing/opening/comments depending on task severity, project or other things
- present a button to the user for state transitions. Eg. instead of setting a new assigned user, changing the task to testing, and adding a comment: it would be useful to have a single button that does all the right things.
- recurring (cron) emails, for example to send a customer a summary of all tasks opened in the last 30 days and their status
- escalation. If a task is languishing in a user queue for longer than a defined time (probably depending on severity), it would be useful to bump it by adding a comment or adding another cc user or sending an email to management
- we currently parse incoming emails and add them to incoming, but we don't assign them to milestones or users. We should be able to do that based on keywords in the incoming emails. We can even do some preliminary processing on emails coming from automated logging systems.
- The simplest approach is to code each of the above options separately. Perhaps a templating engine for emails, a hardcoded once a month task summary, and a hardcoded escalation process
- Some sort of dynamic state engine like this: https://github.com/state-machines/state_machines with a mechanism for the admin to define the states and actions
The problem with the state engine is how to define events and actions. In effect we have several parts:
- The event:
- cron
- task save
- message create
- worklog added
- Filter. We already have the ability to create and save search filters.
- Action:
- Add templated message
- Modify task values
- Send email
We want to avoid allowing the user to write any Ruby they want for reasons of security and reliability. It would be too easy to break things badly.
We also don't want to create all the complexity and power of Jira/Youtrack. Our needs are simpler.
Part of this work will be to create customisable email templates. We have a few options
- html emails and plaintext need to be written separately
- no protection against malicious or badly broken content
- Depends on one company, so possibly limited to that they want
- A bit simplistic
- html emails and plaintext need to be written separately
- solid protection against bad templates
- https://github.com/schneems/maildown
- html and plaintext handled easily
- not sure about protection against bad templates
https://github.com/mustache/mustache
- html emails and plaintext need to be written separately
- I think we have good protection against bad templates since we have a lot of control over what objects and attributes are visible
- More flexibility than Liquid