Finding when an issue was last updated by its current assignee

Question

Up front: I have JIRA Software 7.0.4 on-premises with ScriptRunner, Misc Custom Fields, and all the usual add-ons people will say this would be impossible without.

I'd like to be able to determine how much time has passed since an assignee has interacted with an issue. LastUpdated-by is one thing, and the difference between the issue's overall last updated date and today is another thing, but the important metric is how long it's taking for an assignee to respond to a ticket, even if a non-assignee is updating fields (delayed fixVersions) or adding comments ("Anybody home?").

The ultimate goal is to have something like an email alert be triggered for any issue where "assignee hasn't responded in 30+ days".

I'd like to avoid using transitions and special statuses when waiting for a response from someone, since that's workflow-specific and I'd really rather have something that can work system-wide.

Does anyone have ideas for how to achieve this kind of thing?

Thanos Batagiannis _Adaptavist_ · Answer

Hi Joshua,

Here is a possible solution (and it would be interesting to see how people address similar situations, as Bart did). In two steps

* Create a custom field, let's name it daysWithoutAction. And then an (built in scripts ->) escalation service that will triggered every day and will add one day in the daysWithoutAction. Make sure that the user that you configure to be the 'user that the service will run as' will not going to be the same with the assignee.
* Now we want somehow to 'zeroing' the daysWithoutAction custom field when the assignee does something in the issue. You can create a (script listener -> ) custom listener which will 'catch' the issue updated events and if the update comes from the assignee then to zeroing the above custom field.

//pseudocode
if (event.user == event.issue.assignee) {
    // set zero the daysWithoutAction custom field, without firing an update event
}

You can even 'send an email' within the above listener if the custom field value == 30

// Create an email
def sendEmail(String emailAddr, String subject, String body) {
    SMTPMailServer mailServer = ComponentAccessor.getMailServerManager().getDefaultSMTPMailServer()
    if (mailServer) {
		def emailTo = event.issue.assignee?.emailAddress
        Email email = new Email(emailTo)
        email.setSubject(subject)
        email.setBody(body)
        mailServer.send(email)
        log.debug("Mail sent")
    } else {
        log.warn("Please make sure that a valid mailServer is configured")
    }
}

I didn't test the above solution (and If I find some time I will) therefore any arguments or thought are more than welcome. Now if in your case the only 'acceptable' update the assignee can do is to transition the status then a solution with post functions (maybe similar with what Bart proposed) is more appropriate.

Kind regards

Bart Van Belle · Answer

Hi Joshua,

I am looking for exactly the same thing, and didn't find a real solution either.So I am curious to read other posts about this topic.

What we are using as a workaround, is checking when the status is changed.

Meaning, when an issue gets assigned to a specific user and other users are updating the issue (eg. adding comments or changing other issue fields), we don't see this as an "issue update by the current assignee". We are only interested when the current assignee changes the status of this issue (eg. from To Do --> In Progress ) because this means for us that the current assignee did something active on the issue (besides updating comments, updating issue fields). Changing the status means for us that "real" work was performed that adds value to solving the JIRA issue. We have a postfunction in the workflow so that only a ticket can get transitioned by the current assignee.

So the  JQL status we use is project = "ABC" and NOT status changed after -30d

It's not exactly what you are looking for, but you can ask yourself the question do you need to know when the current assignee added comments, updated issue fields or are you interested why a ticket doesn't get transitioned through a workflow ? Also at our company it can be the case that a developer keeps a ticket in a specific status for days and for us it's enough to know that they are working on that ticket, if the ticket doesn't get transitioned after x days, then we take action.

Is this something you can use ?