Permission for Export function #1020

New Issue

OVERLORD · 2026-02-04T23:24:45+03:00

OVERLORD commented

2026-02-04 23:24:45 +03:00

Originally created by @ongmark on GitHub (Feb 1, 2019).

Describe the feature you'd like
A way to set permissions for export on a per book basis

Describe the benefits this feature would bring to BookStack users
Granular control of the export function. We may want to restrict Export for Admin or Editor roles only.

Originally created by @ongmark on GitHub (Feb 1, 2019). **Describe the feature you'd like** A way to set permissions for export on a per book basis **Describe the benefits this feature would bring to BookStack users** Granular control of the export function. We may want to restrict Export for Admin or Editor roles only.

OVERLORD added the 🛠️ Enhancement 🏭 Back-End labels 2026-02-04 23:24:45 +03:00

OVERLORD closed this issue

2026-02-04 23:24:48 +03:00

OVERLORD commented

2026-02-04 23:24:54 +03:00

@h4ckninja commented on GitHub (Feb 1, 2019):

I'd like to also add a way to completely disable this. Apologies if I missed it in the docs, but I didn't see it.

@h4ckninja commented on GitHub (Feb 1, 2019): I'd like to also add a way to completely disable this. Apologies if I missed it in the docs, but I didn't see it.

OVERLORD commented

2026-02-04 23:25:01 +03:00

@ssddanbrown commented on GitHub (Feb 2, 2019):

Thanks for the suggestion @ongmark.

If I'm honest I personally feel this would be making the permissions system too granular. At the moment permissions dictate actions on the content (View, create, update, delete) which then is used by features (View permission is required for exporting, for example). Bringing features into the permission system would be a slippery-slope to them expanding a lot more for other features.

I'll leave this open to discussion for a while though in the even someone can make the case this would be worthwhile.

@ssddanbrown commented on GitHub (Feb 2, 2019): Thanks for the suggestion @ongmark. If I'm honest I personally feel this would be making the permissions system too granular. At the moment permissions dictate actions on the content (View, create, update, delete) which then is used by features (View permission is required for exporting, for example). Bringing features into the permission system would be a slippery-slope to them expanding a lot more for other features. I'll leave this open to discussion for a while though in the even someone can make the case this would be worthwhile.

OVERLORD commented

2026-02-04 23:25:06 +03:00

@h4ckninja commented on GitHub (Feb 2, 2019):

That's fair.

My immediate needs are a little less granular, and if unrelated, I'll open a new ticket.

For the immediate, I don't want anybody to export. The installation I run has sensitive information that competitors would find useful. While I can't stop anybody from screen printing, I can at least stop them from using the built-in functionality, or, going with @ongmark, restrict it to the admins.

I think this is more in line with the "secured images" functionality as it seems to be built with that sort of frame of mind.

@h4ckninja commented on GitHub (Feb 2, 2019): That's fair. My immediate needs are a little less granular, and if unrelated, I'll open a new ticket. For the immediate, I don't want anybody to export. The installation I run has sensitive information that competitors would find useful. While I can't stop anybody from screen printing, I can at least stop them from using the built-in functionality, or, going with @ongmark, restrict it to the admins. I think this is more in line with the "secured images" functionality as it seems to be built with that sort of frame of mind.

OVERLORD commented

2026-02-04 23:25:15 +03:00

@ongmark commented on GitHub (Feb 3, 2019):

My use case is similar to @h4ckninja. I'm planning to store sensitive information that i wouldn't want viewers to conveniently export.

@ssddanbrown If tying the feature flag to a role is not practical, maybe tying it to the create permission instead of the view permission is more workable?

Completely disabling the export function works for me too.

@ongmark commented on GitHub (Feb 3, 2019): My use case is similar to @h4ckninja. I'm planning to store sensitive information that i wouldn't want viewers to conveniently export. @ssddanbrown If tying the feature flag to a role is not practical, maybe tying it to the create permission instead of the view permission is more workable? Completely disabling the export function works for me too.

OVERLORD commented

2026-02-04 23:25:18 +03:00

@ssddanbrown commented on GitHub (Feb 3, 2019):

The create permission won't really work here since that is for container items (Books, chapters) and does not relate to the export function as much as the view permission.

If you want to just hide the menu for now you could add the following to the "Custom HTML head" setting:

<style>
	.toolbar .action-buttons > .dropdown-container:first-child {
	    display: none;
	}
</style>

This has potential to stop working on updating though so check after updates as you might need to tweak this.

@ssddanbrown commented on GitHub (Feb 3, 2019): The create permission won't really work here since that is for container items (Books, chapters) and does not relate to the export function as much as the view permission. If you want to just hide the menu for now you could add the following to the "Custom HTML head" setting: ```html <style> .toolbar .action-buttons > .dropdown-container:first-child { display: none; } </style> ``` This has potential to stop working on updating though so check after updates as you might need to tweak this.

OVERLORD commented

2026-02-04 23:25:25 +03:00

@ongmark commented on GitHub (Feb 3, 2019):

Works like a charm. Many thanks, @ssddanbrown!

@ongmark commented on GitHub (Feb 3, 2019): Works like a charm. Many thanks, @ssddanbrown!

OVERLORD commented

2026-02-04 23:25:29 +03:00

@ssddanbrown commented on GitHub (Jul 10, 2019):

Updated export-menu hide styles for the current release (~v0.26):

<style>
.tri-layout-right-contents a[href$="/delete"] + hr, .tri-layout-right-contents .actions hr + .dropdown-container {display: none;}
</style>

Can be added to the "Custom HTML head" setting. Will leave an empty "Actions" menu for public viewers though.

@ssddanbrown commented on GitHub (Jul 10, 2019): Updated export-menu hide styles for the current release (~v0.26): ```html <style> .tri-layout-right-contents a[href$="/delete"] + hr, .tri-layout-right-contents .actions hr + .dropdown-container {display: none;} </style> ``` Can be added to the "Custom HTML head" setting. Will leave an empty "Actions" menu for public viewers though.

OVERLORD commented

2026-02-04 23:25:34 +03:00

@JtheBAB commented on GitHub (Jul 11, 2019):

Thanks @ssddanbrown

Maybe you could implement a system wide option like disabling the comments? Then this code would not be needed?

@JtheBAB commented on GitHub (Jul 11, 2019): Thanks @ssddanbrown Maybe you could implement a system wide option like disabling the comments? Then this code would not be needed?

OVERLORD commented

2026-02-04 23:25:37 +03:00

@james-geiger commented on GitHub (Aug 15, 2019):

If the per-book export option would be too granular, I agree that it would be useful to have exporting perhaps at three levels; exporting globally off, exporting globally on, exporting only for authenticated users.

Although I could see use-cases where per-book export permissions would be helpful, this might be a nice middle-ground for initial implementation.

@james-geiger commented on GitHub (Aug 15, 2019): If the per-book export option would be too granular, I agree that it would be useful to have exporting perhaps at three levels; exporting globally off, exporting globally on, exporting only for authenticated users. Although I could see use-cases where per-book export permissions would be helpful, this might be a nice middle-ground for initial implementation.

OVERLORD commented

2026-02-04 23:25:40 +03:00

@ssddanbrown commented on GitHub (Aug 29, 2021):

I've just merged in #2899 which will provide role-level export permissions at an instance level (Not per asset). Using this you'll be able to remove the permission from all roles to prevent exports globally if desired. This is about as granular as I'd like to go with this since I don't really want to go outside of the core CRUD actions for content (Books/chapters/pages). This should hopefully cover most use-cases.

I'll therefore close this off. It will be part of the next feature release.

@ssddanbrown commented on GitHub (Aug 29, 2021): I've just merged in #2899 which will provide role-level export permissions at an instance level (Not per asset). Using this you'll be able to remove the permission from all roles to prevent exports globally if desired. This is about as granular as I'd like to go with this since I don't really want to go outside of the core CRUD actions for content (Books/chapters/pages). This should hopefully cover most use-cases. I'll therefore close this off. It will be part of the next feature release.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#1020