QualityDocD enforces a structured approval workflow before a document can reachDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/juescoryisus/QualityDocD/llms.txt
Use this file to discover all available pages before exploring further.
Approved status. Any authenticated user can submit their own documents for review, but approval actions are restricted to users with the Reviewer, Manager, or Admin role. Every state change and reviewer decision is written to the audit log with a timestamp, user identity, and IP address.
Who can submit for review
Any authenticated user who created a document may submit it for review, provided the document is currently inDraft or PendingChanges status. Users do not need a privileged role to trigger the submission — only document ownership matters at this stage.
Full approval workflow
Author creates the document
The document is saved with status
Draft. The author fills in all required metadata and optionally attaches a file. See Managing Documents for details on the creation form.Author selects reviewers and submits
From the document detail page, the author checks one or more reviewers from the Submit for Review panel and clicks the submit button. This posts to:The form payload includes the
DocumentId and a list of ReviewerIds. Only active users with the Reviewer or Manager role (excluding the document author) appear in the reviewer list. Each selected reviewer is assigned an ApprovalOrder (1, 2, 3, …) in the order they are submitted.| Document was in | Status becomes |
|---|---|
Draft | UnderReview |
PendingChanges | UnderSecondReview |
When a
PendingChanges document is resubmitted, all previous DocumentApproval records for that document are cleared before the new reviewer assignments are created. This gives reviewers a clean slate for the second round.Reviewers take action
Each assigned reviewer sees a review panel on the document detail page. The panel appears only when the document is
UnderReview or UnderSecondReview and the reviewer has a Pending approval entry. Three actions are available — see Reviewer actions below.All reviewers approve → document is promoted
When the last reviewer approves, the system checks whether every
DocumentApproval record for the document has Status = Approved. If so, the document status automatically advances to Approved and ApprovedAt is set to the current UTC time. No manual promotion step is required.Author revises (if changes were requested)
If a reviewer requested changes, the document moves to
PendingChanges. The author edits the document (optionally uploading a new file, which increments the version number) and then resubmits for a second round of review (step 2), which transitions the document to UnderSecondReview.Reviewer actions
Approve — POST /Documents/Approve/{id}
Approve — POST /Documents/Approve/{id}
Records the reviewer’s decision as Outcome: The approval entry is marked
Approved on their DocumentApproval entry. An optional comment can be provided but is not required.Approved with a ReviewedAt timestamp. An ApprovalReviewed audit entry (old: Pending, new: Approved) is logged. If this was the last pending reviewer, the document moves to Approved and a StatusChange audit entry is logged.Required role: Admin, Manager, or Reviewer.Request Changes — POST /Documents/RequestChanges/{id}
Request Changes — POST /Documents/RequestChanges/{id}
Indicates the document needs corrections before it can be approved. A comment is required and must describe the changes needed.Outcome: The reviewer’s
DocumentApproval entry is set to RequestChanges. The document status immediately changes to PendingChanges. A StatusChange audit entry is logged with old status and PendingChanges as the new value.Required role: Admin, Manager, or Reviewer.Reject — POST /Documents/Reject/{id}
Reject — POST /Documents/Reject/{id}
Permanently rejects the document. A comment is required and must state the reason for rejection.Outcome: The reviewer’s
DocumentApproval entry is set to Rejected. The document status changes to Rejected and RejectedAt is recorded. A StatusChange audit entry is logged.Required role: Admin, Manager, or Reviewer.The PendingChanges revision loop
When a reviewer requests changes, the document enters a revision cycle:- Reviewer calls
POST /Documents/RequestChanges/{id}→ document becomesPendingChanges. - Author edits the document at
GET /Documents/Edit/{id}(only possible inDraftorPendingChangesstatus). - Author resubmits via
POST /Documents/SubmitForReview→ document becomesUnderSecondReviewand previous approvals are cleared. - Reviewers review again. If all approve, the document moves to
Approved.
Audit trail
Every state change in the workflow is recorded in the audit log with the following information:| Field | Description |
|---|---|
Action | One of StatusChange, ApprovalReviewed, Created, Updated, Downloaded |
OldValue | The previous status or approval state |
NewValue | The new status or approval state |
UserId / Username | The user who triggered the change |
IpAddress | The remote IP address of the request |
CreatedAt | UTC timestamp of the event |
AuditLogs table (accessible from the document detail page) and to the PostgreSQL audit_entries table (accessible from the PHP portal’s audit page).
Viewing status in the PHP portal
Reviewers can check the current status of a document and browse its audit history in the PHP portal. The portal reads directly from the PostgreSQLaudit_entries table, so it reflects the same events shown in the .NET application’s History panel.