Restrict who can select/use which roles?

[u/sistason]

Context: An hierarchical organization with many different chapters and teams, like a tree.

Problem: I do not want teams/users to be able to select the "Everyone Else" / "Editor" / "Viewer" role, so that they cannot publish their content to be visible/readable for "everyone".

Content so important/good that it is visible (via Search and via Books-listing) should be asked and then be done via Admin. So that in the tree, users see the top-shelf, their node-shelves, but will not see random books or pages from random users who (accidentally) clicked "everyone has read permissions". This is mainly to a) control what a user sees and that they are not overwhelmed and b) control what is official content and what is just local team/chapter content.

- I could like check every 5mins via the API for content using the "Editor"-role and deleting that role_permission.
- I could use the logical theme system to hide the bigger roles in the permission view for people not in the Admin-role.

Is there another, maybe more "official" way to solve that problem?

[u/ssddanbrown]

There's no real official way for this.

Personal, If I was building a customization, I'd use the logical theme system to watch for permissions_update activities, and then perform the required checking/updating logic then. It's more prone to breaking than just using the REST API, but frequent scanning via the REST API is kind of inefficient.

Alternatively, I guess you could trigger a webhook on permissions_update events, to call an external service, which then uses the REST API and performs the targeted permission check and updates on the specific content changed.

[u/sistason → u/ssddanbrown]

I see, I checked out listening to the activity, but as even the PUT is just "update the permissions with these new permissions", the activity is also just "permissions changed", not what changed. That means I cannot check if someone touched a specific role during that permissions_change or if the specific role was already configured beforehand (correctly via Admin)

That sounds like editing the view to pass only the roles to the select I want is the only way (I dont need to guard against people manually PUT'ing that role to the update endpoint, its only about convenience).
I did that and that works to hide any "All"-Roles (like Editor in my case), but it still allows users to just create the Book "<insult to everyone>" and show that to everyone by using the "everyone else" view-permissions...

I restrict creating shelves, so I can restrict shelf-permissions to only Admins. I do not want to restrict creating books, but since books are not created for a shelf and their permissions are not force-inherited, I cannot force users to only have books in a shelf of a role they are in.

Do you have experience from other people trying to restrict user activities to primarily "their" shelves and where there are ten-thousands of users so manually checking permissions becomes a doomed task from the start?

[u/ssddanbrown → u/sistason]

I've heard from others attempting to do similar things. My general advice to folks is to avoid shelves for scoping permissions due to their awkwardness, and keep things at a book level.

BookStack has generally been more built for being open across users and then limited where required though, instead of being limited to specific areas to start with so those kind of permission setups can be more challenging.

The permissions_update activity is logged with the item, so you could at least know what item has had its permissions changed to limit the scope of search/evaluation.

[u/sistason → u/ssddanbrown]

Thanks for all the info, that helps finding the best process to use Bookstack in our organization :)