[Feature Request] Add a review/audit property to a Book/Chapter/Page #1735

New Issue

OVERLORD · 2026-02-05T01:44:22+03:00

OVERLORD commented

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

Originally created by @mikeyz24 on GitHub (May 15, 2020).

Describe the feature you'd like
I'm using Bookstack for documentation and policies & procedures purposes. These items need to be reviewed regularly so that they are kept up to date. Adding a review date to a Book/Chapter/Page along with email notifications to the owner of upcoming items for review would be very useful. A history of when a review was completed and by whom should also exist.

Describe the benefits this feature would bring to BookStack users
It would allow people to keep their documentation up-to-date and keep an audit trail for accountability purposes.

Additional context

Originally created by @mikeyz24 on GitHub (May 15, 2020). **Describe the feature you'd like** I'm using Bookstack for documentation and policies & procedures purposes. These items need to be reviewed regularly so that they are kept up to date. Adding a review date to a Book/Chapter/Page along with email notifications to the owner of upcoming items for review would be very useful. A history of when a review was completed and by whom should also exist. **Describe the benefits this feature would bring to BookStack users** It would allow people to keep their documentation up-to-date and keep an audit trail for accountability purposes. **Additional context**

OVERLORD added the 🔨 Feature Request label 2026-02-05 01:44:22 +03:00

OVERLORD commented

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

@tiredofit commented on GitHub (Jul 29, 2020):

This would be quite an interesting feature to add introducing review/moderation workflow. I envision another set of permissions on the Shelf level and even Book level that allows a certain set of permissions to Create/Edit/Update content, yet keep in a "Review" mode similar to Draft which notifies in the Application a series of pages/content to be reviewed. The "Reviewer" role would then do any edits required and be responsible for "Publishing".

@tiredofit commented on GitHub (Jul 29, 2020): This would be quite an interesting feature to add introducing review/moderation workflow. I envision another set of permissions on the Shelf level and even Book level that allows a certain set of permissions to Create/Edit/Update content, yet keep in a "Review" mode similar to Draft which notifies in the Application a series of pages/content to be reviewed. The "Reviewer" role would then do any edits required and be responsible for "Publishing".

OVERLORD commented

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

@BFjimmy commented on GitHub (Nov 18, 2024):

After analyzing the database structure and current functionality, here’s a proposal for introducing a review workflow in BookStack to support a "peer review" process before publishing pages.

Database Observations

Draft Pages:

A page is marked as a draft if the draft column in the pages table is set to 1. This column appears to only be used before a page is first published. Once published, it is no longer utilized.
Subsequent unpublished changes are tracked using the page_revisions table with a type value of update_draft.

Concurrent Drafts:

Multiple users can work on drafts simultaneously, which may cause changes by one user to be hidden from another. This is acceptable due to the notification system alerting users to such conflicts.

Proposed Review Process

To introduce a peer review mechanism, the following changes and behaviors are suggested:

Button Behavior Changes:

For users without the publish page permission:

Replace the "Save Page" button with a "Set to Review" button. The "Save Draft" button remains unchanged.

For users with publish page permissions:

Retain both the "Save Page" and "Set to Review" options, allowing these users to optionally participate in the review process.

Database Updates for Review Status:

When a user clicks "Set to Review," update the type column in the page_revisions table for that revision to review_draft.

Behavior for Reviewing Drafts:

Any user with the publish page permission:

Can load the "review draft" of another user as their own draft but cannot make changes.
Gains the option to publish the page directly based on the review draft.

If a page is marked as type = review_draft and the draft owner revisits it:

They can only choose to "Remove from Review," reverting the draft to an editable state.

Restrictions:

While a page is in review_draft status:

Only the draft owner can remove it from the review queue.
Users with publish page permissions can only publish it but not edit it.

Intended Workflow

A user without publish page rights works on a draft and clicks "Set to Review" instead of "Save Page." The draft's status changes to review_draft.

A user with publish page rights sees the page marked for review, loads the draft, and can decide to:

Publish the draft as-is, or
Notify the original author to make further changes by leaving the draft in the review state.

If the original author decides to remove the draft from the review queue, they regain the ability to edit it.

Advantages of This System

Simplicity:

The system avoids implementing a complex review mechanism while providing a clear path for review and publication.

Seamless Integration:

Leverages existing database structures and user permissions, minimizing changes to the core functionality.

Flexibility:

Users with publish page permissions can participate in the review process or bypass it entirely, depending on the context.

Potential Implementation Steps

Add a new "Set to Review" button with associated logic.
Update the page_revisions table to support the new review_draft status.
Implement restrictions for users accessing review_draft revisions.
Add UI indicators to highlight pages in the review process for users with publish page permissions.

Also, maybe consider changing the text "Save page" to "Publish page" if the publish rights are enabled?

@BFjimmy commented on GitHub (Nov 18, 2024): After analyzing the database structure and current functionality, here’s a proposal for introducing a review workflow in BookStack to support a "peer review" process before publishing pages. **Database Observations** **Draft Pages**: - A page is marked as a draft if the draft column in the pages table is set to 1. This column appears to only be used before a page is first published. Once published, it is no longer utilized. - Subsequent unpublished changes are tracked using the page\_revisions table with a type value of update\_draft. **Concurrent Drafts**: - Multiple users can work on drafts simultaneously, which may cause changes by one user to be hidden from another. This is acceptable due to the notification system alerting users to such conflicts. **Proposed Review Process** To introduce a peer review mechanism, the following changes and behaviors are suggested: **Button Behavior Changes**: For users without the publish page permission: - Replace the "Save Page" button with a "Set to Review" button. The "Save Draft" button remains unchanged. For users with publish page permissions: - Retain both the "Save Page" and "Set to Review" options, allowing these users to optionally participate in the review process. **Database Updates for Review Status**: - When a user clicks "Set to Review," update the type column in the page\_revisions table for that revision to review\_draft. **Behavior for Reviewing Drafts**: Any user with the publish page permission: - Can load the "review draft" of another user as their own draft but **cannot make changes**. - Gains the option to publish the page directly based on the review draft. If a page is marked as type = review\_draft and the draft owner revisits it: - They can only choose to "Remove from Review," reverting the draft to an editable state. **Restrictions**: While a page is in review\_draft status: - Only the draft owner can remove it from the review queue. - Users with publish page permissions can only publish it but not edit it. **Intended Workflow** A user without publish page rights works on a draft and clicks "Set to Review" instead of "Save Page." The draft's status changes to review\_draft. A user with publish page rights sees the page marked for review, loads the draft, and can decide to: - Publish the draft as-is, or - Notify the original author to make further changes by leaving the draft in the review state. If the original author decides to remove the draft from the review queue, they regain the ability to edit it. **Advantages of This System** **Simplicity**: - The system avoids implementing a complex review mechanism while providing a clear path for review and publication. **Seamless Integration**: - Leverages existing database structures and user permissions, minimizing changes to the core functionality. **Flexibility**: - Users with publish page permissions can participate in the review process or bypass it entirely, depending on the context. **Potential Implementation Steps** 1. Add a new "Set to Review" button with associated logic. 2. Update the page\_revisions table to support the new review\_draft status. 3. Implement restrictions for users accessing review\_draft revisions. 4. Add UI indicators to highlight pages in the review process for users with publish page permissions. Also, maybe consider changing the text "Save page" to "Publish page" if the publish rights are enabled?

OVERLORD commented

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

@BFjimmy commented on GitHub (Nov 25, 2024):

@ssddanbrown Any thoughts on my suggestion?

@BFjimmy commented on GitHub (Nov 25, 2024): @ssddanbrown Any thoughts on my suggestion?

OVERLORD commented

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

@ssddanbrown commented on GitHub (Nov 25, 2024):

Hi @BFjimmy, Thanks for offering up the proposal. This issue thread is really for post-publish review/auditing, whereas your proposal is more aligned to pre-publish review/auditing, which better fits #473.

Setting that aside, I like the simplicity of what's proposed but I think even that would still add considerably complexity once all edge-cases, interactions, added views and required controls have been fleshed out, and this is an area that will spawn a lot of additional requests & can be quite opinionated as it can be specific to company/business workflow. Implementation is commonly the lesser effort/concern/consideration, with general scope/complexity/maintenance/support being bigger factors which this will have significant impact on.

This does provide a good basis for an an initial implementation when we get to that point, but I'm not keen to jump into this further right now since I've recently already significant increased the scope with a couple of significant features (New editor and new zip import/export format) which I need to see settle somewhat to assess burden, and since I think I need to think through some of the higher level planning/ideas around draft collaboration/access in general, as that has a big impact to such a process/workflow. Since these areas are in high demand though, it may be something I return to and potentially focus on for 2025.

@ssddanbrown commented on GitHub (Nov 25, 2024): Hi @BFjimmy, Thanks for offering up the proposal. This issue thread is really for post-publish review/auditing, whereas your proposal is more aligned to pre-publish review/auditing, which better fits #473. Setting that aside, I like the simplicity of what's proposed but I think even that would still add considerably complexity once all edge-cases, interactions, added views and required controls have been fleshed out, and this is an area that will spawn a lot of additional requests & can be quite opinionated as it can be specific to company/business workflow. Implementation is commonly the lesser effort/concern/consideration, with general scope/complexity/maintenance/support being bigger factors which this will have significant impact on. This does provide a good basis for an an initial implementation when we get to that point, but I'm not keen to jump into this further right now since I've recently already significant increased the scope with a couple of significant features (New editor and new [zip import/export format](https://github.com/BookStackApp/BookStack/pull/5260)) which I need to see settle somewhat to assess burden, and since I think I need to think through some of the higher level planning/ideas around draft collaboration/access in general, as that has a big impact to such a process/workflow. Since these areas are in high demand though, it may be something I return to and potentially focus on for 2025.

OVERLORD commented

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

@BFjimmy commented on GitHub (Nov 25, 2024):

Thanks for the reply @ssddanbrown

@BFjimmy commented on GitHub (Nov 25, 2024): Thanks for the reply @ssddanbrown

OVERLORD commented

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

@brynmoorhouse commented on GitHub (Apr 14, 2025):

Can I add my vote for this one please?

@brynmoorhouse commented on GitHub (Apr 14, 2025): Can I add my vote for this one please?

OVERLORD commented

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

@nimble-software commented on GitHub (May 19, 2025):

Agreed, this feature would be very useful

@nimble-software commented on GitHub (May 19, 2025): Agreed, this feature would be very useful

OVERLORD commented

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

@kasdkuls commented on GitHub (Nov 14, 2025):

Agreed, woud love to see this feature

@kasdkuls commented on GitHub (Nov 14, 2025): Agreed, woud love to see this feature

OVERLORD commented

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

@Grovkillen commented on GitHub (Nov 14, 2025):

We're investigating in having this done using Redmine + a making a plugin. It's very specific since you would need to have Redmine alongside Bookstack but for our company this is a potentially perfect match.

@Grovkillen commented on GitHub (Nov 14, 2025): We're investigating in having this done using Redmine + a making a plugin. It's very specific since you would need to have Redmine alongside Bookstack but for our company this is a potentially perfect match.

OVERLORD commented

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

@kevin39 commented on GitHub (Nov 25, 2025):

In case this helps someone: on my side, I implemented a small review process using only the tag system and search filters.

We added a link in the header menu containing two predefined searches: “Waiting pages” and “Anomaly pages”.
Each page includes a specific tag indicating its review state (waiting, verified, anomaly). The key point is that the author assigns the initial tag, and the reviewer updates it after verification.
Each page also displays a dynamic warning (using JavaScript) whenever the tag value is anything other than “verified”.

@kevin39 commented on GitHub (Nov 25, 2025): In case this helps someone: on my side, I implemented a small review process using only the tag system and search filters. - We added a link in the header menu containing two predefined searches: “Waiting pages” and “Anomaly pages”. - Each page includes a specific tag indicating its review state (waiting, verified, anomaly). The key point is that the author assigns the initial tag, and the reviewer updates it after verification. - Each page also displays a dynamic warning (using JavaScript) whenever the tag value is anything other than “verified”. <img width="1532" height="364" alt="Image" src="https://github.com/user-attachments/assets/e11e9f4e-ede1-499d-9cc6-923e2e8f955f" /> <img width="995" height="283" alt="Image" src="https://github.com/user-attachments/assets/de471576-2d76-4feb-a1f8-0cfb03bb6030" />

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#1735