How to run a subtask unconditionally from a transition

[Phil Bustin]

I can't seem to recall or find how to run a subtask  unconditionally from a transition.

[John Funk · Accepted solution]

Hi Phil - What do you mean by "run a subtask"? Can your describe in a little more detail what you are trying to do? 

[Phil Bustin]

When the user selects a certain transition in a workflow, automatically submit into a subtask workflow--perhaps not Jira terminology, but I think the gist is there.  I also need to configure some entity so that when the subtask is complete, the next transition in the parent will run. 

I'm pretty sure I'll find the solution to each of the two requirements in one or two Atlassian courses.  I probably already found and implemented them in a test workflow I created quite some months ago in my personal account, but I only did it once, don't recall how, and can no longer find the automations I created.

[John Funk]

Sorry, but still not following you - I don't know what you mean by "submit into a subtask workflow". Can you be more descriptive? When I transition this sub-task issue, then I want the parent to do transition to another status, etc. 

[Phil Bustin]

Sorry: I have two workflows (A & B).  In Workflow A, a Developer promotes code through ascending promotion regions; in Workflow B, an assignee tracks code promotion.

When the Developer selects the transition (call it "Request Tasks" that requests code promotion to a region in workflow A, automatically run the submit transition into workflow B, mapping certain fields.  I think in this context, workflow B is called a subtask in accepted terminology.

When the subtask is complete, the next transition ("Tasks Complete") in workflow A will fire.

----------------------

Further, the Developer may check multiple checkbox fields and fill in paired instruction fields in the Request Tasks transition form.  If so, one subtask will be generated for each checkbox checked, each with its own default signee (a group assignee), and each paired instruction field will be mapped to workflow B's Description field.

[John Funk]

So, let me see if I have it. When an issue is transitioned to a particular status, you want a new sub-task created automatically based on the value(s) of a field. If there are multiple values checked, then multiple issues are created. Is that correct? 

[Phil Bustin]

That sounds correct.  To me, the procedure seems as though it should be commonly used, yet I haven't so far found a solution.

The transition to the particular status in workflow A has a form.  If the user checks any of 7 checkboxes in that form, one or more subtasks in workflow B equal to the number of checkboxes checked (usually one or two) will be created.  Depending on the checkbox, a subtask will be assigned to a group or role, and the subtask Summary will automatically default to an appropriate value ("Software Move"; "Schedule"; etc.), and the parent transition instruction field that is paired with a checkbox will be mapped to the subtask Description field. 

The subtask has a simple workflow: Submit Dev Task ("Create" renamed) to status "Assigned"; transition "Done" to status "Task Completed".  There are other fields that will be mapped if filled in.  Hopefully, automation will also validate field content and field validity, depending on whether other fields are filled in, and other fields' values.

[John Funk]

Yes, this sounds pretty straight forward. 

Created a rule an Issue Transitioned trigger. 

Then add an If / Else block condition. 

For the first If condition, choose add condition then use Issue Fields Condition. Choose your checkbox field and the value of one of the 7. 

Then add a new action for Create issue and chose the fields you want to populate and the values for each field. Choose sub-task for the Issue Type. 

The click on the Add else option in the left-hand side and continue in the same fashion for each of the 7. 

[Phil Bustin]

Thanks.  Trying to do that now, but I need to amend the requirement as follows: There are only 6 checkboxes, not 7, because there will unconditionally be a software move subtask, so no need for a checkbox for that.

Or, if I want to tailor the transition to my rule, I could include the software move checkbox, but set it to default to checked, and not display it.

If I omit the software move checkbox as I prefer to do, what will that require for automations and rules?  I'm not sure how to proceed with the combination of no conditions for one subtask, but conditions for additional subtasks.

So far, I created a Rule for a non-conditional (unconditional) action (create sub-task that is my new issue type, Dev Task), with the idea of creating a conditional action for creating additional subtasks.

[Nic Brough -Adaptavist-]

Automation does not have functions for moving issues - issue moves should not be part of a standard process, they are for housekeeping, migration and genuine "oops, created in completely the wrong space" mistakes.

[Phil Bustin]

Thanks, but I'm not trying to move an issue; just trying to run one or more subtasks.

[John Funk]

@Phil Bustin  - so what's different about not having the 7th option that needs to change what you have so far? And can you share the rule and what's missing with the functionality that you want? 

[Nic Brough -Adaptavist-]

I'm not sure what "run a subtask" means.

Nor "move", but I am sure that is due to me living in the Atlassian ecosystem for so long - in Jira-speak, "move" means "make a structural change to an issue, like changing the project it is in, or the issue type that all the config hangs off"

As John said, I think we're missing a definition of what you want the 7th option to do.

[Phil Bustin]

I haven't looked at my rule for a few days, but here it is:

It is for the remaining optional tasks (there are actually 7 other tasks, or 8 including the software move task that will always be created in this automation), that I need a rule to submit into the Dev Task workflow if one or more task's checkbox is checked and its paired instruction field contains an entry (is filled in by the user).

To summarize again, always submit a Dev Task of the type Software Move.  Also submit a Dev Task for any checked checkbox and filled in instruction field.

Hope this info is helpful.

[Phil Bustin]

incidentally, the rule has errors at the moment:

[Nic Brough -Adaptavist-]

I'm very confused here now.

Your automation is trying to create a sub-task.  Why are you calling it "move"?  It is not a "move" as I explained before.  Also, what does "run a sub-task" mean?

The errors you are getting are because you are not feeding the "create sub-task" all the fields you have set to be required on sub-tasks.

(Incidentally, you appear to have "Story points" on sub-tasks.  Don't do that, it will break all your attempts to use Scrum or Kanban, unless you've set up other automations that can cope with it by tricking Jira to look at it in quite a clever way)

[Phil Bustin]

The title of the sub-task refers to the purpose--to track a user's PVCS (or is a few cases, non-PVCS) software promotion ("move" from one promotion group to the next). The word 'move' has nothing to do with the Jira parent or child workflow per se.

I sent my reply before I had a chance to address the error--sorry about that.  I understood the cause.

The story points are there because the Sandbox project contains them globally, apparently.  Scrum and Kanban will never be used for these subtasks, though.

I asked a different Community question: Why isn't my transition screen appearing?  Must be something obvious I neglected to connect.  I'd as soon solve that before I take up the sub-task again.

[Nic Brough -Adaptavist-]

Ok, that's really helpful. Thank you!

I can now ignore "move" in Jira-speak. It means "update an issue" in this case.

You are outside a Scrum/Kanban structure, so your story points will probably do what you need.  I strongly recommend that you don't touch Scrum boards here, but project and Kanban boards could still be very useful. 

Kanban boards might need a little user education on "we're not doing Kanban, but we're using a Kanban tool, so 'done' might look a bit odd", but I've never found anyone who doesn't get that - I've always booked hour-long meetings to explain it, and then found the remaining 55 minutes long enough to go have a coffee or swift pint with the attendees.

I don't think this is the right place to talk about the transition screen (they should appear if you add them to a company-managed workflow, team-managed ones don't yet do them, but that is a different conversation you've already started)

[John Funk]

Yes, remove the Story Points field from the Create screen. And click the Add fields option beside the name of each Sub-task creation and make sure there are values for each required field for the Sub-task. Get the 7 done then we can deal with the 8th one. 

[Phil Bustin]

Story Points and the other field are not in the parent transition screen (I renamed the transition and the screen "Request Dev Tasks").  I suspect the configuration I inherited needs to change, and I don't know why Story Points and Business Analyst are somehow present in the sub-task workflow and required.  I created a screen for  the sub-task workflow create transition, and those fields are not on the screen.

Also, assuming I solve the required fields problem, I don't know how to set a default value for Summary, so that in the sub-task workflow, it has the appropriate value; and I don't know how to map field "Instr - Software Promote" in the parent transition to "Description" in the sub-task, or sub-task create transition.

[John Funk]

Alright, let's take this in steps. First, remove the Story Points field from any screen that project is using - most importantly the Create screen if it is there. The transition screen is not the problem. 

Next, can you share the rule that you have create so far? 

Finally, I am still not following your flow. Are the check boxes you are using a Checkbox field in Jira? Or is it a third party Checklist app? 

[Phil Bustin]

Thanks for the tip!  I see Story Points in the Create transition of the parent workflow.  There's no screen for that transition, however.  I inherited the project, or issue type, and Story Points may be a field I won't receive permission to remove.

If I want to remove Story Points anyway, in the Sandbox, I'm not sure I can.  It may be configured to exist across all entities in the Sandbox.

Can I just deal with it in the sub-task?  Set a value (1) and be done with it?

Here is the rule:

- and -

The checkbox is a Jira standard field.  Here it is in the Request Tasks transition screen:

[Phil Bustin]

I got the automation to run successfully by providing values to the required fields.  It occurs to me that I can do that instead by doing so in the parent transition instead.

Question: Where would I find the subtask issue, if it was created?  There's no link I can see in the parent issue.

The parent and sub-task are issue types.  I see that there is a Field Configuration associated with each.  I made them optional in the sub-task issue type and removed them from the rule.  It worked.

I have 3 questions at the moment:

1) I apparently need to replace the workflow assigned to my sub-task issue type with the Dev Task workflow I created, but I can't find a function to do so.  Here is the Issue Type page, showing the correct workflow assigned to the Dev Story issue type, but an inherited workflow assigned to the Dev Task issue type:

One clue may be that when I look at the workflows view, and then try to assign the Dev Task workflow, there is no Dev Task issue type in the dialog box that follows:

 

2)  I'm still searching for the issues presumably created when my rule ran successfully a couple of times.  They're not in the project > Reported by me list.

3) Can fields be mapped to fields with different names, from the parent to the subtask?  Perhaps this is the answer: https://confluence.atlassian.com/jirakb/how-to-automatically-map-fields-of-a-parent-ticket-to-a-new-sub-task-in-jira-cloud-779160741.html

[Nic Brough -Adaptavist-]

Great to see it's close to doing what you need!

> Where would I find the subtask issue, if it was created?  

The full issue view has a "sub tasks" panel - once you have created one sub-task.   You can also see them on boards if you do swimlanes by story (and in a couple of other configs)

> 1) I apparently need to replace the workflow assigned to my sub-task issue type with the Dev Task workflow I created, but I can't find a function to do so.  

This is done in two places.  First, get the "tech support & BI support workflow scheme - v2" doing the mappings you want (which seems to be right already from what you've said).  When you're happy with that, go back to the project -> project admin -> Workflows, and look for "switch scheme" - it will ask you which one to go to, select your new one and save it.  It will walk you through a migration if it is needed

>2)  I'm still searching for the issues presumably created when my rule ran successfully a couple of times.  They're not in the project > Reported by me list.

Check that the Automation is set up to run as the current user or you.  Also check one of the created sub-tasks to see who it is being reported by.  You may need to add a line to the Automation to set the reporter

> 3) Can fields be mapped to fields with different names, from the parent to the subtask? 

Yes, but it's a bit fussier than having a simple "Copy field A down to field A"

[Phil Bustin]

I found the sub tasks panel; I wonder why I didn't notice it yesterday.

See my comments:

> 1) I apparently need to replace the workflow assigned to my sub-task issue type with the Dev Task workflow I created, but I can't find a function to do so.  

This is done in two places.  First, get the "tech support & BI support workflow scheme - v2" doing the mappings you want (which seems to be right already from what you've said).  I do not know what that means.  When you're happy with that, go back to the project -> project admin -> Workflows, and look for "switch scheme" - it will ask you which one to go to, select your new one and save it.  I found "switch scheme", but could not figure out what to do with it.  ... - v3 appeared, but when I selected it, it showed one of my two workflows with every status pointing toward a To Do status.  It did not show the workflow I need to associate with my Dev Task sub-task.  It will walk you through a migration if it is needed

> 3) Can fields be mapped to fields with different names, from the parent to the subtask? 

Yes, but it's a bit fussier than having a simple "Copy field A down to field A

But how is it done, please?  I can of course try to find the answer myself.  I found https://bobswift.atlassian.net/wiki/spaces/CSOT/pages/41975942/How+to+copy+a+custom+field+value+to+another+field

but I doubt I can obtain the apparent 3rd part software

and

https://docs.adaptavist.com/sr4jc/latest/features/built-in-scripts/copy-custom-field-values-to-another-field

but I'm not sure I'll be allowed to obtain ScriptRunner, even though it is free.

For now, instead of mapping each of 7 or 8 instruction fields in the parent to Description in the sub-task, I could just create 8 separate custom fields.  How would I be able to display only the appropriate one in each subtask--use a condition of not empty?  Or, I could create another 7 issue types, all using the same workflow.  What do you think?

[Nic Brough -Adaptavist-]

To change the workflows a project uses, you change the workflow scheme.  Either edit the existing one (which may affect other projects), or create a new one and edit that.

You said you'd already created a new scheme, and amended it to map the workflows you want on to the issue types.

So all you need to do next is swap the project to use the new scheme.

But you seem to have moved on to a -v3 scheme which does not have the right mappings.  You need to edit that to get the mappings you want before swapping to it.

On the field copying, look to "Automation" - this lets you copy data from field to field.

[Phil Bustin]

I want to modify the key of my sub-task, to easily identify it, but I can't without modifying the key of the parent, and all other entities in the project.  That leads me to the conclusion that the sub-task should be in a new project.  Please confirm.

[Phil Bustin]

I seem to have narrowed down the problem with establishing my sub-task workflow.  It looks right in the Workflow view (below), but that is a Draft.  However, when I try to publish the draft, I'm tasked with changing inherited statuses.  I thought when I created a new Issue Type (Dev Story) (or did I?), that it would not impact existing items.  I was apparently mistaken, and I don't understand why.

Original workflow scheme

Draft workflow scheme

Publish workflows

[Phil Bustin]

I have resolved the important issues.  I learned that the status mapping was just a routine action in case there were issues with the old workflow statuses, so I simply published the workflow scheme with all the old statuses going to Resolved (or whatever it was).  

I am now OK with the key prefix being the same in the sub-task as the parent, and I was informed that my new workflows can be associated with multiple projects, so I won't have to re-create them.

I was also offered "{{issue.summary}}" (as an example), a syntax in the Description field Set option, that may work for mapping a field to Description, which is my goal.  A challenge will still be how to do that in one transition for multiple sub-tasks.  Perhaps you can suggest a solution.

Also, what I’m looking in field mapping may still pose a challenge: I have 7 checkboxes in my transition screen—one for each kind of task (sub-task) other than Software Move task; a Software Move subtask is always created, while other types are only created if their checkbox is checked and their instruction field is not empty.  (I'm hoping my automation can handle that).

My preference is, for each sub-task, the instruction field for that sub-task will be copied to Description.  I’m hoping one or multiple automations can launch multiple sub-tasks, each with the appropriate instruction field mapped to Description in each sub-task.

I have the option of having 8 separate instruction fields that are copied to the appropriate instruction field in the sub-task, but then I’d have to hide 7 of the 8 fields in any sub-task created. 

[Phil Bustin]

Nic - you stated:

On the field copying, look to "Automation" - this lets you copy data from field to field.

Did you mean that my only practical solution, if I can't obtain authorization to add 3rd party apps for mapping fields, is to use the 8 or so individual fields and copy them from parent to child?  Or did you mean the option shown below can be used for mapping a field to a different field?

[Nic Brough -Adaptavist-]

Um, that json is part of an automation...

[Phil Bustin]

Yes--It appears when I click 'More' in the automation.  I thought it might be used to copy a field to a different field.

[John Funk]

Hey Phil - how are you getting on with this? Do you have your rule for the 8 items yet? What's still missing? 

[Phil Bustin]

I just now set up another subtask action with a condition that the checkbox had to be a certain value, and automation worked.  I was able to create two subtasks from my transition.  However, until I find out how to map an custom field to Description, I have no other option than clicking Copy in my automations for each of 8 instruction fields from parent to child--not a problem, except I'd want to hide the other 7 fields in the Assigned status of the child for any subtask, and I don't know yet how to do that.

I'm pretty sure I copied a field to a different field in an automation on my personal account a year ago, but I haven't found the automation or any documentation I created, yet.  I have to look again.  Somewhere in the Community postings, or on the Internet, there must be a sample json or {{[custom field name]}} in the Set option that would do this.  I seem to recall that I had to perform some function to find the correct syntax for the custom field name, to use in the automation Copy function, or in the More > json in the automation.

[John Funk]

So the Description should just look something like: 

{{issue.Some Field}}  where Some Field is the exact name of the custom field you are copying into it (including case). If it is coming from the trigger issue, then it is:

{{triggerIssue.Some Field}}

[Phil Bustin]

This is working!!!!  Thank you.

[John Funk]

WOOHOO!!  Thanks so much @Nic Brough -Adaptavist-  with all of your assistance and patience with this. And thanks to you @Phil Bustin for your perseverance. 

[Phil Bustin]

Eternally grateful.