Ability to set one permission but new items to inherit another permission

[mnaoumov]

Describe the feature you'd like

Sometimes, we need to allow access to a book but deny access to every future new pages. Currently every new page will inherit allow access permission.

I would like to be able to allow access to the book but make new pages by default inherit deny access.

Describe the benefits this would bring to existing BookStack users

I have Book1 with Page2 Page3. And I want to open to external world only Page2

Granting Public view permissions for Page2 is straightforward.

1. If we allow Public view permission to Book1, then I have to go to manually deny Public view permission for Page3. And every new page PageNew in Book1 will inherit Public view permission from Book1 and we will have to go and manually deny Public vide permission for PageNew.
2. If we deny Public view permission to Book1, then this page won't be discoverable. Yes, you are still able to reach it via https://my-url/books/book1/page/page2 but you have no way to find this page without the direct link. The workaround is to have a page with all the links available for Public users, but you also have to not forget to add a link there if you decided to open a Public access to some other Page.

Both options seem to be annoyingly unfriendly.

Can the goal of this request already be achieved via other means?

No

Have you searched for an existing open/closed issue?

• [X] I have searched for existing issues and none cover my fundamental request

How long have you been using BookStack?

Under 3 months

Additional context

No response

[mnaoumov]

I also created a thread on Discord about it: https://discord.com/channels/578552496637739008/1029530651797499945/threads/1195035048152420512

[ssddanbrown]

Thanks for the request @mnaoumov. Personally though, I wouldn't be keen on supporting the additional permission system complexity for something like this just for this specific kind of scenario, as I think the general benefits to existing BookStack users are quite limited.

If you're confident with PHP, you could use our logical theme system to build and maintain a customization, to watch for page creation and apply permissions as required.

[mnaoumov]

@ssddanbrown thanks for the quick reply. However, I wonder if my request is so special and unique? I am using BookStack for a few days only, but for me it seems like a basic scenario. Maybe there are better ways to achieve what I am trying to do without you breaking your permission system?

[ssddanbrown]

The only other thing I can suggest is categorizing your public/private content into different books to simplify the permission management.

[mnaoumov]

@ssddanbrown no, this is also a workaround. The separation between public/private content is already done via permissions. We just need a bit more granular control over them. From the programming point of view, I think, it is the matter of adding an optional override permission, which as you said 99% of users won't use.

So main permission will be inherited as in your current logic, but override permission can override the main permission for the object itself, not for its children

Would you be interested if I make a PR?

[ssddanbrown]

Would you be interested if I make a PR?

No. As above I wouldn't want to add the extra complexity into the permission system, especially upon little proven benefit to our audience base.

If you have the PHP skills to make a PR, then taking advantage of the logical theme system as advised above may well cover your needs.

[mnaoumov]

Thanks for the feedback