What is the different between script runner's event:
Issue Updated/CustomFieldUpdatedEvent ?
Because I write a custom listener script to judge the customfield's value,when the condition is true then auto clone the issue to other projects.
I set the event: Issue Updated/CustomFieldUpdatedEvent.
I find a bug that when the custom field condition is true, it auto clone the issue(it is correct),but users upload the attachment three times,it also auto clone issue to other projects(it is wrong).
Is it jira's bug?We use JIRA 7.2.6 version.
Should I just need to remove Issue Updated to avoid this problem.
Thanks for your great support in advance.
Please note that these are not "script runner events". The events are fired by activity in Jira, and you're using Script Runner to react to them.
From "We only want to auto clone issue when the custom field condition", I think you need to forget CustomFieldUpdatedEvent.
It sounds like your requirement is "Clone issue if a custom field changes to <a value>". You will need the IssueUpdated event for that, and to then check the value of the custom field as the condition.
If my guesses there are wrong, could you clarify the requirement a bit more?
The questions is that I have already set the custom field to meet some condition and then to auto clone the issues,but when users update the attachment it also meet the condition then auto clone the issue,but this issues should not auto clone.
What should I need to avoid this problem?
So are you wanting the issue to only be cloned when a certain field is updated in an issue? If so, but the clone is being made when some other field is being updated, then I'd agree with Nic in that your condition is probably wrong. If, however, the attachment field is actually the field that is supposed to trigger the event, then I imagine your issue is that you need to check for if a clone of the issue already exists; and not to make another one if it does.
Could we please take a peek at your listener config and condition to get a better idea of what might be happening in your code?
1.So are you wanting the issue to only be cloned when a certain field is updated in an issue?
2. If so, but the clone is being made when some other field is being updated, then I'd agree with Nic in that your condition is probably wrong.
No,Because I put IssueUpdated event and the field have already changed to my trigger condition and then happen issue updated then it is auto clone?Is it correct action?
This is correct. An issue updated event tells us the issue has changed, and how.
Your condition needs to look specifically at one field within that. SR can do that easily, but it sounds like you have not configured it correctly.
Please, tell us what you have configured for this. We can't really help you until you tell us that.
If you need to judge which custom field is the one that has been updated, you can use something like the ChangeHistoryManager to see exactly which field was the updated field.
def chm = ComponentAccessor.changeHistoryManager
def changeHistory = chm.getAllChangeItems(event.issue)
// check that the field changed was the specified custom field
if(changeHistory.field.last() == "Custom Field Name")
//Execute the rest of your listener code
That should allow you to control which field the listener fires on. But if you have an issue with a condition somewhere else in your listener, this won't be a solution. But try to implement that and test it out. Then let us know how it goes! :D
Best of Luck!
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Atlas Camp is our developer event which will take place in Barcelona, Spain from the 6th -7th of September . This is a great opportunity to meet other developers and get n...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs