The Status Rollup Effector automatically updates parent issue statuses based on the earliest status of their sub-issues. For example, if all sub-issues are Resolved, it will update the parent issue's status to Resolved; but if one sub-issue is still In Progress, the parent issue will be set to In Progress.
Adding a Status Rollup Effector to a Structure
To add a Status Rollup Effector to a structure, open the Automation menu and select Effectors.
Choose Status Rollup...
On the Effector setting screen:
- Name: this field is updated automatically as you select the Effector properties. If you prefer, you can also click the edit button to enter a custom name.
- Projects: select the projects that should be updated by the rollup. To include all projects, toggle All projects.
- Issue types: select which issue types should be considered by the rollup. To include all statuses, toggle All types. Note: If your structure contains issue types not included here, the Effector will not make any changes to those issues OR their ancestors (items above them in the structure).
- Resolution: this resolution will be used whenever an issue is moved to a "resolved" state (based on the project's workflow).
- Select whether email notifications should be sent when the Effector writes values to Jira
- Set statuses based on the following order: select the statuses that should be considered by the Effector, and place them in order from earliest status to latest. If you do not want the Effector to move issues to a specific status, do not include it here. For example, leaving out "Done" will prevent issues from being closed when all their sub-issues are Done.
When you're finished, click Save and Run to run the Effector immediately, or click Save to simply add the Effector to the structure but not run it yet.
How the Status Rollup Effector Works
When you run the Effector, it updates the status of parent issues to the earliest status of their sub-issues, based on the project(s), issue type(s), and status order you chose in the configuration.
Let's take a closer look at how this works.
- We configured our Effector to our DOC project, selected ALL issue types, and set our statuses (To Do, In Progress, Done).
- BEFORE running the Effector, our statuses looked like this:
- AFTER running the Effector, the following status changes were made:
- Story 2 was moved to DONE, because it's only sub-issue, Story 3, was DONE.
- Story 1, Story 4 and Story 5 all share a sub-issue (Task 1) with the earliest possible status (TO DO), so they were all moved to TO DO.
Statuses that are not selected in the settings are not recognized by the Effector. If a sub-issue has one of the unselected statuses, it will not affect it's parent issue. Additionally, if a parent issue has an unselected status, it will not be updated by the effector, even if one of its children has an earlier status.
This can be useful if you want to prevent issues from being transitioned to or from certain statuses. For example, if you omit DONE from your list of statuses, no issue can be moved to or taken out of DONE status by the Effector.
Missing Issue Type
If an issue type is not selected in the settings, the Effector will not change the issue's status or the status of any of its ancestors (issues above it in the structure).
For example, in our example above, if we had not included Tasks in our list of issue types, the Effector would have ignored Task 1 and Task 2, and it would not have changed the statuses of any of their ancestors (Issues 5, 4, and 1).
Running the Effector
Once you've added the Effector to a structure, you need to run it for changes to take place. See Running an Effector
Review / Revert Changes
To review or revert changes made by an Effector, see Revert Effector Changes