move parent (living in another project) from one state to another

[Francisco Navarro]

Dear community,

I'm trying to create an automation for a project in jira that moves my "Project" issue based on the movement of epics that live in different projects, these epics are connected with the "parent" field to the main project.

I need the issue indicated in the parent to be moved to a particular state when the project epic goes to "in progress". I created the following but I don't know where I'm failing because my "project" issue doesn't move. Attached images.

[Bill Sheboy]

Hi @Francisco Navarro 

For an automation question, please also post an image of the audit log details showing the rule execution.  That will provide context to see which steps in the rule processed.

Also, what is the scope of your rule: single-project, multiple-project, or global?

You describe the issues are in different projects, and so the rule will likely need multiple-project scope.  Your Jira Site Admin will need to help make that change in the global automation area.

Kind regards,
Bill

[Francisco Navarro]

Also, what is the scope of your rule: single-project, multiple-project, or global?

I first tried from the project that "triggered" the action to move the parent project from a "not started" state to a "site candidate", but in the "transition" action the final state (site candidate) did not appear, so I set the automation for "multiple projects", and in this scenario the final state I needed did appear.

I attached the automation log, thanks!

[Bill Sheboy]

To confirm, is the rule now working as you expected?

[Trudy Claspill]

Hello @Francisco Navarro 

Looking at the Audit log it indicates the rule was triggered by issue CDNS-3211, and that issue did not match the first condition (issue type = Epic) so the rule stopped running. Is that correct functionality? Is CDNS-3211 indeed not an Epic type of issue?

What happens if you transition an issue that is an Epic and has a parent issue in a different project?

[Francisco Navarro]

Bill,

To confirm, is the rule now working as you expected?

No, the rule is not doing what I need.

Is it as you say Trudy, that the trigger is based on the movement of an "epic" type issue in a project and the final action is to move an issue in another project of type "Project"???.

In any case, it seems strange to me, since I have another automation that makes the epic go to "in progress" when any of its subtasks go from backlog to "in progress".

[Trudy Claspill]

Please review the questions I asked in my response.

The log says that CDNS-3211 failed the check to confirm it is an Epic. Is it an Epic?

What are the project Types of the projects that contain the Epics? Get the project Type information by looking at the View All PR jects page under the Projects menu. On that page find each project that contains the Epics that might be children of the "project" issue type. For those Projects what is shown in the Type column on the View All Projects page? Are any of the Team Managed projects? Is CDNS a Team Managed project?

[Francisco Navarro]

@Trudy Claspill 

You're right, it's not an epic you're seeing there, it's a subtask.

But it's because I have another automation that makes it so that when a subtask goes to "in progress", any of them, it moves the parent epic to "in progress".

This is done without problems, but I want that when that epic that was moved to in progress, it triggers another action towards the issue contained in the "parent" (The issue named "Project" that is in another project) and moves it from its "Not started" state to "Site candidate".

[Trudy Claspill]

For this rule look at the Rule Details page.

At the bottom of that page is a check box that says something like Check this bos to allow this rule to be triggered by the actions of other rules. That box needs to be checked.

By default rule triggers are activated only when the trigger action has been executed directly by a user. In this case it is another rule that is transitioning the Epic issue.

[Francisco Navarro]

@Trudy Claspill 

That option you mention is already checked.

I really don't know where this could be failing, logically the conditions are fine but it doesn't do what I need. I tested "manually" moving the epic from the backlog to "in progress" but the automation didn't activate either.

I'm asking you. How would you do it? If you have a "parent" project that looks at several projects from different teams and you need it to move from one state to another as I need it.

[Trudy Claspill]

Thank you for that additional information.

What is shown on the Rule Details for the Scope of the rule?

You said:

 I tested "manually" moving the epic from the backlog to "in progress" but the automation didn't activate either.

Was the Project that contained that Epic within the Project Scope of the rule?

What information was added to the rule Audit Log when you manually moved the Epic in that case? Was the rule not triggered? Or was the rule actually triggered? If the rule was triggered then what messages are in the Audit Log for that run of the rule?

What are the project Types of the projects that contain the Epics?

• Get the project Type information by looking at the View All PR jects page under the Projects menu. On that page find each project that contains the Epics that might be children of the "project" issue type.

For those Projects what is shown in the Type column on the View All Projects page? Are any of the Team Managed projects? Is CDNS a Team Managed project?

If the Epics might be in Team Managed projects then you will have to use a different type of Condition to check if the rule was triggered by an Epic issue. You'll have to use this:

[Jack lee]

Based on your description, "Project" issue when an Epic in another project transitions to the "In Progress" state. The automation you’ve created likely needs a few tweaks.

Here are a few things to check:

1. Trigger Configuration: Ensure that the trigger is set correctly. It should be based on the Epic issue type transitioning, not the "Project" issue. For example, the trigger could be set as "Issue transitioned" and filter it specifically for the Epic issue type moving to "In Progress."

2. Condition for the Parent Link: Make sure you're using the correct JQL (Jira Query Language) to check the parent link, such as parent = <Epic Key> or something similar. You might need to reference the parent field properly to ensure the correct project issue is selected.

3. Action Configuration: Double-check the action that moves the "Project" issue. Ensure that it’s set to update the status of the linked issue and not just the Epic.

4. Permissions: Make sure the automation has the necessary permissions to move the issue within the relevant projects.

If everything is set up correctly and it’s still not working, you can also check the audit log for errors that might provide further insight into where it’s failing.

[Trudy Claspill]

@Jack lee 

Welcome to the Atlassian community.

1. The Issue Transitioned trigger allows you to specify only the starting and destination status. You cannot specify within the trigger the type of issues to which you want the trigger to apply. You have to add a Condition after the trigger to check the Issue Type of the trigger issue.

2. There is no need for a Condition to check the Parent link. The For Parent step determines if the Parent field of the trigger issue has any data. The Issue Type Hierarchy determines what type of issue can be the parent of another issue. If the hierarchy is configured to allow only "Project" issue types to be parent of an "Epic" issue, then this branch will execute only when the trigger issue (an Epic, per the previous condition) has a parent and that parent will be a "Project" issue.

3. Given that the Action to transition the issue is nested within the For Parent branch, that action will be applied to the Parent of the trigger issue - the parent "Project" of the "Epic".  Additionally that action has no direct configuration option for specifying the type of issue to which it should apply.

[Jeffrey_Denton]

Is the automation rule global, for both projects?

[Francisco Navarro]

No, I had to add it to the parent project because the destination state I needed to move to did not appear. Initially, the automation was built locally, but since the destination state information was not provided, I added the project.

[Jeffrey_Denton]

For this to work it has to be a global automation.  Please check to make sure its a global operation as I believe you are using this between two projects and it would have to be global to work. 

[Jeffrey_Denton]

Here is my automation for moving Epic (parent) based on Child Status.  My epic only transitions if all child tasks are in that status.  I have a automation per transition.  The first transition moves the epic, but every transition after that is based on if all children have the same transitioned status.  

[Francisco Navarro]

Thanks!

But I don't know if it will help me, since it is global, it can affect other projects that have the same issue structure, which is not what I need.

When I select more than one project, it becomes "global" but indicating which projects my automation affects, I feel that the problem is from the parent project that does not have the others directly loaded as "children" created in this project, they are connected only by the "parent" field.

[Trudy Claspill]

@Francisco Navarro 

Please review the last reply I added within Bill Sheboy's response thread, and let me know if that assists you

https://community.atlassian.com/t5/Jira-questions/Re-Re-move-parent-living-in-another-project-from-one/qaq-p/2920078/comment-id/1082209#M1082209

[Francisco Navarro]

Ok, I'll try it @Trudy Claspill