You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I can not understand why the rule does not return when the specified conditions are met? If I need the rule to select only epics from the project specified in the rule settings? Can you suggest what needs to be changed?
The rule configuration for "Projects" (which you highlighted) determines the general context for the rule, not an absolute scope for all issues processed.
I see that you're branching on "Linked Issues", and I could imagine that issues in the configured project might link to issues outside that project.
The trigger for this rule will fire only for transitioning issues in the one project configured for the rule. So you can be assured that the issue that triggered this rule is in that project.
But your rule logic (the branch) follows any "relates to" links that may be on that triggering issue, and those "related issues" might be in other projects. That's a feature of automation, not a bug. :-)
If you only want to look at related issues in the same project, just add a conditional early in your branch to confirm that the current issue is in the desired project.
Sorry, I don't understand you
I have two projects "Test1" and "Test2". I want to create a rule that should apply only to the tasks of the "Test2" project. This rule should be triggered when there is a status change in the epic. On startup, it should check the conditions:
- if this task has an associated task with type "Epik" and whether it was created in the "Test1" project.
If "Yes" - change the status in the found task to a similar one.
How can I set up a rule in this case?
OK, let's take it step by step. First, let's confirm that this rule is triggering properly as you expect.
Add a Log Action step in your rule, where shown below by the arrow:
Configure that new Log Action component to look like this:
When you run your rule (by transitioning an Epic), you should see a message in the Audit Log for that rule which confirms the issue that the rule is starting with:
In your case, the type should show as "Epic".
Also try transitioning an Epic in a different project, or a Task/Story in both projects, to verify that you do NOT see the Log Action in those cases.
Start with that, and let's confirm that your rule is working correctly to that point.
Hi @Виталий ,
what @Mykenna Cepek wanted to explain is that the scope of an automation rule limits its "area of operation". It also limits where linked issues will be searched (in this case it´s a single project scope rule and therefore will only look for linked issues in the selected project and furthermore will not execute any actions in any other projects). Please check the audit log of an execution of your rule (I tried to reproduce this use case on my site): your log should tell something similar to the following:
--> JT in my case is the scope (project) i selected for the automation rule.
@Mykenna Cepek could you please confirm (just to be sure I´m not bringing more confusion than help into the conversation)
@Виталий Please let us know if there is anything unclear and feel free to ask.
@Stefan Salzl is correct. If the "Rule Details > Scope" is set to a single project, then a branch operation like "Branch > Linked issues" will only find issues in that one project. The "Branch" component configuration actually provides a reminder about this.
So you will have to use a "Rule Details > Scope" of either "Multiple Projects" or "Global" for your rule in order to find linked issues outside of the one source project.
Unfortunately, this also means that your rule will execute for every transitioned issue in all those projects. That will only be a problem if your Jira plan has a limitation on the number of rule executions.
Also, I think you will want to include an extra condition right after the trigger, to terminate the rule if the triggering issue isn't in the source project.
So, fix your rule Scope to include ALL the projects with issues of interest, and change the first part of your rule to look something like this: