Book-scope role membership (Custom User<=>Role relation per book) #762

Closed
opened 2026-02-04 22:12:03 +03:00 by OVERLORD · 19 comments
Owner

Originally created by @justein230 on GitHub (Aug 1, 2018).

I would like to be able to add "Book Admins" and "Book Editors" instead of just allowing one user to either edit all books or edit no books.

Describe the benefits this feature would bring to BookStack users
This would make the platform more extensible and make permissions more granular.

Additional context
Proposed feature set:

  • Roles are created globally, and have a default permissions level, and a default set of members (meaning the members at the global level will be a member of that role for all books).
  • Roles can then have per-book permissions (meaning that a user can be an editor of only one book, but only a viewer of all the other books)
  • If a user has a higher level of permission at the book level than the global level, apply that permission
Originally created by @justein230 on GitHub (Aug 1, 2018). I would like to be able to add "Book Admins" and "Book Editors" instead of just allowing one user to either edit all books or edit no books. **Describe the benefits this feature would bring to BookStack users** This would make the platform more extensible and make permissions more granular. **Additional context** Proposed feature set: - Roles are created globally, and have a default permissions level, and a default set of members (meaning the members at the global level will be a member of that role for all books). - Roles can then have per-book permissions (meaning that a user can be an editor of only one book, but only a viewer of all the other books) - If a user has a higher level of permission at the book level than the global level, apply that permission
OVERLORD added the 🔨 Feature Request label 2026-02-04 22:12:03 +03:00
Author
Owner

@ssddanbrown commented on GitHub (Aug 6, 2018):

Hi @justein230, Sorry for the late reply. Your general request should already be available.
On any book, chapter or page you can click the 'More' menu in the top right then select permissions. You can then choose local permissions here which will override the global role-level permissions.
Permissions will cascade down from Book > Chapter > Page.

Let me know if that helps or if the current solution is lacking in any way.

@ssddanbrown commented on GitHub (Aug 6, 2018): Hi @justein230, Sorry for the late reply. Your general request should already be available. On any book, chapter or page you can click the 'More' menu in the top right then select permissions. You can then choose local permissions here which will override the global role-level permissions. Permissions will cascade down from Book > Chapter > Page. Let me know if that helps or if the current solution is lacking in any way.
Author
Owner

@justein230 commented on GitHub (Aug 13, 2018):

That's what I was referring to with the per-book roles. Let's say, for example, that I have "Book1" and "Book2". I want to be able to provision editors for "Book1" and "Book2" at the local level. For example, user1 will be part of the "Book1" editors, while "user2" will be part of the "Book2" editors, and they will not be able to edit the other book.

@justein230 commented on GitHub (Aug 13, 2018): That's what I was referring to with the per-book roles. Let's say, for example, that I have "Book1" and "Book2". I want to be able to provision editors for "Book1" and "Book2" at the local level. For example, user1 will be part of the "Book1" editors, while "user2" will be part of the "Book2" editors, and they will not be able to edit the other book.
Author
Owner

@justein230 commented on GitHub (Aug 21, 2018):

Any update on this?

@justein230 commented on GitHub (Aug 21, 2018): Any update on this?
Author
Owner

@justein230 commented on GitHub (Sep 11, 2018):

Hi, just wanted to check and see if there was any update on this.

@justein230 commented on GitHub (Sep 11, 2018): Hi, just wanted to check and see if there was any update on this.
Author
Owner

@ssddanbrown commented on GitHub (Sep 11, 2018):

Hi @justein230,
I'm a bit confused of where this is at?

Did you try following the instructions in my previous comment, Using this menu option on your books:

image

Or are you looking for something else?

@ssddanbrown commented on GitHub (Sep 11, 2018): Hi @justein230, I'm a bit confused of where this is at? Did you try following the instructions in my previous comment, Using this menu option on your books: ![image](https://user-images.githubusercontent.com/8343178/45345534-8378ea80-b59e-11e8-9e79-ed88a5515b72.png) Or are you looking for something else?
Author
Owner

@justein230 commented on GitHub (Sep 14, 2018):

It is a feature request. The feature does not already exist. I'm looking into ways that I can do this myself and submit a PR, but wanted to know if a feature like this was on the radar.

@justein230 commented on GitHub (Sep 14, 2018): It is a feature request. The feature does not already exist. I'm looking into ways that I can do this myself and submit a PR, but wanted to know if a feature like this was on the radar.
Author
Owner

@battosai30 commented on GitHub (Nov 21, 2018):

I agree it would be a useful feature ;)

@battosai30 commented on GitHub (Nov 21, 2018): I agree it would be a useful feature ;)
Author
Owner

@ssddanbrown commented on GitHub (Nov 21, 2018):

Again on this one, Not really sure how this request differs to what's already implemented in BookStack. If someone could explain the difference between this request and the book-level role permissions already implemented that would be very useful for me.

@ssddanbrown commented on GitHub (Nov 21, 2018): Again on this one, Not really sure how this request differs to what's already implemented in BookStack. If someone could explain the difference between this request and the book-level role permissions already implemented that would be very useful for me.
Author
Owner

@justein230 commented on GitHub (Nov 22, 2018):

Right now, when a user is made part of the editors role, they have edit permissions on every book. Sure, you could restrict this with book level permissions, but then all editors wouldn’t be able to edit a certain book. What I would prefer is to have a global editors group, then have the ability to define per-book memberships. Example:

User A should have permissions to edit ALL books in the instance, but user B should only have access to edit Book 1. User A is part of the global editors list, and user B would be part of the Book 1 editors list.

Let me know if you need more clarification. Theoretically, you could make a role for each book, but that could get messy really fast... would be willing to help develop this feature but wanted to gauge interest before.

@justein230 commented on GitHub (Nov 22, 2018): Right now, when a user is made part of the editors role, they have edit permissions on every book. Sure, you could restrict this with book level permissions, but then all editors wouldn’t be able to edit a certain book. What I would prefer is to have a global editors group, then have the ability to define per-book memberships. Example: User A should have permissions to edit ALL books in the instance, but user B should only have access to edit Book 1. User A is part of the global editors list, and user B would be part of the Book 1 editors list. Let me know if you need more clarification. Theoretically, you could make a role for each book, but that could get messy really fast... would be willing to help develop this feature but wanted to gauge interest before.
Author
Owner

@beegedigital commented on GitHub (Nov 22, 2018):

I think what @justein230 means is that you can create permissions on a user basis. Currently you can only change permissions for whole groups of users. I think it would be nice if you could grant a single user permission to only one specific book or shelve. At the moment we work around this by creating new groups for single users. That's way too complicated.

With that it would be possible to create personal or private books for every user, that no other one can read.

@beegedigital commented on GitHub (Nov 22, 2018): I think what @justein230 means is that you can create permissions on a user basis. Currently you can only change permissions for whole groups of users. I think it would be nice if you could grant a single user permission to only one specific book or shelve. At the moment we work around this by creating new groups for single users. That's way too complicated. With that it would be possible to create personal or private books for every user, that no other one can read.
Author
Owner

@justein230 commented on GitHub (Nov 29, 2018):

@beegedesign A bit different from what I am proposing. I propose we allow a different role list per book. A user would be added to a role in Book A (say, read only role) which would allow them to have different role memberships per book.

@justein230 commented on GitHub (Nov 29, 2018): @beegedesign A bit different from what I am proposing. I propose we allow a different role list per book. A user would be added to a role in Book A (say, read only role) which would allow them to have different role memberships per book.
Author
Owner

@justein230 commented on GitHub (Nov 29, 2018):

Perhaps some graphics would help:
image

The image above is taken from Jira. You can see here that you can create roles. These role memberships can be different per Jira project (per BookStack book, shelf, chapter, etc. for this explanation). That way, we could use roles to define permissions, then put users into roles per entity instead of globally for all.

@justein230 commented on GitHub (Nov 29, 2018): Perhaps some graphics would help: ![image](https://user-images.githubusercontent.com/7889269/49190409-208a2a80-f327-11e8-8003-90491f94f1cf.png) The image above is taken from Jira. You can see here that you can create roles. These role memberships can be different per Jira project (per BookStack book, shelf, chapter, etc. for this explanation). That way, we could use roles to define permissions, then put users into roles per entity instead of globally for all.
Author
Owner

@lindsayschm commented on GitHub (May 15, 2019):

I would like to add a +1 to this feature request. I have more than one writer/editor duo who don't cross projects, and trying to go in and create different roles for every single project is proving to be a royal pain. It would be far better to have a couple of global roles such as "admin" and "writer" that everyone gets assigned to upon logging in, and then for each project (book, shelf, etc), a set of roles that individual users can then be assigned to. Then, if a writer gets the "editor" role on another writer's project, they're elevated for that project only.

Might be a little more work now, but it'll streamline permissions over time, instead of base restrictions.

@lindsayschm commented on GitHub (May 15, 2019): I would like to add a +1 to this feature request. I have more than one writer/editor duo who don't cross projects, and trying to go in and create different roles for every single project is proving to be a royal pain. It would be far better to have a couple of global roles such as "admin" and "writer" that everyone gets assigned to upon logging in, and then for each project (book, shelf, etc), a set of roles that individual users can then be assigned to. Then, if a writer gets the "editor" role on another writer's project, they're elevated for that project only. Might be a little more work now, but it'll streamline permissions over time, instead of base restrictions.
Author
Owner

@alexmannuk commented on GitHub (Aug 24, 2020):

Depending on number of books you have you could just create roles of Book A Editors, Book B Editors, etc and assign users to those. There are many requests for being able to assign permissions direct to users though, so that will probably stay on the list until someone gets round to it.

@alexmannuk commented on GitHub (Aug 24, 2020): Depending on number of books you have you could just create roles of Book A Editors, Book B Editors, etc and assign users to those. There are many requests for being able to assign permissions direct to users though, so that will probably stay on the list until someone gets round to it.
Author
Owner

@battosai30 commented on GitHub (Sep 3, 2020):

There is many cases that needs this feather. For example : I'm forming in an IT school. Students have to build project during the year, and they do it in teams. So each team creates a book in order to document its project. As there is around 75 teams, I can't create 75 groups to restrict accesses ...

@battosai30 commented on GitHub (Sep 3, 2020): There is many cases that needs this feather. For example : I'm forming in an IT school. Students have to build project during the year, and they do it in teams. So each team creates a book in order to document its project. As there is around 75 teams, I can't create 75 groups to restrict accesses ...
Author
Owner

@homer1993 commented on GitHub (Oct 4, 2020):

Most of my stacks and books are public, some of them are only editable for the roles, which I have already defined. And some of them are private, which I would like to add a group just for one or two users.

For the last step, it would necessary to define user permission to specific books via roles. Unfortunatelly, I cannot create roles with userbased permission, only with functionbased permission.

That's why I want to add a +1 for userbased viewer/editor permissions to books and stacks.

@homer1993 commented on GitHub (Oct 4, 2020): Most of my stacks and books are public, some of them are only editable for the roles, which I have already defined. And some of them are private, which I would like to add a group just for one or two users. For the last step, it would necessary to define user permission to specific books via roles. Unfortunatelly, I cannot create roles with userbased permission, only with functionbased permission. That's why I want to add a +1 for userbased viewer/editor permissions to books and stacks.
Author
Owner

@aftabcurrency commented on GitHub (Jan 24, 2022):

Hi
This would give better control over the documentation at the individual team level. The permissions should be diluted to the chapter level.

@aftabcurrency commented on GitHub (Jan 24, 2022): Hi This would give better control over the documentation at the individual team level. The permissions should be diluted to the chapter level.
Author
Owner

@ssddanbrown commented on GitHub (Jan 24, 2022):

I've updated the title and labels to be specific to feature requested by the OP.
Personally I think this would add a great deal of complexity to an already complex system, and hence won't be worth the maintenance cost but, before I close this off as out of scope, I'll wait until we've made future permissions changes as there may be an easer route of implementation by that time.

Note: User level item permissions are tracked under issue #1747, and selective permission application is tracked under issue #410. From the above comments I think some may be confusing this issue for slightly different functionality requested elsewhere.

@ssddanbrown commented on GitHub (Jan 24, 2022): I've updated the title and labels to be specific to feature requested by the OP. Personally I think this would add a great deal of complexity to an already complex system, and hence won't be worth the maintenance cost but, before I close this off as out of scope, I'll wait until we've made future permissions changes as there may be an easer route of implementation by that time. Note: User level item permissions are tracked under issue #1747, and selective permission application is tracked under issue #410. From the above comments I think some may be confusing this issue for slightly different functionality requested elsewhere.
Author
Owner

@ssddanbrown commented on GitHub (Nov 8, 2022):

I'm going to proceed to close this off as my thoughts have remained that this would add a complexity level to the permissions system that would not be worthwhile, especially as it complicates the design of what a role is.
I've since refined how permissions are applied within the latest release, and I still intend to add user-level permissions which should appease some of the requests here.

@ssddanbrown commented on GitHub (Nov 8, 2022): I'm going to proceed to close this off as my thoughts have remained that this would add a complexity level to the permissions system that would not be worthwhile, especially as it complicates the design of what a role is. I've since refined how permissions are applied within the latest release, and I still intend to add user-level permissions which should appease some of the requests here.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#762