Who can do what, and where

Posted in: Beta, Content design, Content Publisher

We now have over 100 people using the new CMS, drawn from 48 organisations and 28 groups. We also recently crossed the threshold of 1,000 content items in the CMS (woohoo!) And aside from organisations, all those numbers are bound to go up.

How do we make sure that users:

  • see only the content that's relevant to them, rather than every single thing in the CMS?
  • can edit only the content their organisation or group is actually responsible for?
  • can feature only the most relevant content on their landing pages?

The answer comes down to permissions – both for users, and the organisations or groups they belong to.

Organisations and groups

Content items aren't owned by individual users, but entire organisations or groups. Users access that content by being members of the right organisation or group.

Organisations are top-level entities within the University, like the Institute for Policy Research or the Department of Marketing & Communications.

Groups are smaller entities within organisations, like research groups or Digital Marketing & Communications.

An organisation that contains a group is called the "parent" of that group.

Three types of permissions

Whether you can or can't do something in the CMS comes down to three things:

  1. What your role is (admin, contributor, etc)
  2. What organisations or groups you belong to
  3. What organisations or groups an individual content item belongs to

The third factor also affects how and where pages appear on the published site, like landing pages or lists of content.

The user's role

We have four levels of role in the CMS, which we've cribbed from WordPress:

  • Contributor – can create and edit pages, but must pass them on for review by an Editor or Admin to publish anything
  • Author – can create, edit and publish pages on their own, or pass them on for Editor or Admin review
  • Editor – responsible for editing, reviewing and publishing pages, as well as curating landing pages
  • Admin – infinite godlike power (like deleting pages, or setting up organisations and groups)

They're a bit more complex than that, but you get the idea. You have the same role for any organisations or groups you're a part of, so an Editor is always an Editor, whether they're in an academic department or a research group.

The user's organisations and groups

If you're using our CMS and you're not an admin, what you can see and do depends on what organisations and groups you belong to. Everyone has one primary organisation or group, but some people can be associated with others as well.

This includes:

  • which individual content items you can access and edit
  • what you see on the CMS dashboard's list of existing content
  • what organisations or groups you can filter by to narrow that list down

Filtering within the CMS is a new (but useful!) feature for us. All users can filter by any org/group they're part of, and filtering will show any content owned by the chosen org/group.

This does mean that if a content item is owned by another org, but associated with yours, you can't filter by the owning org, because you're not part of the owning org – but you can still see the content in the list of everything.

The content item's organisations and groups

What org/group a content item belongs to determines how orgs and groups can use that content, including:

  • pinning content to landing pages
  • including content in filtered list pages of org/group content (like all Guides owned by Student Services)
  • declaring who's responsible for content on the page ("document navigation")
See that little grey box with "Student Accommodation" in it? That's who made this page.
See that grey box with "Student Accommodation" in it? That's who made this page.

How it actually works

What an organisation or group can do with a content item depends on its level of responsibility for that content. There are three possibilities:

  • owner – the org/group primarily responsible for the content item
  • associated – an org/group with secondary responsibility for the content item
  • parent – an org that includes the group which owns the content item

Every content item in the CMS must be owned by a single organisation or group. But it can also be associated with multiple additional orgs/groups if needed.


The owner org/group has a lot of options for what they can do with a content item. It can:

  • pin it to their landing page
  • include it in a filtered list of all its Guides
  • be named at the top of the page in the document navigation

And its users can:

  • edit the item
  • see the item in the CMS dashboard's list of all available content
  • filter that list to only show content owned by that org/group


The users in an associated org/group can still edit the content item, and they can still see it on the unfiltered dashboard. But they can't filter by orgs/groups they're not part of.

The org/group itself has even fewer options. In fact, it can't currently do any of the things the owner org/group can. As far as people viewing the published site are concerned, it doesn't have anything to do with the page at all.


Users in the parent org have the same power as users within the child group. They can still edit the page, see it on their dashboard and (if the child group is the owner, not associated) filter by that group's name.

But when it comes to output, the parent org is still as limited as any associated orgs/groups. Its landing page can't feature the item and it won't show up in lists of their content, or even get its name on the page itself through the document navigation.

Filling in the gaps

So at this point, associated and parent orgs/groups might be feeling a little hard done by. But it's cool, we've got plans.

  • document navigation – we're working on updating our document navigation this sprint to include the names of associated and parent orgs/groups
  • pinning items to landing pages – we've got stories in our backlog to allow associated or parent orgs/groups to pin content too
  • lists of content – we've also got a story to include associated content in filtered lists of an org/group's content, not just the stuff it owns

We're not just building features – we're also building our knowledge. A single change can have a lot of knock-on effects elsewhere. But working iteratively means dealing with frequent, small changes, rather than big, complicated ones, so it's easier to keep our knowledge up-to-date. And that knowledge is important for making the right decisions and advising our publishers.

Getting to grips with this complexity is a lot easier with good documentation – and a reminder that it's worth putting that extra time in writing it up now, rather than get confused later.

Posted in: Beta, Content design, Content Publisher


  • (we won't publish this)

Write a response