symbiote / silverstripe-advancedworkflow

A highly configurable step-based workflow module.

Advanced Workflow Module

Overview

A module that provides an action / transition approach to workflow, where a single workflow process is split into multiple configurable states (Actions) with multiple possible transitions between the actions.

Requirements

• Silverstripe Framework and CMS 3.1 or newer
• (Optional) Queued Jobs module (for embargo/expiry functionality)

Note: The Silverstripe 2.4 version of the module is available from the ss24 branch of the repository.

Installation

composer require symbiote/silverstripe-advancedworkflow

The workflow extension is automatically applied to the SiteTree class (if available).

Documentation

• User guide
• Developer documentation

Contributing

Translations

Translations of the natural language strings are managed through a third party translation interface, transifex.com. Newly added strings will be periodically uploaded there for translation, and any new translations will be merged back to the project source code.

Please use https://www.transifex.com/projects/p/silverstripe-advancedworkflow to contribute translations, rather than sending pull requests with YAML files.

silverstripe-advancedworkflow's Issues

"Allow editing during this step" field disappears

Select “Workflows” in left-hand CMS nav, then select a workflow containing some actions and select “Edit” on one of those actions.

Observe there is no dropdown field showing to the right of the “Allow editing during this step” field-label. Occasionally you will observe it show and become hidden once again almost immediately. Reloading/refreshing your browser and selecting “Edit” again, “fixes” the issue.

As i have seen similar behavior elsewhere in the CMS, this is likely a CMS+JS issue rather than being module-specific.

Firefox 15 and Chrome 22 OS X 10.7.4

Usability: Workflow

Silverstripes Publish button locations design is changing, we will need to make some adjustments to the way buttons are presented for Workflow.

SilverStripe 3.1 button Changes
https://skitch.com/clarkepaul/849t1/actions-panel-and-status

Our designer Bee will be taking a look at how Workflow is presented and ease of use.

Action buttons appear even when content-object is marked "Removed"

Workflow buttons still appear in the CMS UI for content-objects marked as "Removed". Selecting this button produces a PHP error.

Workflow action-buttons should be hidden until the targets to which their workflows are attached, are editable again.

$Context.(Fieldname) seemed not rendered, beside the special one $Context.CMSLink

When I put the variables in those notifying emails, such as $Context.Title, $Context.LastEdited, etc., they seemed not rendered into the page that applied the WorkflowDefination

Disallow creation of title-less workflows

Presently, there is no validation on the creation of workflows so a user can create a workflow with no title, and it will appear as such in the module's ModelAdmin.

User confirmation messages now look a little odd also - thus; Saved Workflow Definition ""

Some validation would be good here, or even for the module to allocate a default title, after having checked that the elected-for default, doesn't already exist.

Additional UI widget or indicators for multiple button scenarios

There may be instances of CMS use where the CMS "admin" (superuser) is also an editor or manager (or publisher etc).

Current functionality is therefore to show the "Save and Publish" button, as well as the workflow-specific action-buttons in these cases, which is obviously not ideal. Initial use of the module in proceeding through a workflow may confuse users as to which action will be performed if/when one or the other of these buttons were clicked.

Proposed solutions:

1). A JS dialogue when either of these buttons is clicked in the above scenario, explaining what is about to happen, and/or;
2). A LiteralField with some "hint" text above the button-action content-area, or;
3). If a workflow is in effect on this content object, show only the workflow's action button - but if the above scenario is true - present a JS dialogue (like a bog-standard window.confirm but fancier) where if a button "Proceed with workflow" is pressed, the workflow action continues or a 2nd button is pressed; "Publish now" the default action would occur as if the user has clicked the "Save and Publish" button.

This would of course need some UI/UX design work before work can proceed.

Show transitions instead of actions on content-objects

Selecting a WorkflowInstance in the CMS, allows editors (or "approvers") to run the next transition in the current action. However when viewing the Target object in the CMS (e.g. a "Page"), the action itself is shown as a button "Editor Approve" (for example). This basically means an editor is unable to "Reject" (if >1 transition exists on the current action) an action, just move the workflow-instance onto the next action.

Should this UI be re-defined to show the available transitions as opposed to jumping directly to the next action these transitions lead-to?

This is likely low-priority - see issue #51

Add CSS padding to Formatting Help UI widget(s)

Not at all a major but: There is no padding on each ToggleCompositeField for each NotifyUsersWorkflowAction. Adding some would make this UI a little more consistent with the rest of the CMS UI.

Wrapping the output of getFormattingHelp() in an additional <div> or adding contextual padding to an existing <p> selector in the module's CSS would easily achieve this.

BUG: Exception thrown when restricting a transition to users

Create at least x2 actions and a transition between them on an existing workflow definition. Now go and edit that transition and try and make a selection from the "Users" dropdownfield - this fails and in your browser's debugger you'll see something like:

ERROR [User Error]: Uncaught Exception: Object->__call(): the method 'markpartialtree' does not exist on 'Member'
IN POST /admin/workflows/WorkflowDefinition/EditForm/field/WorkflowDefinition/item/53/ItemEditForm/field/Workflow/transition/item/128/Form/field/Users/tree
Line 675 in /Users/rmichell/sites/ss3-opensource/framework/core/Object.php

BUG: Timepicker throwing error on unmatch on scheduled publications

To reproduce:

• Go to a page with the "publishing schedule" tab
• Select a time (or a date) to publish.
• Clear the field you just filled, focus out.

Console throws:

Uncaught exception TypeError {} in onunmatch on 
    <form id=​"Form_EditForm" action=​"admin/​pages/​edit/​EditForm?locale=en_NZ" method=​"post" enctype=​"application/​x-www-form-urlencoded" class=​"cms-edit-form center CMSPageEditController CMSMain LeftAndMain cms-previewable ui-widget ui-tabs-panel ui-widget-content ui-corner-bottom" data-pjax-fragment=​"CurrentForm" data-layout-type=​"border" aria-live=​"polite" aria-labelledby=​"ui-id-3" role=​"tabpanel" aria-expanded=​"true" aria-hidden=​"false" autocomplete=​"off" style=​"left:​ 201px;​ top:​ 40px;​ width:​ 635px;​ height:​ 614px;​ position:​ absolute;​">​…​</form>​
jquery.entwine-dist.js?m=1376257011:863


    Stack Trace:
TypeError: object is not a function
    at jQuerySub.$.entwine.onunmatch (http://localhost/project/cms/javascript/CMSMain.EditForm.js?m=1376257086:325:35)
    at Array.proxy [as onunmatchproxy] (http://localhost/project/framework/thirdparty/jquery-entwine/dist/jquery.entwine-dist.js?m=1376257011:1867:23)
    at HTMLDocument.<anonymous> (http://localhost/project/framework/thirdparty/jquery-entwine/dist/jquery.entwine-dist.js?m=1376257011:2043:16)
    at HTMLDocument.jQuery.event.dispatch (http://localhost/project/framework/thirdparty/jquery/jquery.js?m=1376257011:3332:9)
    at HTMLDocument.elemData.handle.eventHandle (http://localhost/project/framework/thirdparty/jquery/jquery.js?m=1376257011:2942:6)
    at Object.jQuery.event.trigger (http://localhost/project/framework/thirdparty/jquery/jquery.js?m=1376257011:3210:12)
    at jQuery.fn.extend.triggerHandler (http://localhost/project/framework/thirdparty/jquery/jquery.js?m=1376257011:3874:24)
    at Base.extend.triggerEvent (http://localhost/project/framework/thirdparty/jquery-entwine/dist/jquery.entwine-dist.js?m=1376257011:1358:16)
    at http://localhost/project/framework/thirdparty/jquery-entwine/dist/jquery.entwine-dist.js?m=1376257011:1364:68 jquery.entwine-dist.js?m=1376257011:866

3.0 Compatibility

Just a note that the master branch of this module is no longer 3.0 compatible, until there's a separate branch.

Show diff of changes as part of workflow

When submitting a change for approval, the person approving needs to easily see what has changed. The cmsworkflow module had this feature, showing a field-by-field diff with red/green highlighting.

This content should be shown in two places:

• Workflow emails
• The workflow screen

No designs currently exist, AFAIK

Usability: Embargo/Expiry

Some Usability Adjustments:

1. Label each field appropriately and separately

Embargo:
'Select Publish date'

'Select Publish time'

Expiry:
'Select Un-publish date'

'Select Un-publish time'

1. Add Time Picker to time field to assist in data entry and format required.
   Currently a text field, this should probably have a time picker drop down of some sort.
2. "Click "Save Draft" to save changes" instruction.
3. Add an additional button/indication when a page is under Embargo preventing early Publishing.
   Additionally a Content Publisher would need to be able to 'Remove' an embargo in this state - rather than editing date/time to null

Maintainer note: See framework commit 585a8bc "Removed 'showdropdown' option from TimeField, use custom libraries instead (Ingo Schommer)" This is why a dropdown no-longer shows for this workflow functionality.

Allow the creation of "undo publication request" step

Consider the following use-case:

• An author makes a change
• An author submits it for publication
• An author realises that there is one final change to make

In these situations a "make further edits" or "cancel publication request" action would be great. The workflow system is fairly configurable, but one thing it doesn't let you do is define an action that can be triggered by the original author even when the workflow has been assigned to someone else.

Adding "Who can perform this action?" as a dropdown to each action that defaults to "Current assignee" is part of this. However, what appears in the dropdown? The simplest would be to list all groups/users.

The problem I see with listing all groups/users in the system is that you need to create a whole new workflow for each set of users. It's one thing to say "a 2 step workflow lets Editors create content and Publishers publish it", but then if you have a separate section of site, e.g. Careers, with different editors and/or publishers you need to make an entirely new workflow such as "a 2 step workflow that lets 'Careers Editors' edit content and 'Careers Publishers' publish it".

This seems far from optimal but this limitation already exists in the system, so it shouldn't be solved merely for the feature described in this ticket.

Possible bug on new Queued objects with expire embargo

I've got some failing unit tests for this module.

According to them, it looks like the QueuedJob module (class AbstractQueuedJob) doesn't play want to play nice.

Basically the extension WorkflowEmbargoExpiryExtension adds object in onBeforeWrite to QueuedJobService via a WorkflowPublishTargetJob. But it fails for me with:

WorkflowEmbargoExpiryTest::testFutureDatesJobs
Trying to get property of non-object
PHPUnit_Util_ErrorHandler::handleError(8,Trying to get property of non-object, /Users/slindqvist/Code/site/advancedworkflow/code/jobs/WorkflowPublishTargetJob.php, 18, Array)
WorkflowPublishTargetJob.php:18

I believe this happens because the AbstractQueuedJob::getObject() calls a DataObject::get_by_id() on the object that actually is in the onBeforeWrite hook.

I haven't hade more time to look into it and it might be mine setup of SS3, AdvancedWorkflow and QueuedJob that causes it. But it is pretty much on the latest HEAD.

Full stack trace:

$ ./framework/sake dev/tests/WorkflowEmbargoExpiryTest

WorkflowEmbargoExpiryTest::testFutureDatesJobs
Trying to get property of non-object
PHPUnit_Util_ErrorHandler::handleError(8,Trying to get property of non-object,/Users/slindqvist/Code/site/advancedworkflow/code/jobs/WorkflowPublishTargetJob.php,18,Array)
WorkflowPublishTargetJob.php:18

WorkflowPublishTargetJob->getTitle()
QueuedJobService.php:101

QueuedJobService->queueJob(WorkflowPublishTargetJob,2020-01-01 00:00:00)
WorkflowEmbargoExpiryExtension.php:130

WorkflowEmbargoExpiryExtension->onBeforeWrite(,,,,,,)
Object.php:913

Object->extend(onBeforeWrite,)
DataObject.php:946

DataObject->onBeforeWrite()
SiteTree.php:1378

SiteTree->onBeforeWrite()
Page.php:174

Page->onBeforeWrite()
DataObject.php:1068

DataObject->write()
WorkflowEmbargoExpiryTest.php:27

Build Embargo/Expiry into workflow for easier install

Embargo and Expiry requires a config call additionally to Workflow

Object::add_extension('SiteTree', 'WorkflowEmbargoExpiryExtension');

Can it be built/incorporated into the single module for easier install?

ENHANCEMENT: UI Indicator for content with effective workflow

It would be useful for authors of all kinds to see at-a-glance, if some content-ish objects had an effective workflow applied to it, either or both of an icon or label in the site-tree similar to the current 'modified' and 'draft' labels and/or a label or icon in the edit UI for that content.

Note: Will need design input before work commences.

See suggestion from @nyeholt in #19 for something along these lines.

BUG: Hide workflow creation button if user has no permission to create

With no permissions allocated for advanced workflow in the standard CMS secuity admin, a user can still see the button to create a workflow definition. He will eventually receive a forbidden growl message when trying to create actions and transitions, but really shouldn't be allowed to get this far.

Simply hiding the button via canView() should be sufficient.

Add email field defaults on NotifyUsersWorkflowAction

Add defaults to email from, subject and body fields on NotifyUsersWorkflowAction to speed-up initial workflow creation.

This is low priority, while issue #16 is attended-to.

Create a "docs" folder and move a new SS3 how-to, readme etc

The suggested directory hierarchy for SS modules includes provision for a "docs" directory for project-specific documentation, ultimately viewable by docsviewer.

Suggest a "docs" folder is added to the project and at least initially a new SS3 How-to.md is added, with subsequent how-tos and tute's being added to this directory as more are written.

@nyeholt, refer to shared Google doc (upon completion to our satisfaction) for the content of a .md how-to as a starting point for SS3. The existing 2.4 docs could also be added and we then layout the docs directory thus:

docs/2.4
docs/3.0

Migration process for cmsworkflow->advancedflow

Provide documentation and/or script to migrate workflow rules/setups/users from the old module to new.

Not working properly

Hi,

When i add an action, it works, but you can't remove the action.
Within an action > add transition > restrict to users will give an error.

My question is, is this module still in beta?
Updated the latest version of ss and this module.

Best regards

Add validation on instances of NotifyUsersWorkflowAction

Users are able to add some basic template logic into email templates on instances of a NotifyUsersWorkflowAction.

However if the syntax is incorrect (ie users actually try and use brackets - taking literally the formatting help syntax) users are only made aware of this when they try and run the workflow and notice an error in SilverStripe's "growl"-like alerter in the top-right.

Some basic validation on this field at point of creation / modification would therefore prevent this ever occurring, prior to any workflow instance being run.

Create default workflow on installation

When you install the module, it would be helpful to create a simple 2-step workflow to show how the system works.

The most straightforward way to do this would be a requireDefaultRecords() method that creates the workflow if no workflows exist. That way you could delete the default workflow and it wouldn't come back as long as your had created at least one other workflow.

Versioning / branching tidy up

Can I suggest the following to tidy up the branches?

• Drop the ss3 branch; it's been merged into master.
• Create a branch 1.4 based on the current ss24 branch, and delete the ss24 branch. That will be the final 2.4-compatible version. 1.5 will require SS3.

Alongside this I will submit composer.json pull requesets files to master (requiring SS >=3.0.0) and the existing ss24 branch (requiring SS >=2.4.0,<3.0.0).

This will mean that SilverStripe 2.4 users can install 1.4.x-dev via composer, and SilverStripe 3.0 users can install dev-master. In either case, specifying no specific version will install the correct one.

Author's name in CommentHistory

The CommitHistory in notifying email only populate with the author's name of the last comment, leaving all rest of the comments as no author name as blank

Addition of hint text to field labels

As a user creating a workflow - be it simple or complex - this can be a fairly time-consuming process (as noted in other issues by Sam for example), especially for newbies.

Anything that can be done to expedite workflow creation and understanding workflow in general as a concept, should help users considerably.

As a starting place, I'd like to see terse "Hint" text added to each form's field-labels in workflow, action and transition creation UIs, which if agreeable, myself and the team are happy to work on - probably expanding language functionality a wee bit using translatable for all copy initially.

Does this work with SS v3.0.5?

I get loads of errors when I try and install the module...

Can someone advise on how to install the module correctly? It might be due to my in-experience with SS on how to install modules that is creating the problem?

Appreciate any insight!

Cheers,

Add extra heading to action dialogue's for consistency

For usability, accessibility and consistency's sake, an extra <h2> should be used for the first-section of each action's popup dialogue.

Currently one might see "Assign Users" as a heading for the second logical field-grouping, but there is no consistent equivalent above it for the first logical field-grouping above ("Action class", "Title" etc).

Suggest something like "Edit Action" or "Administer Action".

Better visualisation of a workflow to highlight potential issues

Highlight in the UI when an action has

• no outbound transitions (ie it's a terminal action)
• only one outbound transition
• and any not-properly-configured transitions (ie transitions that don't have an outbound connection).

While it could be done using colours and other pretty things, I'm thinking something more like http://arborjs.org/ or http://raphaeljs.com/graffle.html or http://www.graphdracula.net/

BUG: Selecting an action button, loses changes

Because both "Save Draft" and the current workflow-action button, appear enabled at the same time, it is confusing for users who lose changes when pressing the action button, assuming that saving-as-draft occurs at the same time.

See comments in #72 for some background on this, but the best solution would be to disable/hide the action button until "Save as Draft" had been selected.

Note: Work on this shouldn't really commence until the new button API in 3.1 has been finalised and applied to this module, otherwise work is likely to be repeated.

Allow users to see personal workflow reports

Users need a personal workflow report, providing at least the following.

1. Content authors need to a list of what pages they've submitted into the workflow system and which user(s) are now to action these.
2. Publishers need a list of all the pages they're being asked to action, what the action is, who's waiting on them, how long they've been waiting, etc.

The current workflow reporting is inadequate and merely lists every active or completed workflow, and is not accessible to most users, it is intended for superusers.

Workflow buttons should be disabled if user has no permission to use them

In WorkflowAdmin, the Edit", "Add Transition" and "Delete" buttons on actions and transitions that comprise a workflow transition, shouldn't show in WorkflowAdmin if the current user doesn't have permission to perform those actions.

Currently, clicking these results in a CMS growl error = "Forbidden".

Dev note:

WorkflowInstance already has canView(), canEdit() etc methods on it, it's just a matter of calling these from the .ss template or adding some simple logic in the Class itself to perform the same.

WorkflowTransition does not have the canXXX() methods on it, see WorkflowInstance for how this is implemented.

Add Documentation for $Context.(Field Name)

When viewing the formatting help for a Notify Email there is a series of Calls you can make and one in particular, $Context.(field name)

Can we get documentation on what these field names are, or some that would generally be used in notify emails.

For example a Page Name/Title etc. This would be particularly useful in Summaries to notify what pages need review before publishing.

Rather than linking workflow rights to Users/Groups, link them to worfklow roles.

This follows on from the issues I mentioned in #17.

The general idea is that setting up a workflow is time-consuming and complicated, and ideally many users of the CMS would never have to do this. Admittedly, it's a lot easier than setting up a workflow in cmsworkflow module, which involved writing a lot of really fiddly code, which is why we've dropped cmsworkflow in favour of advancedworkflow.

However, because cmsworkflow never really expected you to create your own workflows, it made it easier to apply those workflow to different groups of users at different places in the system.

In particular, it would be good to apply workflow rights in two separate steps:

• For a page or section of the site, define the "Editors", "Approvers", and "Publishers" for that page.
• For a workflow, indicate rights in terms of those 3 categories, rather than SilverStripe Users/Groups.

This would mean that the same 3 step workflow can be used in one part of the site with some users, and in another part of the site with other users.

Now, of course, "Editors", "Approvers", and "Publishers" wouldn't be hard-coded - you would want to define these based on the workflows you have available. There are a few options for that:

• Define these roles side-wide
• Define these roles on a workflow-by-workflow basis

The former would make a lot of sense if you were trying into an overall ACL system. The second one is more precise, but requires that a workflow is chosen before a users/groups can be assigned to those roles.

Minor usability improvement: add clock icon or similar to sitetree pages that have a publish/unpublish date set

While viewing the sitetree it would be useful to see which pages have a publish/unpublish date set, this could be achieved by a clock icon at the right side of the label or above the page icon.

Workflow action buttons should not take their label from workflow actions

After a recent internal conversation the following issue has arisen:

Currently buttons in the UI attached to SiteTree objects for example, take their labels from the name of the workflow action to which they relate.

Now depending on who creates the workflow(s) in the system, these may or may not make sense to authors and editors, worse, they may serve to confuse.

One idea is to set a standard/default button label for these buttons, e.g "Submit for approval". The problem one immediately conjures however is that the range of workflows able to be setup and managed by the module are such that "Submit for approval" may only be valid for a certain type of workflow ie "A simple 2 step approval workflow" and not for any other workflow type.

A simple and partial solution may be as follows: In the process of workflow creation, an additional field is made available on each action whose value is displayed as the button label. The idea being that what makes sense for an action name to a CMS admin and a content-author, may be poles apart. Initially this might be configurable only at point of workflow creation.

This at least allows for workflow creators to liaise with authors as to what would make sense for them in terms of button text, while workflow creators can label their actions differently if they so wish. The default would therefore be, if no button-text is entered, the action-name shown instead (current behaviour).

The email "To" field is not populated with the assignees' email address

No matter how I populated those 'Users' and "Groups" during creation of WorkflowDefination / WorkflowAction, it seemed the notification emails are never able to populated with "To" address, though some assignee's email are picked up into "Bcc". For a email and for some mail server, "To" is mandatory, "Bcc" is not supplementary. So I would consider this as an issue.

Additional UI widget or indicator for content workflow status

Once a workflow reaches a particular stage, there may be the case where certain users or user-groups need to intervene - say to "Reject" or "Publish" content (In the case of a simple "2 step approval workflow" for example).

Currently, the only indicator to these users that some content - as part of a workflow - requires some sort of action on their part is a). a new button at the foot of that page whose label corresponds to the effective workflow's relevant action and b). (In development) a "report" (See issues/28 #28).

It has been suggested that an additional piece of UI wizardry be added to content-objects in the CMS with an attached effective workflow, as a more obvious indicator to users that - that content requires an action on their part.

Potential solution(s)

1). Background colour change of the CMS main content pane, or some part of it (right off the top of my head, that one..)
2). A growl-type message at the top-right
3). A coloured-strip along the top of the CMS main-content area much like the ones that display "page-saved" type notifications.
4). A coloured breadcrumbs-like trail, dynamically built from the effective workflow, clearly indicating to users, at what step of the workflow, this content is currently at.

Note: It should go without saying that each of these will require discussion and design before any development is begun.

Plain text vs html emails

The NotifyUsersWorkflow action currently sends emails as html, so if you enter plain text in the email template all the line returns are gone. If you enter html text then the textarea is quite small and not ideal for editing such content. The issue is that the action does not detect a plaintext email body and send using Email::sendPlain.

A solution could be for the action to have the ability for the user to specify either plain text or html format, this would then change the edit action form field from a TextareaField to an HtmlEditorField.

Also it would be nice that if there was a .ss template present for the notify emails for there to be some indication of this in the edit action form, to inform the user that they don't need to edit the email body in the action.

Enhancement: Add ability to copy/paste a workflow

This is really only useful when coupled with issues #16. If a default workflow is created on install, it is unlikely that it will not need changing and will "just work" and 100% suit the organisation using the system at that time.

What might be good therefore, would be the ability to select a "copy" icon in the gridfield entry for the default (any?) workflow which duplicated it (only the workflow, no object targets need be included) and dropped it into the UI directly below, using the name "<original_workflow_name> (Copy)" for example.

This would then allow workflow users/admins to use the original workflow as a reference point without "destroying" it, or needing to reinstall the module.

Alternatively, using the templates idea (see issue #18), instead of "copy/paste" as above, there was simply a button alongside the "Create Workflow" button, labelled "Re-create Default Workflow" which did essentially the same thing, but according to a stored default-workflow "template".

"Update workflow" action usability issues

In order to update the workflow, you need to open the WorkflowActions tab. However, the "Update workflow" button appears at the bottom of the UI.

I would recommend either moving the "update workflow" button to reside within the tab, or do show each applicable workflow action as a separate button down the bottom of the form.

@clarkepaul might have some useful insight here, he's spent a lot of time on the default actions panel.

Cant add a workflow fransition when using SS3.1, exception thrown.

Due to introducing UnsavedRelationList in SS3.1, when creating a WorkflowTransition, the edit form for the newly created object has an 'Users' CheckboxSetField which tries to preload data from an user list of UnsavedRelationList, that will result in calling getIDList() on the UnsavedRelationList object, however, UnsavedRelationList::getIDList() function throw LogicException.

So, the issue is down to the question that why we trying to preload an form from not-yet-existed (only in memory but not yet in DB) object?

Tooltip/literalText on AssignUsersToWorkflowAction

Some additional label-text on the popup dialogue for a
"Assign Users To Workflow Action" would be useful, indicating to workflow-creators and admins that this label will become the text on the button that authors will press in order to enter some changes into a workflow.

Add Workflow Action Name to each row in the workflow CMS interface

Adding the workflow classname to the default workflow admin view for clarity when editing/managing workflows, will greatly aid workflow admins to see at a glance what sort of action, their own names-for-actions, relate to.

Currently this is only displayed in the action popup dialogue.

Translatable links still broken in some places

Steps to replicate:

• attach workflow to a page
• initiate a workflow on the page
• go to workflow section
• try to click on the links in the two of the top listings (e.g. pending workflows)
• the link is http://localhost/recipe-basic-1.0.0/admin/pages/edit/show?locale=en_NZ/2

Could be related to #104

Ability to create transition with same "Action" & "Next Action" selections causes error

Having created an action on a workflow, create a new transition on that action; Add a title and use (howsoever stupidly) the same value for the "Action" and "Next Action" dropdowns, then press "save".

Observe the message "There has been an error" in the transition dialogue.

Now reload/refresh the CMS via your browser, observe the erroneous transition has now been appended to the selected action entry in the main CMS pane. This also occurs if one creates a non-erroneous transition immediately subsequent to an erroneous one; Upon pressing "Save" both the new non-erroneous and previous erroneous transition are appended to the DOM - the latter without a title, even though one was added and is required to be added.

Having reproduced the above issues, try to create a new transition on the same action. This has inconsistent results for me in FF15 OS X, but will occasionally result in empty dropdowns in the popup dialogue. If reproducible, reloading the page and trying again "fixes" it.

My suggestion is that users are prevented from making the same selections from the 2 dropdowns by either dynamically disabling the respective option in the 2nd dropdown or validating user-selections and presenting a message accordingly.

Regardless of the above having been fixed, there may still be a more general issue when errors are displayed for a different reason in that transitions having exhibited an error, will still be appended to the DOM.

FF 15 OS X 10.7.4

Support for timed transitions

I'm currently looking at expanding the advancedworkflow to support timed transition. For example notifying content reviewers that they should have a look at something. I'm dumping a couple of ideas on how to support this. I'm keen on getting @nyeholt and @sminnee ideas on this.

Allow multiple workflows for a WorkflowApplicable extended objects

This allows us to configure multiple workflows per objects. Another approach would to use some sort of hierarchial state machine pattern or a state machine with decision trees, but I think that would complicate this a lot more.

An example would be to have:

• A workflow that updates the state based on user actions in the CMS.
• A workflow that updates the state based on time.
• And another one that updates the state from external influences, i.e. web services.

This refactoring includes changing the WorkflowApplicable from

public static $has_one = array(
    'WorkflowDefinition' => 'WorkflowDefinition',
);

to

public static $has_many = array(
    'WorkflowDefinitions' => 'WorkflowDefinition',
);

.. and change all the relevant UI elements to support that.

Create Transitions that are triggered via timers

Waiting for review - initial state

• transition to State.Notificated (timestamped)

Notificated

1. on entry: send email to content owner
2. on entry: send email to administrators group

• transition to State.Renotificated (x days later)
• transition to State.Published

Overdue

1. on entry: send email to content owner
2. on entry: send email to administrators group

• transition to State.Renotificated (x days later)
• transition to State.Published

---

This will require transitions to be able to save triggerstamps persistance so it can be queried and exectuted. Most likely with the help of the queuedjobs module.

How about creating a WorkflowTimeTransition?

Other refactoring ideas

Break out Create state from WorkFlowAction

The current state should should reflect which state the current Workflow is in.

A State can have:

• getEntryActions
• getActions (that are run every time the workflow is queried for updates)
• getExitActions

It changes the perception from actions to state:

Example:

Waiting for approval - Initial state

1. on entry: send notification email to Publisher (action)

-> transition to State.Approved
-> transition to State.Rejected

Approved

1. on entry: send notification email to Author (action)

• transition to State.Published

Rejected

1. on entry: send notification email to Author (action)

• transition to State.Waiting for approval
• transition to State.Abort

Published

• on entry: Publish article (action)
• on entry: close workflow (action)

Abort

• On entry: send email to Author and Publisher (action)

This makes states a bit more lightweight and are basically just placeholders for actions.

Allow Transitions to have actions

Good for sending notifications or scheduling embargos / offline tasks

This separates states from actions and makes actions more generic and it's easier to visualize the workflow.

ENHANCEMENT: Edit and Delete icon visibility

• The "edit" and "delete" icons for transitions within a workflow definition appear too close to one another.
• These buttons use iconography only unlike their parent actions, which use a text label for the button also.
• Some "definition" for each button may help too - e.g. a light box-shadow

Note: Before working on this, consult Bee (Science Ninjas Designer) as she may have some ideas for UI improvements here.

Incorrect spacing above GridField under "Active" & "Completed" subtabs

Switching between the "Active" and "Completed" subtabs, an inconsistent space can be observed above each GridField. This seems to occur regardless of whether the GridField contains any rows or not.

Firefox 15 / Chrome 22 OS X 10.7.4