Scriptrunner Listener - Assigned per History tab and logs but not showing in assignee field

[Julia Foden]

Hi

I am trying to use a listener to assign an issue randomly from members of a group (in a group picker field) when a date field is set to a date within a week of now.

The random assignment from the group works fine and the date compare works fine.

Here's my code

import com.atlassian.jira.component.ComponentAccessor

def issue = event.issue

def changeHistoryManager = ComponentAccessor.changeHistoryManager

def lastChangedItem = changeHistoryManager.getAllChangeItems(issue).last() as String

def endDate = issue.getCustomFieldValue(11019) as Date

def nowPlus7 = new Date() + 7

def customFieldManager = ComponentAccessor.customFieldManager

def endDateField = customFieldManager.getCustomFieldObject(11019)

def endDateName = endDateField.fieldName

log.warn(lastChangedItem)

if (lastChangedItem.contains(endDateName)){

    if (endDate.before(nowPlus7)){

        log.warn('need to assign')

        def groupManager = ComponentAccessor.getGroupManager()

        def group = issue.getCustomFieldValue(19200)

        def users = groupManager.getUsersInGroup(group).toSorted{it.key}

 

        users.shuffle()

        

        issue.update { setAssignee(users.first()) }

        log.warn(users.first())

        log.warn(issue.assignee)

    }

}

This is what happens after I edit the date field:

• on the history tab of the issue, it shows that I changed Assignee from blank to <a member of the group>
• in the scriptrunner log, first ChangeHistoryItem shows the change to the date field, then 'need to assign', then ChangeHistoryItem again with the detail of the new assignee , then nothing else
• the Assignee field in the ticket appears empty
• in the Issue Navigator list view, the issue appears as Unassigned

Can anyone advise what is the problem here. Happy to take any other advice on improving the code too, but the main thing I need to understand is this disconnect between the History tab and logs on one hand and the Assignee field on the other.

Thanks,

Julia

[Bobby Bailey · Accepted solution]

Hi @Julia Foden , 

I have had a look at your issue, and it is interesting! It is a little difficult to diagnose. I was unable to do so, I recorded a short video running through that here.

It is worth noting (as mentioned in the video) if you are running Server then it could be a bug or issue that has since been fixed for me, but won't for Server as its no longer supported. I did see the issue you mentioned, however after a reindex that fixed the issue and it hasn't happened since. 

If its not possible to get it working for you, my suggestion would be to use Behaviours to get the same functionality. 

As for your other questions: 

Firstly, to your question about the difference between .update and .set, from here. It looks like .set is being used to just modify the issue in memory, rather than .update, which would save to the database itself by running the update function. Generally, we would say to use .set on a Post Function, as you have an issue in memory at that point to edit, but the post function itself will perform a save, so doing so twice would be redundant. 

As for you other question, yes, the listener would execute the script as (and so using the permission set of) the user that triggered the action. If you would like to have the script execute with a different user like a service account, you can use the User function set in HAPI (docs here) to do so. The example snippet in the docs is best: 

            def issue = Users.runAs('anuser') {
                Issues.create('SR', 'Bug') {
                    setSummary('created by another user')
                }
            }

I hope this helps!

Kind regards,

Bobby

[Julia Foden]

Hi @Bobby Bailey 

Thank you for your investigation and advice. I'm in DC not Server (I don't seem to be able to change that here) but it is indeed an older version.

Because I could only get it working with .set which doesn't appear in the History tab (this would fit with your explanation that .set only modifies the issue in memory), I feel that I can't rely on this.

Thank you for your suggestion to use a Behaviour. This is new to me and I have been doing some experimenting, not entirely successfully.

So I want to assign an issue when a date field is edited if the date field value meets a condition relative to now. 

This seems to work if assignee is on the edit screen and if the person editing the date field has the Assign Issues permission.

def assigneeField = getFieldById('assignee')

assigneeField.setFormValue('fodenj')

But what if the person editing the date field does not have Assign Issues permission? I tried 

Users.runAs('srv-jirasml'){

            getFieldById('assignee').setFormValue('fodenj')

        }

but nothing happened even though that user has the permission. 

Would it be because .setFormValue depends on the assignee field being on the edit screen for the person doing the editing?

Is there an alternative method I could use? I saw your video about assigning in a behaviour in Cloud where the method was .setValue but that doesn't seem to be available in DC.

Thanks,

Julia

[Bobby Bailey]

Hi @Julia Foden

To be clear, Behaviours doesn't function in the same way as the other features. The other features work behind the scenes, but Behaviours function on the active screen on the webpage. 

As a result, even if the user doesn't have the permissions to change the field, if you have this code: 

def assigneeField = getFieldById('assignee')

assigneeField.setFormValue('fodenj')

And the user changes the date, it will function. Just in case you didn't know (as you are exploring ScriptRunner) you can use the Switch User built in script to test this easily. 

The challenge here is that Jira hides the assignee field when the user does not have permissions to set the assignee. As Behaviours works on the screen available, if the field isn't show, we don't have the ability to change it.

To continue with Behaviours, the solution would be to give the users permissions to assignee issues, but then to use Behaviours to set the field as Read-only for the permission set: 

import com.atlassian.jira.component.ComponentAccessor

import com.atlassian.jira.security.roles.ProjectRoleManager

// Get the assignee field

def assigneeField = getFieldById("assignee")

// Get the current user

def currentUser = ComponentAccessor.jiraAuthenticationContext.loggedInUser

// Get the current project (from the issue context)

//def project = underlyingIssue?.projectObject ?: 

// ComponentAccessor.projectManager.getProjectObjByKey(

// getFieldById("project")?.getValue() as String

// )

// Check if user is in the Administrators project role

//def projectRoleManager = ComponentAccessor.getComponent(ProjectRoleManager)

//def adminRole = projectRoleManager.getProjectRole("Administrators")

//def isAdmin = false

//if (project && adminRole && currentUser) {

// def actors = projectRoleManager.getProjectRoleActors(adminRole, project)

// isAdmin = actors.contains(currentUser)

//}

// Alternative: Check if user is in jira-administrators group

def isAdmin = currentUser?.isMemberOfGroup('jira-administrators')

// Make field read-only for non-admins

if (!isAdmin) {

 assigneeField.setReadOnly(true)

 log.debug("Assignee field set to read-only for user: ${currentUser?.name}")

} else {

 log.debug("User ${currentUser?.name} is an admin, assignee field is editable")

}

However, this would now mean that users could in theory circumvent that (for example bulk updates). 

Because of that, I am not sure if this would be the right solution for you. 

If not, could you outline for me the issue you are seeing with Listeners? Specifically what you are expecting to see, and what is missing? Also, could you let me know the Jira Version and the ScriptRunner version you are using?

Kind regards, 

Bobby

[Julia Foden]

Hi @Bobby Bailey 

Thanks again for looking into this. I think Behaviours is not the right solution for me, as you say. The problem with Listeners was what you already looked at in the video you recorded and you weren't able to reproduce it. 

So I've decided to forget about instant assigning when the date field is edited to a date within a week of now. I had already created a Job to find issues whose end date is within a week of now and assign them appropriately, I'll just have that job running more frequently through the day.

Thanks again for your help. I am accepting your answer and hope it will be useful to other people in the future :)

[Julia Foden]

I'm not sure why this was put in App Central rather than Jira Q&A where it probably would have got more views (maybe it was my fault when I created the question but I don't know if I can move it now).

Anyway, I now seem to have solved the problem by changing from

issue.update { setAssignee(users.first()) }

 to 

issue.set { 

            setAssignee(users.first())

        }

This now does update the assignee but it doesn't appear in the History tab. Does anyone know why?

Can anyone explain or point me to documentation on the difference between update and set?

And a question on permissions - do listeners depend on the permissions of the user whose action (editing a field in this case) triggered the listener? If that user did not have Assign Issues permission would this listener still fire? If not, how can a listener be configured to perform its action as a specific user (a service account)?

Thanks, and if any forum moderator sees this, can you move it out of App Central which seems to be mostly ads.