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

[mikeyz24]

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

[tiredofit]

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

[BFjimmy]

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?

[BFjimmy]

@ssddanbrown Any thoughts on my suggestion?

[ssddanbrown]

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.

[BFjimmy]

Thanks for the reply @ssddanbrown