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

[sminnee]

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.

[nyeholt]

Would it be something that could be determined once a workflow was applied to a specific content section? Say there's a workflow definition that has 2 points of assignment to different groups; once applied to a subtree in the site, a separate section appears on that node that has 'Select users/groups for assignment to ****', with as many selections as needed available?

[sminnee]

Yeah that solution makes sense to me, particularly if you're applying a default workflow to the entire site in the site config up front.

The other tweak I'd make is probably to have the UI have a radio button saying "choose users" or "choose groups" and then showing the relevant selector field. The current UI was a bit confusing, as in "why do I need to choose users and groups?" ;-)

[nyeholt]

It's probably tough to determine without having some usage stats as to what the 'best' way forward is, but there's a few issues I see with a 'global' workflow definition that's moulded to fit relevant sitetree sections

• leaking of workflow settings into the content area of a system.
• if one section required a change to how the workflow was configured (eg an additional step, change to notification template etc) then it affects all other sections. You could keep pushing some of those settings into the site tree for runtime detection, but where do you stop?
• It's harder to split reporting on workflow for separate site sections if they're all running from the same definition (not a big deal, but a consideration)

[sminnee]

Good points. My main concern is that workflow can be set up very quickly, but perhaps templates are a better way of dealing with this?

One thing that may be appropriate with templates is to be able to "lock" a workflow to a template, such that any updates to the template are reflected in all its instances.

The advantage is that you therefore get what I'm trying to achieve here: one place to edit the workflow config simpler cases (although admittedly that place is in code, not UI)

It also makes deployment of workflow config from UAT to prod easier.

[nyeholt]

Just assigning this to myself as it ties in with #16