Content
View differences
Updated by Rosanna Sibora 3 days ago
### 1\. Validators
**As a project administrator**, I want to attach validators to a workflow transition so that the transition is blocked if the work package does not meet defined field-level criteria at the time of execution.
Validators are checked **before** a transition executes. If a validator fails, the transition is blocked and the user receives a clear error message. Multiple validators can be stacked per transition.
**Required validator types:**
* Field X must not be empty - prevent transition if a specified field has no value
* Estimated time must be greater than 0 - enforce time entry before closing a work package
* Generic Field X must satisfy condition Y - extensible rule-based validation
**Acceptance criteria:**
* Admin can define one or more validators per transition in the workflow editor
* When a validator fails, the transition is blocked and the user sees a descriptive error message
* Validators cannot be overwritten via API calls
### 2\. Conditions
**As a project administrator**, I want to define conditions on a workflow transition so that the transition possibility is only shown to users who meet specific criteria.
Conditions control **whether a transition step is visible** to the current user. If a condition is not met, the transition step is hidden or disabled.
**Required condition types:**
* Transition visible only if current user is the assignee
* Transition available only if (custom) field Y equals value Z
**Acceptance criteria:**
* Admin can define one or more conditions per transition in the workflow editor
* Conditions are evaluated per user session and applied in real time
* Transitions hidden by conditions do not appear in the UI and cannot be triggered via API without authorization
### 3\. Post-functions
Post-functions are actions that **execute automatically after a transition completes** successfully.
**Required post-function types:**
* Set Assignee to Reporter - reassign the work package automatically after transition
* Set field X to value Y - update any specified field to a defined value
* Send notification to a specific group - trigger an in-app or email notification targeting a user group
* When parent / epic is closed, close all children.
**Acceptance criteria:**
* Admin can define one or more post-functions per transition in the workflow editor
* Post-functions execute in a defined, predictable order
* Post-functions are auditable via the work package activity log
**As a project administrator**, I want to attach validators to a workflow transition so that the transition is blocked if the work package does not meet defined field-level criteria at the time of execution.
Validators are checked **before** a transition executes. If a validator fails, the transition is blocked and the user receives a clear error message. Multiple validators can be stacked per transition.
**Required validator types:**
* Field X must not be empty - prevent transition if a specified field has no value
* Estimated time must be greater than 0 - enforce time entry before closing a work package
* Generic Field X must satisfy condition Y - extensible rule-based validation
**Acceptance criteria:**
* Admin can define one or more validators per transition in the workflow editor
* When a validator fails, the transition is blocked and the user sees a descriptive error message
* Validators cannot be overwritten via API calls
### 2\. Conditions
**As a project administrator**, I want to define conditions on a workflow transition so that the transition possibility is only shown to users who meet specific criteria.
Conditions control **whether a transition step is visible** to the current user. If a condition is not met, the transition step is hidden or disabled.
**Required condition types:**
* Transition visible only if current user is the assignee
* Transition available only if (custom) field Y equals value Z
**Acceptance criteria:**
* Admin can define one or more conditions per transition in the workflow editor
* Conditions are evaluated per user session and applied in real time
* Transitions hidden by conditions do not appear in the UI and cannot be triggered via API without authorization
### 3\. Post-functions
Post-functions are actions that **execute automatically after a transition completes** successfully.
**Required post-function types:**
* Set Assignee to Reporter - reassign the work package automatically after transition
* Set field X to value Y - update any specified field to a defined value
* Send notification to a specific group - trigger an in-app or email notification targeting a user group
* When parent / epic is closed, close all children.
**Acceptance criteria:**
* Admin can define one or more post-functions per transition in the workflow editor
* Post-functions execute in a defined, predictable order
* Post-functions are auditable via the work package activity log