More Flexible User Permissions and Roles

Description:
Right now, Ghost has a fixed set of roles (Contributor, Author, Editor, Administrator) with set permissions. While this works for simple setups, it’s not ideal for teams with multiple contributors and editors.

For example:

  • Any role (except Contributor) can publish posts.
  • However, users can’t see or edit draft posts created by others unless they have full access.

In a real editorial team, this creates confusion. Contributors draft posts, but editors can’t easily review or manage them before publication. It becomes messy when multiple drafts are in progress.

Feature Request:
It would be great to have more flexible permissions, such as:

  • Allow certain roles to view and edit all drafts, without giving them publishing rights.
  • Separate “edit” and “publish” into different permissions.
  • Ability to tweak existing roles or create custom ones, depending on the workflow.

This would make it much easier for editorial teams to stay organized and work smoothly.


Unfortunately, I don’t have the programming skills to make a pull request myself. I hope others also see the value in this and would be willing to pick it up. I’d be more than happy to think along and help test if that’s useful! :blush:

Yes, I need there to be a contributor role which can edit and add to post that I have started. But it says contributor can only write ‘their own posts not those of others’. Not much use for collaborating on a particular piece with someone external…

What do others do for that?

For your specific case, add them as a listed author on your post. (You can always remove them later.)

You’re unlimited in the number of contributors you can have, so inviting external people to be contributors is the way to go, if you want them to be able to edit.

Note: Although Ghost’s dashboard doesn’t let contributors edit drafts that they aren’t authors of, that’s actually just a dashboard level constraint. Contributors can technically read any draft post, via the API, so do choose who you invite with a little care. I think about contributor tokens at the API level as being read-only plus draft-creation for posts. Does this matter for your use-case? Probably not, but I figure it’s better to know that you’re trusting a contributor a little bit more than might be obvious than to be surprised later.

This is very helpful. I only have a limited number of authors so this is manageable. I will try implement it through the API.