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

New Issue

OVERLORD · 2026-02-05T08:48:02+03:00

OVERLORD commented

2026-02-05 08:48:02 +03:00

Originally created by @mnaoumov on GitHub (Jan 11, 2024).

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.

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.
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?

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

Originally created by @mnaoumov on GitHub (Jan 11, 2024). ### 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_

OVERLORD added the 🔨 Feature Request label 2026-02-05 08:48:02 +03:00

OVERLORD closed this issue

2026-02-05 08:48:04 +03:00

OVERLORD commented

2026-02-05 08:48:11 +03:00

@mnaoumov commented on GitHub (Jan 11, 2024):

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

@mnaoumov commented on GitHub (Jan 11, 2024): I also created a thread on Discord about it: https://discord.com/channels/578552496637739008/1029530651797499945/threads/1195035048152420512

OVERLORD commented

2026-02-05 08:48:13 +03:00

@ssddanbrown commented on GitHub (Jan 11, 2024):

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.

@ssddanbrown commented on GitHub (Jan 11, 2024): 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.

OVERLORD commented

2026-02-05 08:48:18 +03:00

@mnaoumov commented on GitHub (Jan 11, 2024):

@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?

@mnaoumov commented on GitHub (Jan 11, 2024): @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?

OVERLORD commented

2026-02-05 08:48:21 +03:00

@ssddanbrown commented on GitHub (Jan 11, 2024):

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

@ssddanbrown commented on GitHub (Jan 11, 2024): The only other thing I can suggest is categorizing your public/private content into different books to simplify the permission management.

OVERLORD commented

2026-02-05 08:48:23 +03:00

@mnaoumov commented on GitHub (Jan 11, 2024):

@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?

@mnaoumov commented on GitHub (Jan 11, 2024): @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?

OVERLORD commented

2026-02-05 08:48:24 +03:00

@ssddanbrown commented on GitHub (Jan 11, 2024):

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.

@ssddanbrown commented on GitHub (Jan 11, 2024): > 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.

OVERLORD commented

2026-02-05 08:48:31 +03:00

@mnaoumov commented on GitHub (Jan 11, 2024):

Thanks for the feedback

@mnaoumov commented on GitHub (Jan 11, 2024): Thanks for the feedback

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#4398