Workflow Roadmap

References

Workflow documentation (needs updating)

Jira Project

UX Concepts:

Keeping the user informed about what's going on

Visual design proposal for reworked workitems in pulse

Superseded Concept Page

Introduction

This page will keep track of the roadmap for the workflow module. It should act as a reference for future steps to be taken in the module. Feel free to comment on the wiki page, but to not end up like the superseded concept page, please do not edit directly.

Pulse and workItems (Review App)

This is one of the next big tasks to be tackled after workflow 5.3. Working with pending/completed workitems is currently a pain. The major technical limitation is that we treat workitems the same way we treat messages in the pulse. It basically acts like an email in your inbox, without any state information except when trying to perform an action.  MGNLUI-2572 - Getting issue details... STATUS

Visual design proposal for reworked workitems in pulse

• i18n: Pulse messages are not translated. Should we only send the keys and translate the message when the user opens the message in pulse? If so, what about dynamic messages? subject = key + args?
• Pulse is still restricted to display subject and body. Basically only getters provided in Message-Interface
• No action availability on actions based on workItem status
• When deleting a workItem notification from pulse, the process can never be resumed by a publisher. This could be solved by having the pulse dealing workItems differently than messagesor an app keeping track of workItems.
• see concept

Integration

Outline of steps needed to make 3rd party integration easier for developers.

• ActivationAction adaption is currently too complex. We need some simple steps to enable workflow. (see install tasks, next point)
• see Workflow Configuration and Actions
  
  • Action chaining much like commands
  • Composite Actions could solve
    
    • chaining of actions for commenting
      
      • publication action opens a dialog from workflow module, which calls back into content apps activation action. This is done for each and every activation related action: activate, activateRecursive, activateDeletion, deactivate
• Provide Install tasks for content apps to enable or disable workflow. This one is depending on e.g. Action chaining. 
• activate workflow on module configuration or workspace level instead of commands?
  
  • Note: I prefer using catalog as is.

ErrorHandler

ErrorHandling is modelled by setting and reading exceptions. This is apparently not all wrong, but using JBPM ErrorHandlers and signalling properly would make this nicer.

Problems

Cleanup, create concept for parameters

• Introduce a WorkflowContext, providing getters for often used parameters. Would also allow us to not run the workflow in system context, but rather have an own context for executing commands etc.
• for example subject used for notifying users, is retained when publication fails and has to carefully been taken care of when re-submitting publication.
• gets cluttered
• maybe not use mgnlData map for everything.
• get rid of:
  
  • info.magnolia.module.workflow.jbpm.JbpmWorkflowManager#mergeParameters
  • info.magnolia.module.workflow.jbpm.JbpmWorkflowManager#launch

Done

i18n

Make workItemHandlers use new i18n concepts. (fixed in 5.2.1)

Integration

• Registry using Observation should be used for the workflows and workItemHandlers. Extension currently only possible by bootstrapping configuration.

Timed Tasks (ongoing effort)

• workflow executed synchronously (this is not the case when using timers)
• Can not use MgnlContext to read e.g. current user (fixed by executing and aborting workItemHandlers in system Context)
• We need to manually load processes/sessions (?) containing timers when restarting the application, otherwise they're not triggered
  
  • see discussion https://community.jboss.org/thread/211785
• currently sending the diff in ms between now and publication date. what happens when it restarts. -> jbpm 6 supports date, somehow send the date and handle the diff calculation in the process (didn't work as expected, the code is not interpreted..)