Implementing an approval workflow

[MarcBollmann]

Hello, I'm considering to try helping with the implementation of the approval feature which is planned to release in version 3.0. I want to know if there are already any implementation plans or general plans for doing so.

My first thought was that you could handle a general approval workflow by permissions if a review is not mandatory. For example approve:pages. For pages, there could be property for an optional opt-in like requireApproval: {type: 'boolean'}. For checking if a page is approved we could add the property: isApproved: {type: 'boolean'}.

requireApproval: {false} -> which should be default would let the pages behave as they have always been working
requireApproval: {true} -> disables/replaces the SAVE Button with a Request Approval button -> if the button gets pressed the reviewing-group (and not the user himself) gets a notification.

If the reviewer is clicking the notification which links to the unpublished page there is still some work to do like someone already mentioned:
When a moderator (a role that can create and edit pages) posts a page for later (a given date) this page is not shown to others. If a QA (another role that can edit pages) likes to review the page he/she cannot see it. There is no model for unpublished pages and therefore is no possibility for roles to see unpublished pages. How do we handle the unpublished pages?

These are my initial thoughts about that functionality. What are your thoughts about it? I can imagine in some companies there are even more complex situations with approval workflows with more users involved.

[jokay]

@NGPixel I wonder if you have already added this to the roadmap, seems to me a really useful and needed functionality?

[jokay]

@NGPixel any updates about this feature's plan since 13.07.2019?

[prodigy7]

Would also be very interested in hearing about the current status. I currently have a client who likes your system but needs the functionality for approvals. Maybe we could support you temporarily with man power or contribute financially if it helps to implement the functionality in a timely manner.

[timsamart]

I strive to enhance Wiki.js, particularly for those who utilize it within regulated sectors, I find it pressing to incorporate an approval process that aligns with FDA 21 CFR Part 11 regulations.

Here are the key features I'm proposing:

Multi-step Approval Process: My goal is to build a system where admins can construct workflows involving at least three individuals. Each document should go through a thorough process where it's reviewed, potentially amended, and then approved by each participant sequentially.

Electronic Signatures: I believe we need a system where every approval or rejection in the workflow is authenticated with the user's unique electronic signature, alongside additional information to confirm the identity of the signer.

Audit Trails: I propose our system automatically create secure, time-stamped audit trails that independently record the date and time of operator entries and actions. This includes all actions that create, modify, or delete electronic records. These audit trails should be unalterable and readily available for review.

Record Retention: It's crucial for us to preserve a history of all changes made within the wiki. This should include details about who made each change, the timestamp, and the nature of the change.

This proposal is greatly inspired by the system used by Comala (https://docs.comalatech.com/space/CDML/6753945277/Switch+between+draft+and+published). Interestingly, some of these components are already present in Wiki.js, and my aim is to fully integrate these FDA 21 CFR Part 11 compliant components into our existing framework.

I welcome your thoughts, suggestions, and potential contributions on this matter.

[timsamart]

also sorry for gpt4 it just sounds better then my crappy english :)

[NGPixel]

@timsamart See #6556, #6557 and #6558

No plan for electronic signatures at the moment as this is its own can of worms.