Community Role permission change in 6.6

Rhythmyx Ideas and Feature Requests
1

Several situations have come up relative to roles and communities and how the filtering of permissions impacts design, such as

and

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:

Community_a
Editor_a role
Author_a role

Community_b
Editor_b role
Author_b role

Now a SINGLE “Workflow C” could be used for items in both of the above as follows.

Approval State
Editor_a assignee
Editor_b assignee
(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.

2

Hello,

I’m not sure if I’ve understood you completely. Is the following an accurate summary of what you are proposing?

Each user’s ability to edit content items, and transition them to different states, will be determined by whether one of their roles is also:
[ul]
[li]A role assigned to the workflow of the content item
[/li][li]A role assigned to a possible state in that workflow
[/li][li]And, new to 6.6, that the role is assigned to the community of the content item
[/li][li]But, unlike in 6.5.2, it won’t matter what community you are logged into at the time
[/li][/ul]
However, the community you are logged in to will determine which other menu options you get (e.g. previews, purge, etc.) And the roles of the user will still determine folder visibility and what community any new items you create will be assigned to.

Thanks,

Andrew.

3

[QUOTE=Andrew Morrison;2913]Hello,

I’m not sure if I’ve understood you completely. Is the following an accurate summary of what you are proposing?

Each user’s ability to edit content items, and transition them to different states, will be determined by whether one of their roles is also:
[ul]
[li]A role assigned to the workflow of the content item
[/li][li]A role assigned to a possible state in that workflow
[/li][li]And, new to 6.6, that the role is assigned to the community of the content item
[/li][li]But, unlike in 6.5.2, it won’t matter what community you are logged into at the time
[/li][/ul]
However, the community you are logged in to will determine which other menu options you get (e.g. previews, purge, etc.) And the roles of the user will still determine folder visibility and what community any new items you create will be assigned to.

Thanks,

Andrew.[/QUOTE]

That is correct, with TWO additional points, primarily for backwards compatibility reasons.

  • Roles NOT associated with ANY communities will be treated as a match always. That is, if you don’t want the new “community specific” role behavior, just don’t associate Roles with Communities (leave them as they are today in most cases). If you DO want it, then associate roles with Communities and/or create new roles to do so.

  • Permissions and session (logged in) community behavior will change as stated, but only in the context of the Enhanced Business User UI (aka Active Assembly) coming in 6.6. There will be a more dedicated post on this aspect of 6.6 later on, as well as previews of it online. In a nutshell, for 6.6 we’re expanding Active Assembly, essentially merging it with the Action Panel, and many functions currently only found in Content Explorer (such as Create New (e.g. New Page), Compare, Translate, etc.) You will have the option in a 6.6 system of having an entire class of users that never (or at least very rarely ever) need the Content Explorer. In the context of that usage, permissions will be based on what is possible, not based on the logged in Community. The are deeper reasons for this, however, since in Active Assembly, there is always a user context that is operative - the page/template, the site, etc. from which to make the UI smarter about this kind of thing. The main area that will be limited in 6.6 will be the folder browser, which will only come up contextually (e.g. to find a item to place into a slot) but as in 6.5.2 is a fully functional browser, at least for those tasks.

Even more will come in the area of UI after 6.6, but basically think of the direction as a bifurcation:

Business Users some Power Users (marketers, content experts, etc.) - live in something that looks like the site or a page (Active Assembly is the closest today), and can “drill down” only if needed/desired into things like folders and meta-data. (today we force them to start in folders and metadata and “drill up” into the friendlier visual Active Assembly).

Administrators, Power Users - live in the Content Explorer, primarily messing with overall system functions, like publishing and managed navigation, using global admin tasks like purge and mass move items to/from folders.

Again, I’ll be posting more on this to come in a more cohesive way when I pull that info together. I only wanted to address the permissions thing in this thread for now. 6.6 is slated for the end of this year, so we’ve got lots of time to get up to speed on it as the weeks and months go by.

4

Still chewing this over:

By “associating a role with a community,” you mean the roles might be called:
Marketing (community role)
Research (community role)
Editor_Marketing
Author_Marketing
Editor_Research
Author_Research

By “not associating a role with a community,” you mean the roles might be called:
Marketing (community role)
Research (community role)
Editor
Author

Is this correct?

5

[QUOTE=mdmcginn;3580]Still chewing this over:

By “associating a role with a community,” you mean the roles might be called:
Marketing (community role)
Research (community role)
Editor_Marketing
Author_Marketing
Editor_Research
Author_Research

By “not associating a role with a community,” you mean the roles might be called:
Marketing (community role)
Research (community role)
Editor
Author

Is this correct?[/QUOTE]

Not sure I understand the example. Partly I think the example above is not well suited, since community is not really about “Marketing” vs. “Research” which would more likely be two roles in the same community. You wouldn’t really have a Marketing community.

Communities are used to sub-divide a Rhythmyx system when a corporation has semi-independent sub-divisions, typically with a site being managed somewhat autonomously by that sub-division. Sometimes an overall “admin” community is also used. But in general, only create a community if you know you want a pretty formal subdivision within a Rhythmyx system. If all you area trying to do is limit permissions and access and UI, just use roles period, often, lots of roles.

Now supposing you DO have a need for a multi-community setup. Say for example you have many corporate sub-divisions, each with their own Web sites, own look and feel, different global templates, etc. So to support that you created several communities. Community “A” is for the “Acme Division” and the site Acme.com. Community B is for the “Beta” Division and Beta.com site, community “G” is for the “Gamma Division” and the site Gamma.com, and so on with many more divisions and sites (note: not ALL multi-site systems should do this!!)

In systems like that, a problem occurs when many of these divisions and sites want to share the SAME workflow process. For example suppose ALL the divisions have Marketing and Research departments, and all the sites require a marketing approval and a research approval before content can go live.

With this change, you can build ONE general workflow and re-use it across all the communities.

The setup would be:

Community A (not a role, a community!)
Marketing_editor_A role (members of marketing with editor level approval who work in the Acme division)
Marketing_author_A role (members of marketing with author level approval who work in the Acme division)
Research_editor_A role (members of research with editor level who work in the Acme division)
Research_author_A role (members of research with author level who work in the Acme division)
(possibly other objects specific to Acme division and site would be associated to this community as well)

Community B (not a role, but a community)
Marketing_editor_B role (members of marketing with editor level approval who work in the Beta division)
Marketing_author_B role (members of marketing with author level approval who work in the Beta division)
Research_editor_B role (members of research with editor level who work in the Beta division)
Research_author_B role (members of research with author level who work in the Beta division)
(possibly other objects specific to Beta division and sites would be associated to this community as well)

etc.

Then create ONE workflow “General Approval” as follows, assuming content can be drafted/authored by anyone in the author level.

draft (state)
marketing_author_a role
marketing_author_b role
research_author_a role
research_author_b role

marketing approval (state)
marketing_editor_a role
marketing_editor_b role

research approval (state)
research_editor_a role
research_editor_b role

public (state)
etc.

Now, content items in either community A or B can flow through the same workflow above, but only the roles that match the community will have access to the items.

If you then wanted to have a group of say “super marketers” and “super researchers” that operated equally across all communities (all divisions and sites), you could simply create roles for them and leave them NOT associated to any community.

For example:

(no community)
Marketing_editor role
Marketing_author role
Research_editor role
Research_author role

Then, whatever states you want anyone in these roles to have permissions regardless of the community, then add those roles into those states.

6

Thanks, Vern. That’s helpful. I am indeed concerned about limiting permissions and access and UI. We’ve planned to create one site per community, and to make the site folder visible only to that community. An Admin in one community could theoretically add and delete content in another community, except he or she can only see one community.

Believe me, at our university, Marketing and Researchare very independent divisions, with each site being managed completely autonomously by that division. We have thousands of such sites. The way I am planning to do it, we could end up with a thousand communities using four roles and hopefully one workflow. I hope you’re not suggesting that I create four thousand roles instead. It seems to me that I need to apply some variation of Occam’s razor just to keep from drowning.

7

I would start from the basics and work up - that is, not a Rhythmyx modeling question, but a business modeling question. The reason for “four thousand roles” would be because there are really that many different groups of users that need to be separated by permissions. If this seems too much, then what else separates these users and how could an automated system know that?

Some questions to ask:
What property of a user tells you that they “go with” a particular site/community?
Does that property already exist somewhere, in LDAP, Active Directory?

There may still be the need to use the API to further automate this in your case. Not many clients have 1000 independent sites all under one system - usually more like dozens. But there are answers available. For example, based one customer with 600 sites, we built a “create branch office site” button using the Web Services SDK. An admin would create the button, enter a name, and the back-end API calls would create a bunch of stuff, from site folders, to navons and even a sample landing page. (Note: this was a prototype and they ended up using another approach in production.)

Again, for a few dozen sites, the investment in such a thing may not be worth the time to code it, but for 1000 sites, it just might be the way to go.

Regardless, the first thing is to pull back a bit from Rhythmyx objects and how they might work, and instead get a good picture of the actual business model.

8

I just checked, and our Google Search Appliance crawls 2,977 subdomains, not all of which are active sites, and not all of which have separate web teams. But we still have quite a lot of sites!

9

Will this address any issues regarding menu visibility according to role?

It would also be extremely useful to have the facility expanded to include folders, e.g. limit content types by role and folder.

10

I’m confused. Our implemetation has one workflow, two sites, three workflow roles, and over 200 communities with matching community roles. Permissions revolve around folder community setting.

How will this change affect us (should we choose to upgrade)? Will I have to create 400+ roles? I probably didn’t get this right…

11

[QUOTE=slolic;3653]I’m confused. Our implemetation has one workflow, two sites, three workflow roles, and over 200 communities with matching community roles. Permissions revolve around folder community setting.

How will this change affect us (should we choose to upgrade)? Will I have to create 400+ roles? I probably didn’t get this right…[/QUOTE]

Existing behavior will not change. If you have no issues with the model now, it will continue.

This change ADDS the option to utilize an currently ignored type of role-to-community association, and then to use that association to solve a specific workflow modeling problem some customers have raised.

Using folders to augment permissions by community or role, among many other permissions options folks currently use, will not change (and in fact, is still recommended.)

12

After having implemented our own role and subject catalogers into production (which I believe seems to have fixed a number of related issues with certain functionality) I can’t help but wish that one of the parameters passed to the catalogers would be community id / name. This would allow us to only give Rhythmyx the appropriate roles for the individual for that community (without giving all the user’s roles).

Our catalogers go against ldap in which we have defined community specific groups (and thus are able to allow web-admins of specific communities to add members to their respective community workflow roles), but all of this eventually cascades down (or up) to a generic workflow role which we then assign the user (in broad terms). So in the end, the Rhythmyx works the same way where there are no community specific roles. Having the community information passed on to the catalogers would allow us to very easily pass back community specific roles to Rhythmyx.

I realize that this would mean a lot(!!) of changes in the back-end (especially with login to a given community), and we are a special case (and so is every Rhythmyx customer), but in terms of our implementation, this would be a lot nicer than new workflow roles for each community.

Now that what we would like is out of the way :), I do think that having this permission change is a step towards the right direction, but we would be in the same boat as mdmcginn in the number of communities and the overhead of trying to manage new workflow roles.

13

Please could someone give the manual name and page number(s) where this is documented in the 6.6 manuals.

Thank you,

Andrew.