Example: Create a story for each component in an epic
In this example we will show how to use Create issues and sub-tasks for creating a Story for each Component selected in Epic issue.
We have 3 components in our project ("Component A", "Component B" and "Component C"). Epic issues and Stories share the same workflow:
We want to implement a post-function in "Start Progress" transition, that will be executed only by Epic issues. This post-function will create a Story for each Component selected in Epic story. The newly created stories will have the following characteristics:
- Summary will be "Story for component component_name."
- Description will be "This is a Story automatically created for component component_name."
- Assignee will be the leader of the component corresponding to the new story
- Reporter: current user, i.e., the user who executes transition "Start Progress" in Epic issue
- Components: we select in each new Story only the component that motivated its creation
- Priority: Stories for "Component A" and "Component C" will have priority Blocker, the rest of stories will inherit priority from Epic issue
- Security Level: all the Stories created will inherit the Security Level from Epic issue
Labels: we will automatically add some labels depending on the Component that motivated the creation of the Story:
Component A:web-resource
.
Component B:sales-strategy
andmarketing
.
Component C:customer-service
anduser-experience
.Automatic transition execution after Story creation: Just after a story is created, it will be moved through the workflow to status "Frozen". To do it we execute the following 2 transitions: "Start Progress" and "Freeze Issue".
Comment: a comment with the following text will be added: "Issue frozen just after creation on current_date_time."
In order to achieve the described behavior we will use the following configuration:
Once configured, transition "Start Progress" will look like this:
Issues to be created
We use multiple issue creation based on seed strings. We need to generate a string list with each component selected in the Epic. To do it we use the following expression: toStringList(%{00094})
, where %{00094} is field code for Components.
From now on, we can reference each seed string in expressions using ^%
. We won't be able to reference seed strings when we use basic parsing mode.
Summary
We use a parsed text in advanced parsing mode with the following string expression: "Story for component " + ^%
.
Description
We use a parsed text in advanced parsing mode with the following string expression: "This is a Story automatically created for component " + ^% + "."
.
Assignee
We obtain the component leader for the component in the seed string by using advanced parsing mode with the following string expression: nthElement(toStringList(%{00125}), indexOf(^%, toStringList(%{00094})))
, where %
{00125} returns the Component leaders for selected components, and %{00094} returns selected Components in the same order as the previous field.
Reporter
We use the Current user, i.e., the user who is executing the "Start Progress" transition in Epic issue.
Epic Link
We link newly created Stories with Epic issue by setting field Epic Link in newly created Stories with the Epic Name in Epic issue.
Components
We set field Components in newly created Stories with the Component that motivated the creation of the Story, which is in seed string, i.e., ^%
.
Priority
We set field Priority using the following text in advanced parsing mode: getMatchingValue(^%, ["Component A", "Component C"], ["Blocker", "Blocker", %{00017}])
.
With this expression we are using priority Blocker for issues with Component A and Component C, and priority in Epic issue for issues with the rest of components. Priority in Epic is represented by field code %{00017}.
Security Level
We use the Security Level of the Epic issue.
New Labels
We create different labels for each component using the following text expression: getMatchingValue(^%, ["Component A", "Component B", "Component C"], ["web-resource", "sales-strategy marketing", "customer-service user-experience"])
.
Automatic Transition Execution
We write twice into virtual field "Execute transition" with the names of the transitions we want to be executed after each Story is created. The order of execution of transitions is the same as the order of writing into virtual field "Execute transition". As we are simply writing string literals (transition names), we can use basic parsing mode.
New Comment
We write into virtual field "New comment" for creating a comment in newly created stories. We use the following text in basic parsing mode: Issue frozen just after creation on %{00057}.
, where %{00057} is field code for Current date and time.
We can use basic parsing mode because we are only using field codes to be replaced by their corresponding field values. If we needed to use advanced parsing function, or seed string references (i.e., ^%
), we would need to use advanced parsing mode.
Conditional Execution
Only when boolean expression %{00014} = "Epic"
is satisfied, post-function will only be executed. This way we can use the post-function in workflows shared with other issue types.
Note that:
- %{00014} is field code for issue type
Other examples of that function
- Assign new issues to a different project role depending on field value in current issue
- Clone an issue and all its subtasks (with additional restrictions)
- Create 3 issues in 3 different projects
- Create a dynamic set of sub-tasks based on checkbox selection with unique summaries
- Create a static set of sub-tasks with unique summaries
- Create a story for each component in an epic
- Create a sub-task for each user selected in a Multi-User Picker
- Create a sub-task in each story of an epic
- Create specific sub-tasks for each selected component