Tracking a tickets last update, without using the Update Date field

[Jordan McCombs]

Hey eveyrone,

I'm being constantly asked by one of our DevOps managers for a way to help him track stale tickets. Now the issue here is that we have a lot of scripted fields via script runner, and these scripted fields also update other fields on the ticket, they can update every 3 hours, and basically, the Updated Date on a ticket in this project can not be trusted to be accurate.

The scriptrunner scripted fields don't transition an issue or anything like that, but they update field values. So since field values are frequently being updated on these tickets, the Updated Date is no longer accurate of a true, user-made update.

I directed the user to try to try JQL like project = DOS and (issueFunction in lastComment("before -7d")) and (project = DOS and !(status changed after -7d) AND status not in ("Closed", Open))
, however this isnt giving him the full picture like Updated Date used to.

I've also reached out to script runner to see if it's possible to disable firing off an update event on-field updates made by the scripted fields, and while that is possible, that isn't going to work for us.

Do you have any ideas on how we can get better reporting via JQL on issues that truly are stale? I know one issue he has with the JQL I provided, is that he can't sort by which ticket is the oldest, or which ticket hasn't transitioned or been commented in the longest amount of time.

Do you have any other ideas on workarounds? I'm out of ideas on this one.

[Hana Kučerová · Accepted solution]

Hi @Jordan McCombs ,

I have one suggestion - I don't like it much, but I wasn't able to find anything better. 

You can try to create another datetime custom field and custom script listener, which will execute the script ever time issue is updated. The script will determine, whether the update is made by technical user or real user and if it is real user, stores "now" to it. This way you should be able to get datetime of the last change made by real user.

[Jordan McCombs]

Hey @Hana Kučerová,

Thank you for the suggestion. We have had similar thoughts over here on our end, and we also aren't big fans of the idea, but I just can't seem to think of any other solution besides adding in another date field. I'll see if anyone else has any other ideas for a few days, but I think this going to be our answer.