Several situations have come up relative to roles and communities and how the filtering of permissions impacts design, such as
Though 6.6 does not address workflow directly, we are making a small change in 6.6 which should help to address this greatly. I post it here for discussion.
Today, when we evaluate the user’s permissions for an item, we look at the roles and assignment types assigned to the state the item is in, aka the “state-roles”. We then look at the user’s roles or “user-roles”. We match any state-role to user-role, and give the user the highest assignment type of ANY of the matches.
In 6.6, we will make the state-role to user-role match community specific. That is, we will check each state-role to user-role match and use the matching role ONLY if that role is included in the same community as the item’s community.
Note also that in general the “session community” (the community one is currently logged in under) will not matter in the evaluation of user permissions at all. That is, you have the permissions you have because of the state-role to user-role matches (and the community of the item and how that filters the match as above). If you have the permission, you will be allowed to act on that item, even if you are logged into a different session community than the item community. The Session Community will only dictate the community of any new items that are created during that session, and any other visibility (not permission) rules that have been put into the UI.
This change will still require lots of roles, but will NOT require lots of workflows or states. That is, if you have more or less the same process, but lots of sites and communities that want to “share” the common workflow definition, you can.
For example, designers will be able to set up things like the following:
Now a SINGLE “Workflow C” could be used for items in both of the above as follows.
(all others reader)
Only users in “editor_a” role would be granted assignee rights to items in community_a that were in this Approval State. Users in “editor_b” role would not have assignee access, even though the item is in that state, it is in a community that is not associated with the “editor_b” role.
You still need lots of roles, to actually contain the different users working in each community. But only one (or a few) fundamental Workflows will be needed.
The other changes for 6.6 relative to workflow are mostly in the UI, and having it be a bit more forgiving (for example, perhaps automatically checking the item out to you if you click to edit it, the item is not checked out by someone else, and you have the rights to edit it.) In general the idea is for the server to see if there is a path to whatever action you just initiated, and if there is, take that path for you rather than force the user through each required sub-action. More on any of these changes will be posted later.
But again, the more comprehensive workflow changes are planned for the release AFTER 6.6, but they are more entwined with the more radical UI improvements coming in that release.