Add the concept of entity "Owners" #1840

New Issue

OVERLORD · 2026-02-05T02:01:29+03:00

OVERLORD commented

2026-02-05 02:01:29 +03:00

Originally created by @ssddanbrown on GitHub (Sep 5, 2020).

This request is intended to propose a solution to a number of requests surrounding the permission system and the use of the "created_by" value on pages/chapters/shelves/books.

The Scenario

Currently we have various permissions and logic that take into account the creator of an entity. Within the role configuration screen these are shown as "Own" permissions. These use the "created_by" field. There is no way, outside of database access, for this altered between users in the system. When a user is deleted this value is nulled.

Implementation Idea

We would add a concept of "Owners" to the system for entities (Shelves/Books/Chapters/Pages). This would be implemented as follows:

A 'owned_by' field would be added to each of the entity tables.
On upgrade, database migrations would copy existing 'created_by' values to the 'owned_by' field.
Within the "Permissions" menu for an entity, A user that has permission to edit permissions will be able to change the "owner" to a single other individual.
When deleting a user from the system, the option to select a new owner will be provided, who will become the owner of everything that was previously owned by the deleted user.

Benefits

By changing the owner an admin could better utilise the "Own" role permissions as they could create a book for users then assign that to a user with "Own" permissions so they can control everything within. As of now, that user would currently also need to be able to create books.
We may be able to utilise this concept in the future for notifications.
By not altering the "created_by" field instead and having a separate field, we're keeping the database semantics correct while providing more accurate information to the user.

Originally created by @ssddanbrown on GitHub (Sep 5, 2020). This request is intended to propose a solution to a number of requests surrounding the permission system and the use of the "created_by" value on pages/chapters/shelves/books. ## The Scenario Currently we have various permissions and logic that take into account the creator of an entity. Within the role configuration screen these are shown as "Own" permissions. These use the "created_by" field. There is no way, outside of database access, for this altered between users in the system. When a user is deleted this value is nulled. ## Implementation Idea We would add a concept of "Owners" to the system for entities (Shelves/Books/Chapters/Pages). This would be implemented as follows: - A 'owned_by' field would be added to each of the entity tables. - On upgrade, database migrations would copy existing 'created_by' values to the 'owned_by' field. - Within the "Permissions" menu for an entity, A user that has permission to edit permissions will be able to change the "owner" to a single other individual. - When deleting a user from the system, the option to select a new owner will be provided, who will become the owner of everything that was previously owned by the deleted user. ## Benefits - By changing the owner an admin could better utilise the "Own" role permissions as they could create a book for users then assign that to a user with "Own" permissions so they can control everything within. As of now, that user would currently also need to be able to create books. - We may be able to utilise this concept in the future for notifications. - By not altering the "created_by" field instead and having a separate field, we're keeping the database semantics correct while providing more accurate information to the user.

OVERLORD added the 🛠️ Enhancement 🔨 Feature Request 🏭 Back-End labels 2026-02-05 02:01:29 +03:00

OVERLORD closed this issue

2026-02-05 02:01:30 +03:00

OVERLORD commented

2026-02-05 02:01:33 +03:00

@tiredofit commented on GitHub (Sep 5, 2020):

I think this would be a great step forward to ensure that a) content is not removed when a user is removed from the system and b) also introduces some workflow capabilities.

For example on workflow:
I am a user who is creating documentation yet I need to have it reviewed before actual publishing. I would create the content, and assign ownership to an individual (or group) to own the book/page/chapter. The owner would perform any edits, or request additional changes, before finalizing the document, removing the permissions of the "creator" and moving the content to a more public area. If there were ever modifications required to the document, the Owner could simply reapply permissions for the original creator to edit the content and follow through the same routine again before publishing. Essentially this introduces a Steward/Content Moderation workflow which would keep content creation inside the application as opposed to in say a separate word processing document (Google Docs/Office etc) which would have to be manually moved after approval.

I think this would be amazing.

@tiredofit commented on GitHub (Sep 5, 2020): I think this would be a great step forward to ensure that a) content is not removed when a user is removed from the system and b) also introduces some workflow capabilities. For example on workflow: I am a user who is creating documentation yet I need to have it reviewed before actual publishing. I would create the content, and assign ownership to an individual (or group) to own the book/page/chapter. The owner would perform any edits, or request additional changes, before finalizing the document, removing the permissions of the "creator" and moving the content to a more public area. If there were ever modifications required to the document, the Owner could simply reapply permissions for the original creator to edit the content and follow through the same routine again before publishing. Essentially this introduces a Steward/Content Moderation workflow which would keep content creation inside the application as opposed to in say a separate word processing document (Google Docs/Office etc) which would have to be manually moved after approval. I think this would be amazing.

OVERLORD commented

2026-02-05 02:01:37 +03:00

@Nello796 commented on GitHub (Sep 14, 2020):

I think is a great idea to have something like this. How long do you think it will take to be implemented in BookStack ?

@Nello796 commented on GitHub (Sep 14, 2020): I think is a great idea to have something like this. How long do you think it will take to be implemented in BookStack ?

OVERLORD commented

2026-02-05 02:01:39 +03:00

@Jregula-pcsd commented on GitHub (Sep 17, 2020):

I like this idea as well.

@Jregula-pcsd commented on GitHub (Sep 17, 2020): I like this idea as well.

OVERLORD commented

2026-02-05 02:01:44 +03:00

@csongs commented on GitHub (Dec 16, 2020):

It's good for me. 👍
By the way, I hope only owner can edit Page Revisions` .

In order to avoid edior clear all content of page and delete all Page Revisions of page.

Example:

	Delete Page Revisions	Edit Page
Editor		V
Owner	V	V

@csongs commented on GitHub (Dec 16, 2020): It's good for me. :+1: By the way, I hope only `owner` can edit Page Revisions` . In order to avoid `edior` clear all content of `page` and delete all `Page Revisions` of `page`. Example: | | Delete Page Revisions | Edit Page | |-------- |------------------------ |----------- | | Editor | | V | | Owner | V | V |

OVERLORD commented

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

@ssddanbrown commented on GitHub (Dec 16, 2020):

@csongs Sure, That kind of functionality won't be included as part of this work though, this will be done sooner.

Issue #1747 is much more closely related to that request (And will likely be dependant for entity-level owner permission overrides).

@ssddanbrown commented on GitHub (Dec 16, 2020): @csongs Sure, That kind of functionality won't be included as part of this work though, this will be done sooner. Issue #1747 is much more closely related to that request (And will likely be dependant for entity-level owner permission overrides).

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#1840