Best practices for roles and permissions

On a current XP installation we have three sites, and some 1000+ authenticated users. Most of the users are automatically put in a group called “bloggers” upon creation. Bloggers should be able to publish content in one or two particular paths. Editors (another group) should be able to edit most content. We also see the possibility that we need further granularity in the future.

A simplified hierarchy looks something like this:

+- /siteA
|     /about (only editors)
|     /blog (bloggers)
|
+- /siteB
|     /about (only editors)
|     /blog (bloggers)
|     /system (only sysadmins)
|
+- /siteC
|     /about (only editors)
|     /system (only sysadmins)

While mighty powerful, one might argue that Content Studio is also somewhat complex and daunting to users not using it daily. So ideally I’d like to hide all content in content studio not editable by the bloggers.

At the same time, I need to give all content read permissions to the Everyone role, so it’s accessible at all to the public.

Is this at all possible to accomplish? Have I just overlooked something obvious?

Also, it would be great to be able to limit the content types users can create. As far as I can see there is no option for limiting available content types based on permissions? Is this on the XP roadmap?

1 Like

[quote=“nerdegutt, post:1, topic:1121”]…So ideally I’d like to hide all content in content studio not editable by the bloggers.

At the same time, I need to give all content read permissions to the Everyone role, so it’s accessible at all to the public…[/quote]

In addition to the Everyone role, there is an Anonymous user. It should be enough to give Anonymous read permissions on all content and at the same time make sure Everyone does not have read permissions.

EDIT: to clarify, when a person is not logged in (such as someone just visiting the webpage), that person is acting as the Anonymous user. As soon as a person has logged in, there is no longer any connection between the logged-in user and Anonymous. In contrast to the Everyone role, which always applies.

Hi Nerdegutt,

So, first of all Content Studio will never hide content elements from the grid. If you cannot edit it (don’t have the proper access rights) we will dim it slightly. But we see that when installations grow ever more complex, with perhaps even “secret” sites created on the same installation as other sites, there is need to fully hide content.

This is in the backlog, but I will need to get back to you after the summer to say anything about an ETA. Right now the focus is on getting 6.11 ready.

So, no, you have not overlooked anything =)

The last thing is also something I’ve heard requested many times, especially during training sessions, but again I also need to get back to you after the summer. It is in the backlog, just not a top priority over the many other exciting features we have planned.

If you want to keep better track of your two suggestions here, I recommend you create two separate threads - one for “Fully remove/hide content items in grid you can’t edit” and one for “Control who/which privileges can use which content types” - in the Feature category here in the forum (or directly on the xp-project in Github).

Lastly I can just say that using groups in the User admin tool for handling access rights is very much best practise =)

Thanks for the suggestion. I actually thought of this, but it means that whoever is logged in can only see the blog content on the published web whenever they’re logged in. This would be a no-go, as a lot of internal users would be logged in a lot of the time.

Right you are Erlend! The anonymous user should rarely be used. That said, the reason why items with “everyone” are visible to everyone even in content studio is not only the read-access, but the fact that one might need to link to some of these items. Also, there are times when the items you have write access to are further down the tree, and this will require you to browse down a lot of grey items to get there.

We have already promised functionality to hide whole sites from users which should not work there, but within a site what you see will still be there in the known future.

1 Like

On @bwe 's good advice, I’ve created two separate XP issues for these matters.

Fully remove/hide content items in grid you can’t edit
Control who/which privileges can use which content types

I see your point here. Perhaps them, and as I’ve partly argued in the github issue, we could simplify this a bit, to be more of a display filter in it’s nature. Meaning it only limits what you see in the drilldown grid, but you can still read all content in the editor views. I guess such an approach would be much easier, as you don’t mess with permissions, only visibility based on content being editable by you or not.

1 Like