mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-14 11:19:37 +03:00
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
No Branch/Tag Specified
development
l10n_development
release
v25-12
llm_only
vectors
v25-11
docker_env
drawio_rendering
user_permissions
ldap_host_failover
svg_image
prosemirror
captcha_example
fix/video-export
v25.12.3
v25.12.2
v25.12.1
v25.12
v25.11.6
v25.11.5
v25.11.4
v24.11.4
v25.11.3
v25.11.2
v25.11.1
v25.11
v25.07.3
v25.07.2
v25.07.1
v25.07
v25.05.2
v25.05.1
v25.05
v25.02.5
v25.02.4
v25.02.3
v25.02.2
v25.02.1
v25.02
v24.12.1
v24.12
v24.10.3
v24.10.2
v24.10.1
v24.10
v24.05.4
v24.05.3
v24.05.2
v24.05.1
v24.05
v24.02.3
v24.02.2
v24.02.1
v24.02
v23.12.3
v23.12.2
v23.12.1
v23.12
v23.10.4
v23.10.3
v23.10.2
v23.10.1
v23.10
v23.08.3
v23.08.2
v23.08.1
v23.08
v23.06.2
v23.06.1
v23.06
v23.05.2
v23.05.1
v23.05
v23.02.3
v23.02.2
v23.02.1
v23.02
v23.01.1
v23.01
v22.11.1
v22.11
v22.10.2
v22.10.1
v22.10
v22.09.1
v22.09
v22.07.3
v22.07.2
v22.07.1
v22.07
v22.06.2
v22.06.1
v22.06
v22.04.2
v22.04.1
v22.04
v22.03.1
v22.03
v22.02.3
v22.02.2
v22.02.1
v22.02
v21.12.5
v21.12.4
v21.12.3
v21.12.2
v21.12.1
v21.12
v21.11.3
v21.11.2
v21.11.1
v21.11
v21.10.3
v21.10.2
v21.10.1
v21.10
v21.08.6
v21.08.5
v21.08.4
v21.08.3
v21.08.2
v21.08.1
v21.08
v21.05.4
v21.05.3
v21.05.2
v21.05.1
v21.05
v21.04.6
v21.04.5
v21.04.4
v21.04.3
v21.04.2
v21.04.1
v21.04
v0.31.8
v0.31.7
v0.31.6
v0.31.5
v0.31.4
v0.31.3
v0.31.2
v0.31.1
v0.31.0
v0.30.7
v0.30.6
v0.30.5
v0.30.4
v0.30.3
v0.30.2
v0.30.1
v0.30.0
v0.29.3
v0.29.2
v0.29.1
v0.29.0
v0.28.3
v0.28.2
v0.28.1
v0.28.0
v0.27.5
v0.27.4
v0.27.3
v0.27.2
v0.27.1
v0.27
v0.26.4
v0.26.3
v0.26.2
v0.26.1
v0.26.0
v0.25.5
v0.25.4
v0.25.3
v0.25.2
v0.25.1
v0.25.0
v0.24.3
v0.24.2
v0.24.1
v0.24.0
v0.23.2
v0.23.1
v0.23.0
v0.22.0
v0.21.0
v0.20.3
v0.20.2
v0.20.1
v0.20.0
v0.19.0
v0.18.5
v0.18.4
v0.18.3
v0.18.2
v0.18.1
v0.18.0
v0.17.4
v0.17.3
v0.17.2
v0.17.1
v0.17.0
v0.16.3
v0.16.2
v0.16.1
v0.16.0
v0.15.3
v0.15.2
v0.15.1
v0.15.0
v0.14.3
v0.14.2
v0.14.1
v0.14.0
v0.13.1
v0.13.0
v0.12.2
v0.12.1
v0.12.0
v0.11.2
v0.11.1
v0.11.0
v0.10.0
v0.9.3
v0.9.2
v0.9.1
v0.9.0
v0.8.2
v0.8.1
v0.8.0
v0.7.6
v0.7.5
v0.7.4
v0.7.3
0.7.2
v.0.7.1
v0.7.0
v0.6.3
v0.6.2
v0.6.1
v0.6.0
v0.5.0
Labels
Clear labels
🎨 Design
📖 Docs Update
🐛 Bug
🐛 Bug
:cat2:🐈 Possible duplicate
💿 Database
☕ Open to discussion
💻 Front-End
🐕 Support
🚪 Authentication
🌍 Translations
🔌 API Task
🏭 Back-End
⛲ Upstream
🔨 Feature Request
🛠️ Enhancement
🛠️ Enhancement
🛠️ Enhancement
❤️ Happy feedback
🔒 Security
🔍 Pending Validation
💆 UX
📝 WYSIWYG Editor
🌔 Out of scope
🔩 API Request
:octocat: Admin/Meta
🖌️ View Customization
❓ Question
🚀 Priority
🛡️ Blocked
🚚 Export System
♿ A11y
🔧 Maintenance
> Markdown Editor
pull-request
Mirrored from GitHub Pull Request
No Label
🔨 Feature Request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/BookStack#762
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
@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.
@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 21, 2018):
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.
@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:
Or are you looking for something else?
@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.
@battosai30 commented on GitHub (Nov 21, 2018):
I agree it would be a useful feature ;)
@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.
@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.
@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.
@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):
Perhaps some graphics would help:

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.
@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.
@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.
@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 ...
@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.
@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.
@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 (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.