Update custom field of bug based on Epic status

[dimofeev]

Hi there,

I would like to achieve the following automation:

1. Create read-only field for Bug and Story called 'Phase'.

2. When the Parent field of any Bug or Story is updated (for example create Bug or Story in Epic) get the status of the Epic and set it for the 'Phase' field.

My end goal is: We have different statuses for the Epic - Development, Alpha, Beta, etc. and we would like to track how many bugs / stories are discovered during different Epic statuses.

Thank you in advance for your help.

[Bill Sheboy]

Hi @dimofeev -- Welcome to the Atlassian Community!

What have you tried thus far to solve this need?

If you have a rule and it is not working as expected, note context is important for the community to help.  Please post the following:

• what version of Jira are you using: Cloud, Server, or Data Center
• for Cloud, what type of project is this (e.g., company-managed, team-managed, etc.)
• an image of your complete automation rule in a single image for continuity
• images of any relevant actions / conditions / branches
• an image of the audit log details showing the rule execution
• explain what is not working as expected and why you believe that to be the case.

If you have not tried creating the rule yet, I encourage you to do so.  Successfully using automation rules requires learning and experimentation.

To help you get started, the rule could be triggered on Issue Created, and then access the parent Epic's status to edit the Bug or Story's field.  Please look here to learn more: https://support.atlassian.com/cloud-automation/docs/jira-cloud-automation/

Kind regards,
Bill

[dimofeev]

Hey Bill,

Thanks for your prompt reply. We are using Cloud Jira Software.

What my final automation goal is the following:

1. I have Product Discovery Project with Ideas in it. These Ideas have standard status field (Parking Lot, Delivery, etc.)

2. For every Idea from that project I have one Epic attached. The epic is part from other project that is Company-managed software.

3. For every epic I have many stories (and potentially bugs).

Now, I want to create new custom text field that should be available for the Stories and Bugs. When a Bug/Story is created and related to the Epic, the custom field should be populated with the status of the Idea (i.e. not with the status of the Epic).

Do you think this is doable?  Thank you in advance for your help.

[Bill Sheboy]

While that is possible with an automation rule, it seems problematic for several reasons:

First, it is going from the lowest issue item --> upwards to gather and display the Idea status, which seems the opposite of what many would use to assess progress.  What problem are you trying to solve by showing the Idea status in those issues used to implement it?

Next, although the Idea status is likely changing less often than the Stories, when it does it could potentially update many items.  That will create a very slow rule, and potentially one that cannot finish if there are more than 100 issues involved (due to rule limitations).

I recommend pausing to meet with your Jira Site Admin, explain the problem you are trying to solve (that is, "why do this?"), and collaborating on possible solutions.

[dimofeev]

Thanks, Bill,

I would like to know how many bugs/stories are logged during the different Idea statuses (not done, discovery, development, alpha, beta, etc.). That way we can see how effective we are during the different release cycles of given feature.

The idea is to create one custom field, let's say 'Phase' add it to Bugs/Stories and fill it only once (i.e. no subsequent updates of this field) with the status of the Idea.

So finally it will looks like.

1. I have Idea and log it in the Jira Product Discovery project. It has some status (let's say 'Discovery').

2. New Epics (deliverables) are created and linked to this Idea.(Epics available under Delivery section of the Idea and resides in Company managed Jira project).

3. Now when I create new Bug or Story and it is linked to some of these epics, a custom field available for Bugs and Stories should be populated with the status of the Idea. This field should be populated only once and no subsequent updates of it. If you change the status of the Idea (or Epic) - this custom field should not be updated.

[Bill Sheboy]

Thanks for the additional details.  Unfortunately, JQL does not have many of the features of a SQL...as those would enable joins and dynamic counting without adding any custom fields.  Such reporting might be possible with marketplace addons / apps or exporting issues with their histories to a reporting database.

Regardless of that...

Do you need these counts regardless of the specific Idea, or do you also need to report based on the specific Idea?

Assuming it is the first one, there are still many scenarios to consider.  Let's examine the most basic one:

GIVEN an Idea exists in JPD
AND the Idea has an Epic linked using "Delivery Tickets"
WHEN a Work Item (recently renamed from "Issue") is created with an assigned parent Epic
THEN update the Work Item's "idea phase" custom field to the current status of the Idea related to the parent Epic

That could be implemented with a multiple-project or global scope automation rule, using the various link types to find the correct Idea. 

Unfortunately, there is no data cardinality enforced with JPD links, and so a single Epic could be a "delivery ticket" for multiple Ideas!  If you assume that does not happen, the rule should be relatively straightforward to implement.

What about the other scenarios?

1. when an existing Work Item is updated to assign it to a parent Epic for the first time, and the Epic implements a JPD Idea...??? what should go in the "idea phase"?
2. when an existing Epic with child Work Items is linked to a JPD Idea...??? what should happen?
3. etc.

The challenge with other scenarios is accessing the issue histories of both the Work Item and the Idea, and so those may not be easily possible with automation rules.

[dimofeev]

Thanks, Bill.

I really appreciate your help.

Do you need these counts regardless of the specific Idea, or do you also need to report based on the specific Idea? - I need these counts regardless of the specific idea.

That could be implemented with a multiple-project or global scope automation rule, using the various link types to find the correct Idea. - well, I tried the very basic automation, but seems it is not working for JDP project. Here is what I tries:

1. Created new Jira Global field - IdeaPhase.

2. Tried to set this field to 'Updated' when new Idea is created. This was not working. When I did the same for Company-Managed-Project - it was working. Do you know if there are any limitation in the terms of automation when the project is JDP ?

About your questions:

1. when an existing Work Item is updated to assign it to a parent Epic for the first time, and the Epic implements a JPD Idea...??? what should go in the "idea phase"? - well, the IdeaPhase field should be synced all the time with the Epic (when Idea status is changed, the Epic 'IdeaPhase' should also be changed. Whenever you create new work item (let's say Bug - it should inherit the Epic 'IdeaStatus'.

2. when an existing Epic with child Work Items is linked to a JPD Idea...??? what should happen? - again, I guess in this case the Epic 'IdeaStatus' should automatically inherit the Idea Status.

Well, I do not know if my solution is the best one, but the problem I would like to solve is the following.

"What is the effectiveness in the terms of found stories (i.e. enhancements) or bugs during the different release cycles of an Idea (given different kind of people are performing testing - i.e. internal colleagues (alpha testing), potential customers, end users, etc. So, I'll be more than happy to hear your opinion on the topic and if there are better solutions for my problem.

Once again, thank you for your great help.

[Bill Sheboy]

Thanks for that additional context.  Let's start with:

• A rule can be built for the basic case I noted above, and
• Based on what you describe, the other cases cannot be easily automated.  The reasons are the Idea's history cannot be easily searched from a rule to find its status at a specific point in time in the past.

So staying with the basic case, the rule will need global scope to access all of the issues involved.  The scope could explain why your non-JPD issues are not updating.  (Your Jira Site Admin will need to help change the rule scope.)

If you post an image of your rule and the audit log details, that will confirm that hypothesis.

What is your Jira license level: Free, Standard, Premium, or Enterprise?  Unless you have at least Standard level, I would not recommend implementing this rule, as it will use up your monthly automation service limit, halting all other rule usage.