Show Book permissions Directly on Book Cards #3809

New Issue

OVERLORD · 2026-02-05T07:32:27+03:00

OVERLORD commented

2026-02-05 07:32:27 +03:00

Originally created by @andriykrefer on GitHub (May 20, 2023).

Describe the feature you'd like

Currently I have to open a Book, and click "Permissions" to see this information.
I would like to see it directly on the book item on the books list, so I can see the permission for all listed books at once instead of opening one by one.

Some suggestions, in the case this implementation add too much clutter to the UI

Make it optional
Click on button to reveal this information
Hover a button to reveal this information (for instance an "i" icon)

I made a draft mockup suggestion showing the group name, followed by icons representing "View, Create, Edit and Delete" permissions.

It would be nice to have this feature on both List and Grid modes.

Describe the benefits this would bring to existing BookStack users

At my company, Groups and Permissions, are used to control the visibility of content according to the Groups assigned to the user.
For instance, there are book visible to "Engineering", but not to "Operations" or "Customer".
It is harder and prone to error to manage all books with this information "hidden". Sometime a book that should not be visible to some Group is left visible by mistake.

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

No. I cannot see permission for multiple books at once, as far as I am concerned.

Have you searched for an existing open/closed issue?

I have searched for existing issues and none cover my fundemental request

How long have you been using BookStack?

1 to 5 years

Additional context

No response

Originally created by @andriykrefer on GitHub (May 20, 2023). ### Describe the feature you'd like Currently I have to open a Book, and click "Permissions" to see this information. I would like to see it directly on the book item on the books list, so I can see the permission for all listed books at once instead of opening one by one. Some suggestions, in the case this implementation add too much clutter to the UI - Make it optional - Click on button to reveal this information - Hover a button to reveal this information (for instance an "i" icon) I made a draft mockup suggestion showing the group name, followed by icons representing "View, Create, Edit and Delete" permissions. ![image](https://github.com/BookStackApp/BookStack/assets/30701181/ce487802-c60d-43e9-8550-5997a7d1db87) It would be nice to have this feature on both List and Grid modes. ### Describe the benefits this would bring to existing BookStack users At my company, Groups and Permissions, are used to control the visibility of content according to the Groups assigned to the user. For instance, there are book visible to "Engineering", but not to "Operations" or "Customer". It is harder and prone to error to manage all books with this information "hidden". Sometime a book that should not be visible to some Group is left visible by mistake. ### Can the goal of this request already be achieved via other means? No. I cannot see permission for multiple books at once, as far as I am concerned. ### Have you searched for an existing open/closed issue? - [x] I have searched for existing issues and none cover my fundemental request ### How long have you been using BookStack? 1 to 5 years ### Additional context _No response_

OVERLORD added the 🔨 Feature Request label 2026-02-05 07:32:27 +03:00

OVERLORD closed this issue

2026-02-05 07:32:30 +03:00

OVERLORD commented

2026-02-05 07:32:36 +03:00

@ssddanbrown commented on GitHub (May 20, 2023):

Thanks for the request @andriykrefer but this is not something I can see implementing with the core project, since I see this detail as too granular for being exposed at higher level views.

I would see #1736 and #3739 as being more appropriate solutions for reviewing permissions at a wider scale.

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

While not direct, it could be possible to build reports via our API, since that now provides permission information.
That said, for your described use-case, you'd maybe actually want to know resolved permission status, rather than defined permission rules, which is not something we expose in a user-facing manner right now.

@ssddanbrown commented on GitHub (May 20, 2023): Thanks for the request @andriykrefer but this is not something I can see implementing with the core project, since I see this detail as too granular for being exposed at higher level views. I would see #1736 and #3739 as being more appropriate solutions for reviewing permissions at a wider scale. > Can the goal of this request already be achieved via other means? While not direct, it could be possible to build reports via our API, since that now provides permission information. That said, for your described use-case, you'd maybe actually want to know resolved permission status, rather than defined permission rules, which is not something we expose in a user-facing manner right now.

OVERLORD commented

2026-02-05 07:32:38 +03:00

@andriykrefer commented on GitHub (May 22, 2023):

Thanks for the response @ssddanbrown

I see this detail as too granular for being exposed at higher level views.

I agree it is too granular when you consider chapters and pages level permissions. But I would suggest only book level permissions on the card.

I would see #1736 and #3739 as being more appropriate solutions for reviewing permissions at a wider scale.

#1736 would solve this issue for me as well! Any plans on implementing that?

it could be possible to build reports via our API

Nice to know there is a way through the API, but a core implementation would be preferred to a hacked workaround

@andriykrefer commented on GitHub (May 22, 2023): Thanks for the response @ssddanbrown > I see this detail as too granular for being exposed at higher level views. I agree it is too granular when you consider chapters and pages level permissions. But I would suggest only book level permissions on the card. > I would see #1736 and #3739 as being more appropriate solutions for reviewing permissions at a wider scale. #1736 would solve this issue for me as well! Any plans on implementing that? > it could be possible to build reports via our API Nice to know there is a way through the API, but a core implementation would be preferred to a hacked workaround

OVERLORD commented

2026-02-05 07:32:43 +03:00

@ssddanbrown commented on GitHub (Sep 11, 2023):

I'm going to go ahead and close this off as per my reasoning above, and since #1736 would be a preferred alternative to the fundemental goal here.

#1736 would solve this issue for me as well! Any plans on implementing that?

No plans at the moment, but I don't plan too far in advance.

@ssddanbrown commented on GitHub (Sep 11, 2023): I'm going to go ahead and close this off as per my reasoning above, and since #1736 would be a preferred alternative to the fundemental goal here. > #1736 would solve this issue for me as well! Any plans on implementing that? No plans at the moment, but I don't plan too far in advance.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#3809