Determine relationship between content workflow and task status

[seanupton]

• When is relationship between primary workflow state 1:1 to task status?
• When does primary workflow transition potentially affect task status as effect?
• Is it appropriate to store state as a secondary workflow in a chain on content that is not primarily a task?
  • Or should task-status state be stored elsewhere?
• How should task status be displayed?
  • In View (vs. portlet vs. Viewlet above content, etc) and should history be displayed in workflow_history?

[aclark4life]

Good question. I think I'd prefer to keep content status (i.e. workflow state) and task status as close to 1:1 as possible. Is it possible they could be 1:1 always or do we need to think about when they absolutely can't be 1:1?

[seanupton]

My sense is that for integrated types other than the OOTB task content type, we cannot necessarily have this be 1:1 (bijective), because they may use a different workflow with differing state and transition names/purpose to the task management. There are two approaches I see as a possibility:

(1) Completion by effect (event subscribers to transitions): for UPIQ forms, when we "submit" a form, it's task aspects ought to be marked as complete (as an effect/subscriber to transition), and when we "send back" or "retract" there should likewise be a subscriber to those transitions that marks the task as "completed".

(2) An adapter interface that simply queries whatever state is appropriate for the content type to answer whether the item is completed. Types integrated with non-OOTB workflow definition would be expected to write their own adapters to satisfy the question.

[aclark4life]

Thanks. I think I like requiring event subscribers better than adapters as the former is arguably a common integration task and the latter a "heavy" development task.

[aclark4life]

Primarily due to the lack of support for secondary workflows in Plone, we decided to store task state elsewhere and I've since changed my mind re: event subscribers vs. interfaces; we're using an interface to provide access to task state e.g. ITaskAccessor(context).state