"This ticket remains open as issue linked or delinked events are still not part of a notification scheme. Right now, we do not have any plans for adding these events to notifications schemes. We will let you know as soon as the status of this suggestion changes."

You can't be serious.  The whole point of Jira is to keep peope up to date on changes to issues and you don't have this tied into Notification events?   BTW, Project Automation feature now exists for this to be tied into as well.

This issue is nearly 2 DECADES old.   Time to get it together Atlassian.

Ok, good news for everyone. I requested feature with the JMWE guys, and they deliver it.

Now, JMWE since 8.4.0 can do event based action, based on IssueLinkCreatedEvent and IssueLinkDeletedEvent. 

Hurray hurray hurray. 

Greeting from the middle of 2023, just wanna to ask, did anyone found any usable solution? Because of strict network rules, I am not able use webhooks at all and need to react to new links / deleted links. 

Got JMWE and ScriptRunner in my hands, but still struggling with working solution. 

How's it that still in the consideration? Stop those Las Vegas parties and get back to work, please!

🤣

My boy started grade 1 this year

I've been selected twice for the International Biennale of Glass art

And we've had a pandemic 

In November this issue will officially be allowed to buy me a beer in an Australian pub (and yes, I'm going to print this ticket out and have it buy me a beer at the end of the year).

In which universe is this a suggestion and not a bug?

Is anyone looking into this issue, since 2005 many things changed, Atlassian must also bring this change in JIRA. :-/

how many vote do you need?

Jakub...what kind of workflow you guys working with over there?  Here's a 13 yr old common sense feature request with tons of votes that you finally get around to, and you only partially implement it and then close it...and then reopen it with a Future Consideration status and a comment that basically says "try waiting another 13 years". 

I had to open JRASERVER-65906 because you guys closed this.  I would think that you could either close that other one as a duplicate, or more better...close this one with a resolution of "Partially Fixed"  and we'll wait 13 years for JRASERVER-65906 to be addressed.

It is very missleading to reopen this ticket since it was released.

I have been looking for it in the Release notes for Jira 7.5.0 but because it is not resolved, it does not appear there. 

Thank you for your comments. I'm bringing this ticket. We do not have any immediate plans for adding events to notifications schemes, but I'll leave it open so we'll consider I while planning future improvements.

Cheers
Jakub Kurcek
Product Manager, JIRA Platform

Still not works. Especially for 'Epic Link'.

Can it be re-opened?

oles.hnatkevych88153195 I think that event listeners are called synchronously, therefore, you can get the user from the static JiraAuthenticationContext

From the event object I can take the link and event creation time instant, but how can I get the USER which performed the linking?

The reporter for this issue has probably long given up on it but it would be great if it could be re-opened as this is not the right attitude for delivering such a requested and awaited feature.

This issue is not resolved, still can not receive link status update via webhook.

Changes to Epic Link still don't seem to be triggering a "issue_updated", is there a separate issue for that somewhere?

(this)

Atlassian, you may have resolved this issue in the most technical sense (creating the events), but the other issues that were closed as duplicates really tell the story of what us as customers want.  We want an exposed event that can be used in notification schemes.  On JRASERVER-14618 Dave Meyer states "We would not implement one without the other.".  That turned out to be incorrect.  You've closed all these issues with 100's of votes and watchers and comments so that we have to start from scratch and create a new issue asking for the same thing all over again.   I've gone and done just that JRASERVER-65906.

@David Sumlin

Nop, only if you write plugin for this. This is the same situation for remote issue links in earlier jira version.
That why i wrote plugin with new custom events.

Looking at that notice, I'm wondering if those events will be able to be used in notification schemes natively.

This is coming out natively in JIRA 7.5! https://developer.atlassian.com/jiradev/latest-updates/preparing-for-jira-7-5

Hello my friends,

I'm really excited to present to you my new plugin Issue Linked Event

Best regards

As a developer or tester I would use this to get notifications when I resolve and link something as a defect of something else, and that something else changed state (like, it was fixed) so I could verify the fix covered the additional defect report.

It seems like a remarkable oversight that if I am the filer or watcher of a bug, and that bug is marked as a duplicate of another via linking, that I wouldn't get a notification about that link activity.

Can someone give an update as to whether this is being dealt with by a dev team or not? It really is a fundamental oversight

I'd expect webhooks to use the common event dispatching mechanism inside JIRA as the source of the events, so I'm quite sure that server code is already there. It's just a question of when the guys at Atlassian get to migrate and release that on the server product.

I think the winky face implies extreme sarcasm. 

Don't worry now when it's available in Cloud it should naturally come to server in a near future

The plug-in architectures, and hence the mechanisms used to implement this, are entirely different for Server and Cloud, so your confidence is misplaced.

That said, unless I'm missing something, the change required to Server seems trivial, so I don't understand why it's taking so long.

Please please please please, there's so many edge-cases that are introduced by not having this event. I need to listen for issue linking to properly handle certain automations or scripts.

@Niclas - I used to think the same until JRASERVER-45690. It appears the codelines for cloud and core are completely separate at this point and there's no guarantee that features delivered in cloud will ever be delivered in the server edition.

Don't worry now when it's available in Cloud it should naturally come to server in a near future

"Never attribute to malice that which is adequately explained by stupidity"

There must be a strategic reason that Atlassian is choosing to not tackle this.  It appears that it wouldn't be difficult at all to implement.

It's great that Atlassian is happy to ignore 527 votes for an issue that probably requires 3 lines of code to resolve. A+ customer support! Keep up the good... work? Please keep developing new features while you completely ignore the basics.

Unfortunately, the workarounds are not applicable on JIRA Cloud. Webhooks for link updates are not fired because of this issue, which makes links-based automation impossible on a Cloud instance.

It is ... (hilarious)
All kudos for Michael Viktorov (who provided the solution in this comment thread)

Francis

Thanks Niclas,

I kind of can't believe that the fix for this is – find 
issueUpdateBean.setDispatchEvent(false);
change it to 
issueUpdateBean.setDispatchEvent(true);
hilarious

As mentioned before if your on JIRA server there is a work-around. Yes it's not the perfect solution but it works and our use case was to provide customer webhooks with important issue link changes for real-time planning.

http://tools-for-agile-teams.blogspot.se/2016/02/how-to-get-link-event-notifications-in.html

Thanks to the people providing this vital information and doing to hard work!

That reminds me of JRA-1369

Cheers Dave,

Didn't mean anything by it - just having a poke at you guys

Thanks for the response

Hi mail37,

Thanks for the peek into your life and for being a customer for so many years.

Time to face the cold, hard, big boy reality that it's just not going to get done.

The cold, hard reality is that we do our best to provide open communication of issues. Jira.atlassian.com is a frustrating place – it's great for tracking all the things we haven't done and not great for the things we have done. As a rule, we don't close issues just because they are old. And just because an issue is old doesn't mean we're not going to work on it. But there's no correlation. The reality is just that there are 100 times for feature requests and improvements than we have time to work on, so most issues are not being worked on most of the time.

Our "attitude" is that open communication of our successes and failures is important. I'll be the first to admit that there are probably some (or many) feature requests here that will never get done. Hopefully not because everyone is underwater...

Rest assured that we hear your feedback and will continue working hard to build the best product we can. Traveling to every art gallery in Europe is extremely impressive! I would love to hear about it if you come join us at Atlassian Summit 2017 in September

Regards,
Dave Meyer
JIRA Product Management

Congrats for all your achievements in the past 11 years

Thanks Alina (thought I commented in 2013, so technically that's just the last 4 years ... maybe I shouldn't be so harsh on ol' atlassian)

Congratulations on graduating, I hope you're enjoying software engineering.

All the best
Adam

Hi, Adam

The amount ot 10+ years old issues lying around this site makes me feel better about my own response time for...everything ever. Thanks for the laugh, good to know there are people who share my frustration with this kind of attitude from Atlassian.  I wasn't even in highschool when people first faced this issue. Here I am, with a degree and a job under my belt and still no answer. Where is the progress, people?

Congrats for all your achievements in the past 11 years and hope you have many more.

Don't forget to tip your wait staff

Hi Adam,

I knew it was a good idea to vote for this ticket and keep reading the comments. You absolutely made my day! Thank you so much for making me laugh. I will share this with the colleagues. We will never get the feature, but at the very least we now got a good laugh!

Thank you!
Stefan

ok...since I last commented on this issue I have

Finished the project I was on
Finished that entire contract I was on
Moved cities
Gone to art school
Travelled to Europe and Morocco for 3 months
Started another contract
Started another project
Had a baby
Finished that new project
Travelled to every gallery in Europe
Moved house
Started a new project (again)

This issue was raised in 2005

Don't bother +1ing it, it's NEVER going to be worked on. People have been born, grown up and graduated primary school in the time this issue has sat on the bench.

Someone could have gotten a PhD in software engineering and fixed the issue themselves in the time this issue has sat on the bench. They would have had 4 years left over.

By the time someone actually looks at this issue we'll all be underwater from global warming and JIRA will be the last of our concerns.

By the time someone actually looks at this issue we'll be colonising some distant habitable zone.

For god sake atlassian - if you're not going not do it then delete the issue, or close it or something.

"oh, we might get to it someday"....NO, YOU WON'T....IT'S BEEN 11 YEARS! Time to face the cold, hard, big boy reality that it's just not going to get done.

Hi

+1, we really need this for our add-on Exocet !

Would be great if events could be also fired when

• a sub-task is created
• an issue is added to an Epic 
• an issue is linked to a remote issue

Thanks

Christophe

Chuck don't need this functionality but we do!  

+1 This would help with some automation rules that were requested by customers

It's such a shame that you are not able to fix this bug for over 11 years 

+1 It's sort of galling that there are RemoteLink events, but not events for actual links.

+1 We too would like this functionality (notification on issue linked) at Percona. Thank you!!!!!!!

+1 from here too. It is just not logical that all other modifications to issues launch an event while adding/removing/changing an epic for an issue cannot be detected in any way.

Our use case: We want certain field value to be in sync from Epic level to all issues that are under it. When an issues is added to the Epic it should inherit this value. My solution would be to add a custom script listener to listen to all issue update events, then do the needed field value sync. I was quite surprised to learn that Epic link modification does not launch any events.

+1 for our instance of JIRA. We didn't realize this wasn't happening until today. Would be a very useful feature for us.

Atlassian Update – 4 January 2016: "We are planning to work on events and webhooks later this year".

Today is 9 January 2017. 2016 is over. Issue is still in status Open, which is the first status in workflow. There is no assignee yet. When you are going to start work on this?