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.
Join now to unlock these features and more
I have a global automation set up. I run it as an admin user. The two projects share the same permission scheme and the admin user has administrative rights. The issue links delete just fine in one project but not the other. The automation log doesn't even show the issue link deletion to have been attempted in the project where it fails. I have attempted to move the delete issue link to various places in the automation but I shouldn't have to since the automation works just fine in one of the projects. I am running Jira Data Center. Has anyone seen this odd behavior? Shown are the automation, the results from the project where it doesn't work and the project where it does work.
The absence in the first audit log of entries about deleting links suggests that the issue that triggered the rule did not have any links of the specified type.
Can you create another scenario that you would expect to fail in the same way? And show us an image of the trigger issue before the rule is run, including the Linked Issues section?
The issue had two links, one that got created the first time and one that got created the second time. The first link did not get deleted prior to the second link being created as it should have. So, this does not suggest that there were no links but rather, something isn't working correctly. The scenario always fails in the one project but is always successful in a second project, both sharing the same permission scheme and both owned by the same administrator with full admin rights. I can run the exact same automation in the exact same way. It fails for one but not the other.
You say that it fails in one project but not the second project.
I see in the first audit log that the trigger issue was in the TGW project. In what project(s) were the linked issues in that case?
Does it always fail when the trigger issues is in the TGW project, regardless of the projects in which the linked issues exist?
Does it matter what status the trigger issue is in? Do the projects use the same workflows? Where I'm going with those questions is wondering if there is a property set on the status that prevents the deletion of links. Is the actor of the Automation Rule able to manually delete the links in the case where the automation rule has not?
Both projects link to POP. TGW linked to POP always fails. FIT linked to POP always succeeds. I tried a manual trigger which also does not work for TGW. The projects do not use the same workflow but share the same permission scheme. I always trigger from an Epic using edit so there is no transition involved. The actor is the admin acct which owns all three of the projects and can delete links. I am an admin and can manually delete the links as well in all three of the projects. I tried running the automation as myself and that does not work either. I will investigate the differences between the two workflows to see if there is anything related to the status but given I am using Edit, I doubt the status has anything to do with it. Both are in the same status of "Open." Thank you
@Trudy Claspill I have created a manual automation as basic as possible to illustrate the issue (see below). Would turning on additional logging possibly shed some light on what the issue is? I have never used logging but did find this: https://confluence.atlassian.com/automation/enable-logging-for-jira-automation-1141480669.html
POP-3 "is parent of" FIT-6859, VOLOV-5252, TGW-1116 (outward link)
Each of the three tickets "is child of" POP-3 (inward link). One of the three issue links (FIT) is recognized, the other two are not.
I'm afraid I am at a loss here.
I work mostly with Automation in the Jira Cloud product. I know that Automation in the Jira self-hosted products has functional differences, but I don't have much experience with it directly.
I recommend that you contact Atlassian Support directly on this to see if they can offer additional debugging advice.
If you get a solution from them, it would be great if you post it here for the benefit of other community members.
I notice your rule is making two edits to the issue in the same rule. When doing this, please use the Re-fetch Issue action in-between them. That will reload the updated issue data before proceeding with the second edit.
Thanks, I already tried that. Still doesn't work. It's as though the Automation doesn't recognize the link existing in one project but does for the other project. I also tried changing the link type in the automation and that didn't work and I also tried manually creating the link and letting the automation delete it. That didn't work either.
Have you confirmed the link type is correct in your delete action? Issue links have "direction", such as "blocks" and "is blocked by", and so perhaps the type is incorrect.
Have you checked if there are any duplicate link types set up, with the same name? That might confuse the automation rule.
Next, as this is Jira Server, when was the last re-index performed?
The link type is correct for both the add and the delete - "is child of"
Keep in mind this automation works for one project and not the other so it's not a link type mismatch/dup situation. I will inquire about the last reindexing. We upgraded in May(ish) so that may be the last time. Thank you