mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-05-04 18:08:46 +03:00
Permission to only Edit Pages (not books) for Selected Users #4500
Reference in New Issue
Block 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 @mgmwhite on GitHub (Mar 7, 2024).
Attempted Debugging
Searched GitHub Issues
Describe the Scenario
Hi all,
is it somehow possible to enable a group of users to create and edit pages/chapters but not the containig book itself without having to micromanage every new page that gets created?
So basically have group "Admins" create new books, that group "editors" are only allowed to fill with content and a group "viewers" that can only read the content.
I tried different setups but either the Editors could edit both pages/chapters and books or neither of them.
Would be great to know if this is somehow achievable.
Thanks!
PS: Same thing goes for being able to create and edit books but not the containig shelf, so one level "higher". Could not figure out how to do that either.
Exact BookStack Version
v24.02
Log Content
No response
Hosting Environment
.
@ssddanbrown commented on GitHub (Mar 7, 2024):
Hi @mgmwhite,
You can do this via role permissions, since you can manage those per-content type, but as soon as you start applying permissions to specific items things can become more micro-managey for what you want, since permissions will cascade (from books and chapters).
@mgmwhite commented on GitHub (Mar 11, 2024):
Hi @ssddanbrown
thanks for replying! I tried a few different settings, but none of them really met the requirement. I think to simply map the process, there would need to be an additional boolean field in the book permissions, maybe called "Update Content" or something like that. If this is set, the user should only be able to edit the content of a book, but not the book itself. This would be great, for example, to allow individual users to use books to publish stuff without "jeopardising" the established book infrastructure.
What do you think about this?
@ssddanbrown commented on GitHub (Mar 11, 2024):
@mgmwhite I can see how that would help, and why you might want that option.
Personally though I don't want to add additional complexity to the permission system so I'd not be keen to add this without significant demand, of which we have not observed so far.
Another potential option for this could be via the request in #4832, for roles to become owners.
There's also some prior discussion related to that in #3964.
@Valaron-Jakob commented on GitHub (May 10, 2025):
To be able to differenciate in permission between the parent and child items would be well appreciated for us as well.
Our UseCases:
Some Examples:
Proposed Solutions:
"Create" permissions already only affects the contet, whereas "Update" and "Delete" allow to delete the book/shelf. Allowing to be able to differenciate between them would be gamechanging for us.
Solution I - Individual Book & Content permission overrides
Solution II - Dropdowns for granular Create & Delete perission overrides
Thank you for reading and considering this
@ssddanbrown commented on GitHub (Sep 3, 2025):
Since this support request is quite old, I'm going to close this off.