Coping the Account from a Story to all of it's Sub-Tasks

[Terry Booth]

I have tried and failed to create an automation to copy the Account field on the Story to all associated Su-Tasks. See screen shot below. When I try to set the Account at the Sub-Task level, I don't get any viable options and the automation fails. Can anyone help?

[Trudy Claspill · Accepted solution]

Hello @Terry Booth 

What is the first For Stories branch for? That would have no impact on setting Subtask issue values.

In the second branch in the Edit action you have shown, click the ... button to the right of the value entry field.

Select the COPY option.

That will show you something similar to this in the field (where Assignee would be Account in your view).

Click on the text displayed, where I'm pointing with the arrow. This will give you a pop-up like this.

Change Current Issue to Trigger Issue or Parent Issue

[Terry Booth]

Thank you for your input. I removed the first branch for Stories and modified as you suggested and received the following errors. The sub-tasks and account information at the story level does exist.

[Trudy Claspill]

Does the Account field exist in the subtask issues and is the field present on the Edit screen for that issue type?

[Terry Booth]

Yes to both

[Trudy Claspill]

Can you share a screen image of GRNPROD-3597 showing the Subtasks section showing the issue keys for that issue's subtasks?

Can you share a screen image of GRNPROD-4781 showing that the Account field is present and editable?

Who is the Actor for the rule? Does that Actor have adequate permissions in the GRNPROD project to edit the Account field?

[Terry Booth]

See screen shots. I am the actor and I am the admin.

[Trudy Claspill]

Are you able to edit the Account field directly in the subtasks when they are in the Done status?

On the For Sub-tasks step do you have this box checked or unchecked?

[Terry Booth]

I am able to edit the Account field once the item is set to Done. The box in question is unchecked

[Trudy Claspill]

Hm, this is a puzzler.

Can you show the details for the Edit Issue step in your automation rule?

When you go to the list for selecting fields to edit do you find more than one field named Account?

[Terry Booth]

There is one other, but has no bearing or information: 

[Trudy Claspill]

Can you show the details for what you selected for setting the field in the Edit step? Did you choose Copy from Trigger Issue or Copy from Parent Issue? Try the other one (Trigger or Parent) to see if that makes a difference.

It shouldn't make a difference. I tried both and the worked.

Can you confirm these are issues in a Company Managed project?

Are you using the built in Sub-task issue type, or did you create a custom issue type within the Sub-task type?

What type of field is Account?

[Terry Booth]

I was using Copy from Trigger Issue. Changed it to Copy from Parent Issue and saw no change. This is a company managed project. I do not know what type of field Account is or if the Sub-Task field is a custom field.

[Bill Sheboy]

Hi @Terry Booth 

Would you please show the details section of your rule, showing the rule actor?

You noted that you were the rule actor, and to clarify do you mean: the rule is set to your user id for the actor, or that you triggered the rule and the actor is the default Jira Automation one?

To Trudy's earlier suggestion, this error can also occur due to a field mismatch.  Have you checked if you have multiple, different fields with the same name in the instance?

Kind regards,
Bill

[Trudy Claspill]

For the type of the Account field:

- do you type in text or do you get a list of values to select from?

- if it is a list for selection, can you select more than one value?

[Terry Booth]

Single value selection derived from Tempo Accounts 

[Trudy Claspill]

I have installed Tempo Timesheets on my own system, set up a couple of Accounts, and created the same automation rule. I am not encountering any errors and the Account information is being copied to the subtasks correctly.

Would you please try creating a new rule from scratch with the same steps, disabling or deleting the first version of the rule that you have been working on?

If the brand new, made from scratch, rule still doesn't work properly please provide screen images that show the Rule Details page, the details of each step, and the Audit Log details for the rule execution.

[Terry Booth]

I rebuilt the automation and it appears to be working. thank you for your help!

[Trudy Claspill]

Wonderful! So the solution in this case was "recreate the rule from scratch" and then the rule worked.

But we don't know why that was needed. {shrug}

Please consider marking the Answer thread as Accepted, if you consider your issue solved, to help other users find posts with validated solutions.

[Bill Sheboy]

Hi!

In my experience, sometimes rules get "glitched" by the editor after too many changes...implying there is something that was not cleaned up during a change/save/publish cycle.  I have seen this with basic rules and more complicated ones.  And so when things just do not make sense why a rule does not work, I try the re-create from scratch in my test project to help fault-isolation.

Kind regards,
Bill

[Terry Booth]

Trudy / Bill - it seems that this is the likely cause; too many edits as starting from scratch fixed my original problem. Thanks for your help.