Set assignee from component lead using script listener

[Alvin]

Hello Community, I need help on scriptrunner, I need to set assignee based on the component's lead. Below is the code that I'm using

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.MutableIssue
import com.atlassian.jira.issue.customfields.option.LazyLoadedOption

// a map with select list option to Component
def componentsMap = [
"BOSS" : "Component1",
"Mashery" : "Component2",
]

def issue = event.issue as MutableIssue

def selectList = ComponentAccessor.customFieldManager.getCustomFieldObjectByName("Affected Service")
def selectListValue = issue.getCustomFieldValue(selectList) as LazyLoadedOption

// there is no value for the select list - therefore do nothing
if (! selectListValue) {
return
}

def componentManager = ComponentAccessor.projectComponentManager
def componentName = componentsMap.get(selectListValue.value)
def component = componentManager.findByComponentName(issue.projectObject.id, componentName)
def userManager = ComponentAccessor.userManager
def components = issue.componentObjects.toList()

if (component) {
componentManager.updateIssueProjectComponents(issue, [component])
}
issue.setAssignee(ComponentAccessor.userManager.getUserByKey(component.lead))

In this code, I have Affected Service as a single select list, if BOSS has been selected, the Component Field will update and set to Component1, but the assignee remains unassigned even if I have default assignee on my component. I know that there's something wrong with my code because I'm a beginner. I need to change assignee everytime component field is changed, that's why I used script listener. Thanks

[Joshua Yamdogo @ Adaptavist · Accepted solution]

Hi Andreas,

This depends on a number of considerations, but mainly:

• How much computation each listener does each time it is invoked
• How frequently events that trigger the listeners get fired 

With regards to the first point, you should be able to limit the amount of computation by writing conditions (depending on your use case). For example: your listener may get invoked 2000 times per day, but maybe you have some code within the listener to check to see if an issue had a particular field updated or if the issue contains a certain Assignee. With that, your listener may only need to do work on a fraction of the 2000 updated issue events.

In most cases, performance isn't a problem. We have users who have incredibly large instances who use listeners with no issue. Unless you're writing an incredibly complex and computationally-expensive listener, you aren't likely to have any problems.

That being said, you'll need to do your own load testing to see if it's performant or not. It's hard to give a definite answer as every situation is likely to be different depending on your use case. Maybe you could try in a staging environment before rolling out to production if you have one?

Regards,

Josh

[Andreas Lorz]

Hi Joshua Yamdogo @ Adaptavist ,

thanks a lot for your answer.

I read about this condition thing on your site. Is a condition a simple if-clause? Like this one from my code which is called right at the beginning?

if(issue.getIssueTypeId() != '10401'){
 return
} 

My assumption of 2000 was wrong. My query was jql and I simply made

updated >= startOfDay(-1) AND updated <= endOfDay(-1) 

Forgot that any of the 2000 issues could be updated x times.

I defenetly will do that in our dev environment, where everything will be fine due to almost no traffic. But thats exactly my point. How do I know that the script will not cause any performance problems in production.

Anyway, your hint of load testing is very good. We haven't done this and I don't have expirience in that, but will look it up :) 

If you can still reply to the condition question. Would be very helpfull.

[Joshua Yamdogo @ Adaptavist]

Hi,

You're correct about the simple if-clause. Writing those can you help you reduce the amount of work that the listener needs to perform every time it is triggered.

With regards to dev environment testing, that is a good question. You could write a script that simulates thousands of issue updates being executed. For example, we have a script in our Script Library that shows how to update the priority of an issue: https://library.adaptavist.com/entity/update-the-priority-of-an-issue-in-jira

You could try using that in your dev environment within the ScriptRunner Script Console. You could add some code to that script to get every issue in your test project, and then loop through all the issues to update every issue. Set up a listener that listens for the Issue Updated Event and you can test how it runs.

Does that make sense?

Regards,

Josh