Content
View differences
Updated by Rosanna Sibora 2 days ago
## User story
**As a** Jira administrator.
**I want to** configure dynamic, status-dependent field requirements and input masks for issue types on a project level (not globally).
**So that** I can enforce proper data collection at each workflow stage and ensure users provide the right information before progressing issues through their lifecycle.
## Prerequisite for this story
<mention class="mention" data-id="39103" data-type="work_package" data-text="##39103">##39103</mention>
## Business value
* **Improved Data Quality:** Ensures critical information is captured at the right workflow stages
* **Process Compliance:** Enforces business rules and approval gates automatically, guides users through the process
* **Reduced Errors:** Prevents incomplete or invalid status transitions
* **Flexibility:** Adapts field requirements to different issue types and workflows
## Examples of use cases
* Specific actions (e.g. comments) may be required to change the status. For example when a ticket is set to "cancelled" an additional comment should be mandatory, so that users need to explain the reason why an issue was cancelled.
* Approval workflow: Approvals are handled by specific individuals, tied to the status.
<br>
## Acceptance criteria
### Dynamic input masks on status transition
* [ ] When user attempts to transition an work package to a new status, system displays a modal/dialog with new (required) fields
* [ ] Modal shows only fields relevant to the target status (not all issue fields)
* [ ] User cannot complete transition until all mandatory fields are filled with valid data
* [ ] System provides clear validation messages for incomplete or invalid fields
* [ ] User can cancel transition and return to work package without saving changes
* [ ] Define conditions for transitions to cover edge cases, e.g. you can go from A to B, but depending on XYZ
### Status-specific mandatory fields configuration
* [ ] Administrator can define mandatory fields per status per work package type via workflow configuration
* [ ] Administrator can specify field requirements for:
* Entering a status (fields required when transitioning TO this status)
* Exiting a status (fields required when transitioning FROM this status)
* [ ] System supports all standard field types
* [ ] Custom fields are fully supported
### Read-Only Field Controls
* [ ] Administrator can configure fields to become read-only based on:
* Current issue status
* Specific field values (e.g., when "Approved" = Yes)
* [ ] Read-only fields are visually indicated (greyed out, lock icon)
* [ ] System prevents editing of read-only fields via UI and API
* [ ] Administrator can define exceptions (e.g. Project Admin can always edit) (TBD)
* [ ] Read-only rules apply consistently across:
* Issue view/edit screens
* Bulk edit operations
* API requests
* Automation rules
* [ ] Hover tooltips explain why fields are read-only
### Configuration Interface
* [ ] Workflow editor includes "Field Behavior" configuration tab for each status
* [ ] Visual workflow diagram indicates statuses with special field requirements (badge/icon)
* [ ] Configuration wizard guides administrator through setup:
1. Select status
2. Define (mandatory) fields
3. Set required actions
4. Configure approvers (if applicable)
5. Define read-only fields
* [ ] Configuration supports copy/paste between statuses and issue types
* [ ] Preview mode shows what users will see during transition
**As a** Jira administrator.
**I want to** configure dynamic, status-dependent field requirements and input masks for issue types on a project level (not globally).
**So that** I can enforce proper data collection at each workflow stage and ensure users provide the right information before progressing issues through their lifecycle.
## Prerequisite for this story
<mention class="mention" data-id="39103" data-type="work_package" data-text="##39103">##39103</mention>
## Business value
* **Improved Data Quality:** Ensures critical information is captured at the right workflow stages
* **Process Compliance:** Enforces business rules and approval gates automatically, guides users through the process
* **Reduced Errors:** Prevents incomplete or invalid status transitions
* **Flexibility:** Adapts field requirements to different issue types and workflows
## Examples of use cases
* Specific actions (e.g. comments) may be required to change the status. For example when a ticket is set to "cancelled" an additional comment should be mandatory, so that users need to explain the reason why an issue was cancelled.
* Approval workflow: Approvals are handled by specific individuals, tied to the status.
<br>
## Acceptance criteria
### Dynamic input masks on status transition
* [ ] When user attempts to transition an work package to a new status, system displays a modal/dialog with new (required) fields
* [ ] Modal shows only fields relevant to the target status (not all issue fields)
* [ ] User cannot complete transition until all mandatory fields are filled with valid data
* [ ] System provides clear validation messages for incomplete or invalid fields
* [ ] User can cancel transition and return to work package without saving changes
* [ ] Define conditions for transitions to cover edge cases, e.g. you can go from A to B, but depending on XYZ
### Status-specific mandatory fields configuration
* [ ] Administrator can define mandatory fields per status per work package type via workflow configuration
* [ ] Administrator can specify field requirements for:
* Entering a status (fields required when transitioning TO this status)
* Exiting a status (fields required when transitioning FROM this status)
* [ ] System supports all standard field types
* [ ] Custom fields are fully supported
### Read-Only Field Controls
* [ ] Administrator can configure fields to become read-only based on:
* Current issue status
* Specific field values (e.g., when "Approved" = Yes)
* [ ] Read-only fields are visually indicated (greyed out, lock icon)
* [ ] System prevents editing of read-only fields via UI and API
* [ ] Administrator can define exceptions (e.g. Project Admin can always edit) (TBD)
* [ ] Read-only rules apply consistently across:
* Issue view/edit screens
* Bulk edit operations
* API requests
* Automation rules
* [ ] Hover tooltips explain why fields are read-only
### Configuration Interface
* [ ] Workflow editor includes "Field Behavior" configuration tab for each status
* [ ] Visual workflow diagram indicates statuses with special field requirements (badge/icon)
* [ ] Configuration wizard guides administrator through setup:
1. Select status
2. Define (mandatory) fields
3. Set required actions
4. Configure approvers (if applicable)
5. Define read-only fields
* [ ] Configuration supports copy/paste between statuses and issue types
* [ ] Preview mode shows what users will see during transition