Angular workflow plugin

Registered by Thai Tran

An angular workflow consists of many steps. However, there is currently no way to add, remove, or modify existing workflow steps without editing source code. This blueprint focuses on a process that enables a more pluggable way to modify workflows. However, the process illustrated here can be generalized to other angular components.

We currently have a robust way to add dashboards and panels via a plugin mechanism, but nothing at a more granular level like workflows, table columns, actions, etc. This is a new process for client-side code that will allow users to do more granular and pluggable modifications.

Recently, we have a mechanism that auto collects static files in your plugin. Alternately, you can point the static collector to a directory in settings to include your own custom code. Bottom line is, you have a few options to include custom code and even override them.

Lets take a look at a real-world example in order to understand the problem. Below are the conditions:

There is a single workflow A containing 3 steps
There are two teams, red and blue, seeking to add to workflow A
They both want to do this without modifying code in trunk

So how do we address this problem? We can use angular’s dependency injection to help us! Red team just have to inject workflow A and do something to it. Blue team will also inject workflow A and do something to it. However, we end up in a race condition, because we don’t know ahead of time which team’s file is going to get picked up first.

The race condition is not really an issue if we allow each team to insert their step at a particular position and optionally specify a priority. Lets say they both want to add their custom step after Step1. All they need to do is specify the id to where they want to insert, and a priority number (which they will have to work out internally, much like how our enabled files work today).

Below is pseudo code that would address this issue.

Workflow Service
// priority is an OPTIONAL parameter
app.factory(‘workflowService’, function(){
  return {
    prepend: function(config){...}
    append: function(config){…},
    insertStep: function(stepId, config, priority){…},
    removeStep: function(stepId){…}

Base workflow
app.factory(‘workflowA’, function(workflowService) {
  return workflowService({
    title: ‘Workflow A',
    steps: [{ id:’’, title: ‘', templateUrl: ‘’, helpUrl: ‘’, formName: ‘’ }, ……]

Blue Team
app.factory(‘workflowA’, function(workflowA) {
  return workflowA.insertStep(’step1’, config={...}, priority=1);

Red Team
app.factory(‘workflowA’, function(workflowA) {
  return workflowA.insertStep(’step1’, config={...}, priority=2);

Final WorkflowA
title: ‘Workflow A',
steps: [
  { id:’step1’, title: ‘', templateUrl: ‘’, helpUrl: ‘’, formName: ‘’ },
  { id:’blueteam’, title: ‘', templateUrl: ‘’, helpUrl: ‘’, formName: ‘’ },
  { id:’redteam’, title: ‘', templateUrl: ‘’, helpUrl: ‘’, formName: ‘’ },

Doc Impact:
Need documentation for this process.

Blueprint information

David Lyle
Thai Tran
Justin Pomeroy
Series goal:
Milestone target:
milestone icon mitaka-1
Started by
Justin Pomeroy
Completed by
Justin Pomeroy

Related branches



One issue is that the API call to the workflowService needs to happen after the workflow is defined, but the ordering of Javascript file loading can't be guaranteed (without perhaps adding new rules to the file sorting already done).

The API call to the workflowService to modify the workflow should be done in a .config() angular step, so that the workflow and service are guaranteed to be present and we don't have to worry about ordering issues in the loading of the Javascript source files.

Also, I think that "insertStep()" should be called "after()" to make it clearer where the new step is going to be inserted relative to the reference step.

prepend() and append() need a priority.

There also needs to be replace().
-- Richard Jones

Gerrit topic:,topic:bp/angular-workflow-plugin,n,z

Addressed by:
    WIP Support angular workflow extension as a feature plugin

[2015-08-19 | david-lyle] "priority" conflict resolution is a concern that should be considered. Would target for Mitaka, but it's not in the list yet.


Work Items

This blueprint contains Public information 
Everyone can see this information.