Make timeline ticket updates aware of workflow actions

[ethan.jucovy@…]

Ticket updates on the timeline are not currently workflow-aware. Instead of using workflow actions to distinguish between created, reopened, closed, and updated tickets, the timeline looks for status changes in the ticket_change table, and hard-codes certain verbs based on the ticket's status change.

These verbs overlap somewhat with the actions provided by the default workflow but in fact are completely independent of them: for example, if a ticket's status changes to "reopened", the timeline will render an event saying "Ticket .. reopened by .." regardless of what workflow action (if any) caused the ticket to arrive in the "reopened" state.

This overlap in responsibilities is confusing, and also means that certain assumptions about the ticket workflow are hardcoded into the timeline:

• The timeline assumes that a "reopened" state exists, and has some special meaning which should be distinguished from other ticket updates in the timeline
• The timeline does not know how to distinguish between any other types of ticket updates, even though some of these might be more special than others

It would be nice if the ticket updates in the timeline could be made workflow-aware, and if they could use historical workflow actions to render themselves instead of using status changes.

[ethan.jucovy@…]

attachment:workflow-aware-timeline.diff​ implements a (not quite complete) proof of concept using the following approach:

• trac.ticket.model.Ticket.save_changes has a new optional keyword argument action, which is a ITicketActionController-style string like "accept", "reopen", "close", etc.
  • If an action is provided to Ticket.save_changes, the action string will be saved alongside the ticket changes.
  • The action string is saved as a new row in the ticket_change table, in a manner similar to "comment" storage: a row is created with type="action", oldvalue=cnum, and newvalue set to the action string.
• The ITicketActionController interface has a new method, get_action_timeline_label(req, ticket_resource, action). An action controller may return a past-tense label for the given action, e.g. "accept" ⇒ "accepted", "reopen" ⇒ "reopened".
  • The default ConfigurableTicketWorkflow implements this interface by looking for configuration like [ticket-workflow] accept.past_tense = accepted.
• The TicketSystem has a similar new method get_action_timeline_label which asks each of its action_controllers for a response in turn. The first action controller to respond gets to set the label. If no action controller responds, the TicketSystem defaults to adding the suffic "ed" to the end of the action string.
• The ticket timeline component special-cases ticket_change rows with type="action", similar to its special-case handling of type="comment" rows. Rows with type="action" are not rendered as individual ticket change entries. Instead, if an action row is found for a group of changes, its newvalue is used as the event's verb, instead of relying on the verbs in the hard-coded status_map.

If this approach seems good, next steps would include:

1. Connecting the same system to the change history rendered in the ticket itself, so that the special "action" ticket_changes aren't displayed as ticket changes, and (potentially) the workflow-aware verbs are used in place of the generic "Changed 14 minutes ago by ejucovy" headings
2. Making the default "ed"-suffixing behavior more i18n-friendly and/or configurable
3. Tests

I know that storing action strings in the ticket_change table (and extending the ITicketActionController interface) is a pretty far-reaching change for an arguably minor timeline enhancement, but I think it makes the codebase more consistently workflow-friendly, and other parts of the system (including plugins) could potentially do interesting things with a persistent history of workflow actions.

[ethan.jucovy@…]

Whoops — this is a duplicate of #5441, sorry.