Is there a way (Addons?) to prevent Epic Links from being cross-project?

[FK]

Hello all,

My organization has the issue described here (this is from 2014!): https://jira.atlassian.com/browse/JSWCLOUD-10696

Now it seems like there is no obvious out of the box solution to this issue but does anyone maybe know a way to do this via addons or some other workaround?

We currently have the problem that we use identical Epic Names in various projects. So it is a nuisance when people are entering or editing tickets, they always see ALL Epic Links, not just the one for the selected project

Thank you,

-FK

[Bill Sheboy · Accepted solution]

Hi @FK 

As you noted, this checking/prevention is not a feature in Jira yet.

One work-around would be to use an automation rule which checks when an epic is assigned, and notifies the person doing the edit if the epic is not in the same project.  This would not block the edit but it would make it more visible for correction.

For example:

• trigger: issue updated
• advanced compare condition: use change log to check if the epic link was assigned
• branch: on the epic link
  • advanced compare condition: if the epic's project is different from the trigger issue's project
  • action: notify the person {{initiator}} by email, comment/mention, Slack, etc.

Kind regards,
Bill

[FK]

Hello Bill,

Thank you for your idea!

Could you please elaborate on the second step? I fail to understand how I can use the changelog to check if the Epic was assigned via Advanced Compare Condition.

I am not sure how to express that here

Best,
FK

[Bill Sheboy]

Oops...updating for my prior errors.  Sorry about that!

One more time...please try two advanced compare conditions, one after the other.

The first checks if the epic link field changed

• first value: {{#changelog.epic link}}{{fromString}}{{/}}
• condition: does not equal
• second value: {{#changelog.epic link}}{{toString}}{{/}}

The second checks if the epic link field has a value

• first value: {{issue.epic link}}
• condition: does not equal
• second value: leave this as "Empty"

[FK]

Thank you Bill!

I played around with your instructions and almost got it to work (I was not able to fully figure out how to compare the parents Project name with the current issues Project name after branching onto the Epic Link - step 3 from your previous message.

But regardless your information allowed me to end up with this here which does what it needs to do:

I changed the Trigger to "Created" because we do not have Jira Premium and therefore only 500 cross-project automation executions per month. Running a rule each time an issue is updated would eat that up in 2 days :)

Thank you again for your ideas and help!

Fingers crossed that Atlassian still gives us the option to toggle that Epics from other Projects cannot be selected.

-FK

[FK]

@Bill Sheboy now I encountered another issue, maybe you can still find a minute to help me?

What I posted above works perfectly for all our use cases except one: We have one project with no epics. Which means whenever a ticket is created in that project, the rule I pasted above will always fire a mail.

Could you help me finding a way to exclude that one project from this otherwise global rule?

-FK

[Bill Sheboy]

First thing: when a rule triggers it counts as an "execution" for usage counts.  So the create trigger will count each time.

Next, to prevent issues without epics from sending an email, please add another condition to test if the created issue has an epic immediately after the trigger.  The other way to do this is to change the rule's detail settings and select specific projects...excluding the ones without epics.  (That seems like a "brittle" solution to me as it requires you to remember and maintain the setting.)

[Fabian Lim]

Hi @FK

It's a great idea.  Hopefully you will get enough votes. 

Regards

[FK]

Thanks @[deleted]

There are so many addons out there, I am a bit surprised that we cannot find one for this purpose.

That is why we hoped that there is one and we maybe just do not see it. After all I would not expect much support from Atlassian here (looking at the creation date of the ticket I linked in the original post).

-FK