56 lines
2.8 KiB
Markdown
56 lines
2.8 KiB
Markdown
# Dual-Key Status Architecture
|
|
|
|
This document defines the status management system for the Royal Enfield Workflow application. It uses a "Dual-Key" approach to resolve ambiguity between request lifecycles and business outcomes.
|
|
|
|
## 1. Core Concepts
|
|
|
|
| Key | Purpose | Possible Values |
|
|
| :--- | :--- | :--- |
|
|
| **`status`** | **Business Outcome**. Tells you *what* happened or the current granular action. | `DRAFT`, `PENDING`, `IN_PROGRESS`, `APPROVED`, `REJECTED`, `PAUSED` |
|
|
| **`workflowState`** | **Lifecycle State**. Tells you *where* the request is in its journey. | `DRAFT`, `OPEN`, `CLOSED` |
|
|
|
|
---
|
|
|
|
## 2. Status Mapping Table
|
|
|
|
The `workflowState` is automatically derived from the `status` and the finalization event (Conclusion Remark).
|
|
|
|
| Primary Status | Finalized? | workflowState | Description |
|
|
| :--- | :--- | :--- | :--- |
|
|
| `DRAFT` | No | `DRAFT` | Request is being prepared by the initiator. |
|
|
| `PENDING` | No | `OPEN` | Waiting for first level activation or system processing. |
|
|
| `IN_PROGRESS` | No | `OPEN` | Actively moving through approval levels. |
|
|
| `PAUSED` | No | `OPEN` | Temporarily frozen; `isPaused` flag is `true`. |
|
|
| `APPROVED` | No | `OPEN` | All levels approved, but initiator hasn't written the final conclusion. |
|
|
| `REJECTED` | No | `OPEN` | Rejected by an approver, but initiator hasn't acknowledged/finalized. |
|
|
| **`APPROVED`** | **Yes** | **`CLOSED`** | **Final state: Approved and Archived.** |
|
|
| **`REJECTED`** | **Yes** | **`CLOSED`** | **Final state: Rejected and Archived.** |
|
|
|
|
---
|
|
|
|
## 3. Ambiguity Resolution (The "Why")
|
|
|
|
Previously, the system changed `status` to `CLOSED` after finalization, which destroyed the information about whether the request was Approved or Rejected.
|
|
|
|
**Corrected Behavior:**
|
|
- **Outcome remains visible**: A finalized request will now keep its `status` as `APPROVED` or `REJECTED`.
|
|
- **Filtering made easy**: Dashboard charts use `workflowState: 'CLOSED'` to count all finished work, while list filters use `status: 'APPROVED'` to find specific results.
|
|
|
|
---
|
|
|
|
## 4. Technical Implementation Notes
|
|
|
|
### Schema Changes
|
|
- **`WorkflowRequest`**: Added `workflowState` (String, Indexed).
|
|
- **`status` Enum**: Removed `CLOSED` (deprecated) and `CANCELLED`.
|
|
|
|
### Transition Logic
|
|
1. **Approval/Rejection**: Updates `status` to `APPROVED` or `REJECTED`. `workflowState` remains `OPEN`.
|
|
2. **Finalization (Conclusion)**: Triggered by initiator. Updates `workflowState` to `CLOSED`. **Does NOT change `status`.**
|
|
3. **Pause**: Set `status` to `PAUSED` and `isPaused: true`. `workflowState` stays `OPEN`.
|
|
|
|
### Impacted Services
|
|
- `DashboardMongoService`: Uses `workflowState` for Facet/KPI counts.
|
|
- `WorkflowService`: Filter logic updated to respect both keys.
|
|
- `ConclusionController`: `finalizeConclusion` logic updated to toggle `workflowState`.
|