Review Workflow

Use a review when a test case needs another person’s approval before it is ready.
Open Test Case Management, choose a case, and open its Review tab. Submit
the case, invite a reviewer, and follow comments and decisions in one place.

About URLs in examples: all examples use localhost:5770 as the default Mockarty address. If your instance runs on a remote server, replace localhost:5770 with its actual address. See Tips & Useful Features for details.

Related pages: Test Case Management · Notification Channels · Webhooks & Callbacks

Concepts

Case under review — a saved test case with a review state: draft, in_review, approved, changes_requested, rejected, or archived. Submission records the case version being reviewed.
Reviewer — a person who can approve, request changes, or reject. A reviewer may be required or optional.
Comment — a discussion note, which may refer to a particular step or field.
Timeline — the record of submissions, reviewer changes, comments, and decisions.

Default policy

One required approval completes the review.
The person who submitted the case cannot approve it themselves.
A reviewer can request changes or reject the case. After you revise and resubmit, reviewers vote on the new version. Earlier comments remain visible.

The required reviewers and review state are visible on the case’s Review tab.

API surface

All endpoints live under /api/v1/namespaces/:namespace/review/.

Method	Path	Purpose
`GET`	`/review/subjects`	List subjects, optionally filtered by `kind` / `status`.
`GET`	`/review/subjects/entity/:kind/:subjectId`	Get the current subject for a target entity (lookup by owning kind + id).
`POST`	`/review/subjects/entity/:kind/:subjectId/submit`	Transition from `draft` → `in_review`. Body may list reviewer user IDs.
`POST`	`/review/subjects/:id/withdraw`	Submitter-only: take the subject back to `draft`.
`POST`	`/review/subjects/:id/reviewers`	Assign a reviewer.
`DELETE`	`/review/subjects/:id/reviewers/:userId`	Remove a reviewer.
`GET`	`/review/subjects/:id/comments`	List comments (threaded).
`POST`	`/review/subjects/:id/comments`	Add a comment. Body: `{body, format, anchorPath, parentId}`.
`POST`	`/review/subjects/:id/comments/:commentId/resolve`	Flip a comment’s `resolved` flag.
`POST`	`/review/subjects/:id/approve`	Reviewer votes approve.
`POST`	`/review/subjects/:id/request-changes`	Reviewer votes request changes + comment.
`POST`	`/review/subjects/:id/reject`	Reviewer votes reject.
`POST`	`/review/subjects/:id/archive`	Move to `archived` (terminal).
`GET`	`/review/subjects/:id/events`	Timeline.

UI integration

In Test Case Management, select a case and open Review. The tab shows the
current state, reviewers, comments, and decisions. Available actions depend on
your permissions; decisions made by another reviewer appear without a reload.

Events & notifications

The review service emits events through the outbound webhook bus on every transition:

review.submitted, review.withdrawn
review.reviewer_added, review.reviewer_removed
review.commented, review.comment_resolved
review.approved, review.changes_requested, review.rejected
review.archived, review.revision_bumped

Subscribe via Settings → Webhooks (HTTP / Kafka / RabbitMQ) or the Notification Channels
for Slack / Telegram / email / bell. The payload always carries {namespace, kind, subjectId, actor, snapshot} plus the transition-specific extras.

RBAC

review:view — implied by namespace read.
review:comment — required for POST /comments and /resolve.
review:review — required for vote endpoints (approve, request-changes, reject).
review:manage — required for archive and reviewer assignment.

All actions are audited: verbs review_submitted, review_withdrawn, review_reviewer_assigned, review_reviewer_removed, review_commented, review_comment_resolved, review_approved, review_changes_requested, review_rejected, review_archived.