**This epic answers one question for every status change: May this status change happen, and what is needed first?**

Teams moving from Jira to OpenProject rely heavily on transition rules. Every status change answers two questions: who may make it, and what must be true before it happens. Conditions and validators are among the most used workflow features in large Jira instances. Without them, these rules would get lost in a migration. Users would then have to remember the rules themselves, and data quality would drop.

Today OpenProject can only restrict status changes per role, through the workflow matrix. It cannot ask for missing information, check field values or block a status change based on rules.

<br>

**Jira features covered by this epic (e.g. conditions and validators)**

<figure class="table op-uc-figure_align-center op-uc-figure"><table class="op-uc-table"><thead class="op-uc-table--head"><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head" scope="col"><p class="op-uc-p">Jira feature</p></th><th class="op-uc-table--cell op-uc-table--cell_head" scope="col"><p class="op-uc-p">What it does in Jira</p></th><th class="op-uc-table--cell op-uc-table--cell_head" scope="col"><p class="op-uc-p">Use case</p></th></tr></thead><tbody><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Conditions: Project Role, Group, Permission</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Only users with a certain role, group or permission can make the transition</p></td><td class="op-uc-table--cell"><p class="op-uc-p">UC1</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Conditions: Only Assignee, Only Reporter, User in Custom Field</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Only the assignee, the reporter or a user named in a field (e.g. Approver) can make the transition</p></td><td class="op-uc-table--cell"><p class="op-uc-p">UC1</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Validators: Fields Required</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Blocks the transition if certain fields are missing</p></td><td class="op-uc-table--cell"><p class="op-uc-p">UC2</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Transition screens</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Show the user a form during the status change to fill in missing information</p></td><td class="op-uc-table--cell"><p class="op-uc-p">UC2</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Condition: Value Field, scripted conditions and validators</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Allow the transition only if field values meet a rule (fixed value, other field, pattern, date, linked or child issues)</p></td><td class="op-uc-table--cell"><p class="op-uc-p">UC3</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Workflow schemes per project</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Different rules per project and issue type</p></td><td class="op-uc-table--cell"><p class="op-uc-p">UC4</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Validators: Comment Required</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Blocks the transition if a comment is missing</p></td><td class="op-uc-table--cell"><p class="op-uc-p">UC5</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Condition: Hide transition from user</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Transition only the system or API can make</p></td><td class="op-uc-table--cell"><p class="op-uc-p">UC6</p></td></tr></tbody></table></figure><br>

**Use Cases**

**Use Case 1 Restrict who can change a status**

**Only defined users can move a work package from one status to another**, based on their role, group, permission, or their relation to the work package (assignee, author, or a user named in a field such as &quot;Approver&quot;)

Example: If a user without the role Begin of the insertion&quot;Developer&quot;End of the insertion Begin of the deletion Project LeadEnd of the deletion opens a work package in status Begin of the insertion&quot;On Hold&quot;End of the insertion Begin of the deletion On HoldEnd of the deletion the status change to Begin of the insertion&quot;In Progress&quot;End of the insertion Begin of the deletion In ProgressEnd of the deletion will not be available to this user.

**Use Case 2 Mandatory information (within any field) when transitioning to/from certain status:**

Ensures users **provide the necessary information in a certain field before a work package can move into a status**. This works for standard and custom fields.
Example (**when entering a status**): If a user sets a work package to Done while a field Version is empty, or sets a work package of type Bug to Cancelled without a comment the user is asked for the information required for the target status, e.g. &quot;Set a target version to move this work package to Done&quot; or &quot;Add a reason why this work package is cancelled.&quot;

Example (**when leaving a status**): If a work package leaves “In review” and “Reviewer” is empty, the user is asked to &quot;Select a reviewer before continuing&quot;. After user adds a reviewer -&gt; status -&gt; target status

**Use Case 3 Allow a status change only if rules are met**

**Status change is blocked when field values do not meet defined rules**. Several rules can apply to the same status change. A rule can:

* compare a field with a fixed value or with another field

* check if a text follows a pattern, e.g. an ID like &quot;ABC-1234&quot;

* check related work packages, e.g. whether all children are closed


Example: If a user sets a work package to Done while no target version is set, or while a Planned Availability Date lies in the past, or the child work package is still open the user would see a dialogue &quot;This work package cannot be set to Done: a target version must be set&quot; or &quot; The planned availability date must be today or later&quot; and/or &quot;This work package cannot be set to Done: all child work packages must be closed&quot;

**Use Case 4 Project-specific rules:**
Admins can set **different rules per project and work package type**.

Example: If a project ALPHA requires a field to be updated on the status cancelled and project BETA does not, only users in project ALPHA are asked to fill out the field.

In the automations UI, you can define a scope of project(s) that the automation applies to. For ALPHA and BETA, this would imply two separate automation objects.

Note: This is more a configuration. This applies to all other use cases.

<br>

\---

**Use cases out of scope for Q1 delivery**

<br>

**Use Case 5 Mandatory information (as a comment) when transitioning to/from certain status:**

Ensures users **provide the necessary comment** before a work package can move into a status. Example (when entering a status): If a user sets a work package of type Bug to Cancelled without a comment the user is asked to &quot;Add a reason why this work package is cancelled.&quot;

Example (when leaving a status): If a work package leaves status “rejected” (e.g. reopening a work package), the user is asked to enter a comment. After user adds a comment -&gt; status transition -&gt; target status

Example 2: When closing a task, require a comment. (Workaround: define a field similar to resolution that then is required as part of the transition).

**Use Case 6 Status changes only the system can make**

Admins can set up a status change that users cannot see or select. Only automation rules or the API can make this status change.

Example: When all child work packages are closed, an automation rule moves the parent from In progress to Ready for release. Users cannot select Ready for release themselves.

<br>