nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

automatic rule for sub-task to inherit a custom date field from its parent

Martina Hurtečáková

Hello,

I´m new in automatic rules in Jira cloud and I tried to google for solution to my problem but haven´t found it.

We want the sub-tasks to inherit a custom field "Deployment Prod" (it´s a date field). this field can be filled in in the parent at any time (no status or transition specified).

I tried several ways but none of them is working. please see attached my 3 attempts and assist me on setting it up. thanks a lot, Martina

Accepted answers

All comments

Tessa Tuteleers

Hey @Martina Hurtečáková ,

In all cases, your condition speaks of the parent issue. You assume that you would start the rule from the subtask itself. But the trigger here would be the parent, not the subtasks (as the change in the field happens on the parent.

Meaning -> If you change the duedate of the parent issue, start the rule with the parent and and then copy that date to all subtasks.

Your condition should be on the issue itself, not its parent.

It looks like your first screenshot is the closest attempt

When the field of an issue is changed -> correct
Check if the issue is the right issuetype -> not correct: unteraufgabe is the subtask I'm assuming? You are going to trigger this rule and allow it when you change a duedate on a subtasks, and then copy that field to its subtasks (which do not exist)
Check if the field is not empty -> not correct: this needs to be on the issue itself, not the parent
For subtasks: copy date field from issue -> I don't know how you configured that one, please provide a screenshot if the above does not work.

Hope this helps!

- Tessa

Bill Sheboy

Hi @Martina Hurtečáková

How accurately do you need the field in the subtasks to be, regarding a match to the parent issue?

That will determine how many automation rules you need, and which triggers they use. For example, you could have at least this many rules:

when a subtask is created, copy the field from the parent issue
when a subtask is edited to manually alter the field, set the value back to the parent's value
when a subtask changes its parent, copy the field from the new parent issue
when a parent issue changes the field, update the value in any subtasks
when a subtask is converted to another issue type, what should happen to the field value?
etc.

Kind regards,
Bill

Martina Hurtečáková

Hello,

sorry to come later to you.

Do I understand you correctly that instead of 1 rule I need so many?

I reviewed those provided by you and we need the first 4 rules (1.-4.). But I realized it should not be for field Due date but for a custom field called "Deployment Prod" (Type: date time picker). Could you please support me on the steps for creation of the rules?

thanks a lot

Martina Hurtečáková

Hello @Piet Pieters ,

thank you for trying to help me but I wasn´t successful in solution.

first of all I need the rule(s) to be created for another custom field called "Deployment Prod" (Type: Date time picker). and I changed the rule as follows:

Aufgabe= Task.

and Audit log shows success. however in the tickets it´s not performed.

Task is 8245
Sub-Task is 8246

I will be grateful for any kind of support, how the rule needs to be set up, to ensure that the "Deployment Prod" field in every sub-task is filled in based on its parent issue (Epic, Task, or Story), doesn´t matter if by creation or edition.

Thank you, Martina

Bill Sheboy

First, please stay engaged with the help @Piet Pieters is providing so you get one rule working correctly.

Then, after you have decided the scenarios needed, you can copy that rule and adjust the triggers / conditions, as needed. For example with the Issue Created scenario...

trigger: issue created
action: re-fetch issue
...previously identified conditions and actions to update your field