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 have a bit of an issue with deleting issues in a listener that I have been debugging. I believe there is some kind recursion going on in the function below.
To outline I have a listener that listens for when link created and then updates a field on one of the issues where the link is (depending on the outward and inward wording of the link). This works perfectly until I come to delete the issue. When deleting an issue it seems to fire the link deletion event first and then of course it tries to update an issue which jira is deleting which is where I assume it gets stuck. This then breaks the db and the issue is stuck for ever. Is there a way I can stop the issue from being updated when it is currently being deleted and how can I tell when this is happening?
Many thanks for any help given in advance.
Never delete an issue, cancel it or close it or something else. It is a bad practice. Reconsider your workflow!
You could use an if else block to make sure that the update code is not executed when a deleted link event is detected.
That was my first thought however after looking into the deletion logic I can see that there is a certain 'flow' that happens when deleting an issue which is why my first crack i.e trying to catch the ISSUE_DELETE_ID event didn't work. From this post https://community.atlassian.com/t5/Answers-Developer-Questions/How-to-retrieve-issue-links-in-delete-issue-event-listener/qaq-p/477337 it seems that the removal of links and therefore the event for the removal of links is called before the actual ISSUE_DELETE event:
- save issue(just like "table row") self, customFieldValues and watchers in event data object
- removeWorklogs (it meant, what you not get not only link, but worklogs too)
- remove sub-tasks
- remove links (!!!!!)
- remove history
- dispatch Event (with event data object from first point)
If anyone comes across this issue in the future this is eventually how I have solved it. I have taken it that having a script that looks for an issue delete event cannot try to update the issue on this event without it looking when you finally try and delete the issue. for this reason purely so you don't lock the JIRA DB and cause issues I have given the update command a 5 second time out and used java concurrent to handle the deletion in a different thread that I eventually cut if it times out. Is this a nice solution that I'm suggesting? Probably not. But in the absence of other ways of achieving this I have gone with this option. I would appreciate if anyone can tell me if this is a complete no go area and I will remove. But this is all I have found. I don't attach the code for this reason.
Hi, echoing the previous comment it's generally bad practise to delete issues.
If however you need to delete them you can add a clause in you listener. I am assuming you are using Scriptrunner so unless I am missing something you can remove the issue link deleted from the list of events that trigger it.
Alternatively something like if (!linkedIssue) return will also unblock your script.
Ok, this is where I must have missed something I'm aware that some events helpfully come for free with others, as seen above, I'm just wondering as this must be an issue people come across that the events are fired in the 'wrong' order for the implementation I have. I almost want to be able to just cut off the script if it takes too long...
The problematic line is:
cfAutoLinkField.updateValue(null, sourceIssue, new ModifiedValue(sourceIssue.getCustomFieldValue(cfAutoLinkField), null), changeHolder)
Which is trying to update the field when the deletion logic is trying to delete it which I assume causes an internal error.
Many thanks for the help,