My client wants to be able to create a filter for issues where Field A has been updated in the last 7 days. As Jira doesn't have the ability to filter for updates made to specific custom fields I am trying to set up another date custom field (Field B) and using a ScriptRunner Listener to add the date every time field A is updated.
I have used some of the logic provided in this post: https://community.atlassian.com/t5/Jira-questions/Scriptrunner-listener-to-update-custom-date-time-field/qaq-p/387444
Specifically, the code below (although have changed the field names as needed).
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.ModifiedValue
import com.atlassian.jira.issue.util.DefaultIssueChangeHolder
def cfm = ComponentAccessor.getCustomFieldManager()
def watch = cfm.getCustomFieldObjectByName("% Complete")
def watchValue = event.issue.getCustomFieldValue(watch)
def updatedWatch = cfm.getCustomFieldObjectByName("% Complete Updated")
def today = new java.sql.Timestamp(new Date().getTime())
if (event.getChangeLog().getRelated('ChildChangeItem').find{ it.field == '% Complete'}){
def changeHolder = new DefaultIssueChangeHolder()
updatedWatch.updateValue(null, event.issue, new ModifiedValue(null, today), changeHolder)
}
This seems to be working and whenever I update Field A, Field B is populated with the date. However, when trying to build a JQL search for "Field B" > -7d it is not returning results, and when I try "Field B" is not EMPTY I also get no results. However, if I search for the specific key of an issue with Field B populated I can see the date populated in the column.
As a test, I manually updated Field B with tomorrows date which allows me to search for it in the issue navigator based on "Field B". I then updated Field A again which caused the Listener to update Field B with today;s date and viewing the issue in the issue navigator the date has been updated correctly to today's date. BUT, my JQL searches still seem to read it as tomorrows date, which I entered manually.
The JQL search only seems to be able to interpret the data I have manually entered into the field, and disregards amendments made by the Listener. Have I missed something obvious in the Listener code or is it known behaviour that JQL cannot parse data entered onto a field by a ScriptRunner listener?
Hi Arbak,
There is an easy enough way for Automation for Jira to do what you need.
I have attached a screenshot which walks you through the steps. (Just keep in mind that I have used the field 'Approvers' instead of 'Reviewers' in the example as this is your custom field.
Let me know if this works for you or if you have any further questions!
Cheers,
John
Hi John,
Thanks a lot for your answer! This is exactly what I was looking for, and here's how I configured it in our case.
status = "10103"
This is "In review" status ID. However, for some reason it conflicts with some other rule that we have in automation.
This rule states that whenever assignee of the issue is changed, status should change to "NEW". I've added != condition for issues with "In review" (10103) status, so that it won't conflict with the rule above. However, there're cases when issues are left unassigned, or transition to "NEW" status even from "In review". What do you think may be the reason?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Arbak,
Glad to see we are close!
There are two changes I will suggest.
1) First - I would try and set the rule up similar to my screenshot (below).
2) Also if you don't need this rule to be triggered by another rule, make sure you untick the box in your 'Rule Details' (see screenshot).
Let me know how you go!
Cheers,
John
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi John,
There are 2 more statuses that should be excluded from the rule. If I do it with your approach, should I add 2 more "If: Compare 2 values" conditions?
Also seems that issues lose assignees when issue type is "Bug". I don't seem to find a way to create rule for specific issue types, shouldn't the base rule cover all?
thanks!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Arbak,
Yep - exactly right with regards to your first question. You can add two more conditions. (You can either use the 'compare two values' condition or the 'Issue matches JQL'
If you want to keep your rule that bit cleaner, you could use the Else / If block which will enable you to use multiple conditions in one. I have attached a screenshot to give you an idea of what I mean.
Secondly, if you want to create a rule for specific issue types, all you need to do is add a condition to check the issue type so it only executes on the issues you want. I have also included a sample of this in the second part of the sample rule screenshot.
Hope that helps but let me know if you have other questions!
Cheers,
John
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi John,
That's great! It answers all of my questions.
Big thanks to you for help :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Arbak,
In my opinion, the best way to reduce the scope is using custom events, create a new event based on "Generic Event" template and then replace in the desired transition the post-function generic event for the one you have created. Then, automation can be triggered when the specified event has been fired (Multiple issue events rule) instead of on issue transition.
You have several ways for implementing the conditioned behavior in order to set the assignee value, you can use ScriptRunner to add a custom script post-function or create a custom script listener together with the custom event (in this case you can remove the automation rule implemented before), you also can create multiple automation rules properly conditioned, etc.
Regards,
Marcos.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.