Hello,
I have a listener which performs some behavior when a change is made to the due date of an issue. The problem is, this behavior is also triggered when a subtask is created for the issue, because technically this is a modification of the parent issue, and apparently to the due date, as well.
How can I differentiate between a true modification to the parent issue's due date and the creation of a subtask, which is interpreted as a modification to the parent issue's due date?
Relevant section of script below:
//Takes an IssueEvent and, should that IssueEvent be a change of Due Date, adds the previous Due Date as a label to the affected Issue public void dueDateChanged (IssueEvent issueEvent) { Issue issue = issueEvent.getIssue(); List<GenericValue> changeItems = null; ApplicationUser user = ComponentAccessor.jiraAuthenticationContext.getLoggedInUser(); try { GenericValue changeLog = issueEvent.getChangeLog(); //grab all changes on this issue HashMap<String, Object> fields = new HashMap<String, Object>(); fields.put("group", changeLog.get("id")); //make map out of them (unsure what "group" and "id" are for) GenericDelegator delegator = changeLog.getDelegator(); changeItems = delegator.findByAnd("ChangeItem", fields); //place them in a list } catch (GenericEntityException e) { log.error(e.getMessage()); } //iterate through list of changes and find if the change was to the duedate for(GenericValue changeVal : changeItems) { String field = changeVal.getString("field"); if(field.equals("Due Date & Time")) { //check if the issue is brand new, to prevent generation of DUE DATE CHANGE comment for change from null to something Object checkPrevDueDate = changeVal.getString("oldstring"); //see if such a string even exists in changeVal! String issueTypeId = issue.getIssueTypeId(); //see if we're dealing with a subtask here if(!checkPrevDueDate.equals(null) && !issueTypeId.equals("5")) { //if such a string does exist, i.e. the due date has actually been set at least once String newDueDate = changeVal.getString("newstring"); String prevDueDate = changeVal.getString("oldstring"); addComment(issue, user, "{color:#d04437}*DUE DATE CHANGE*{color}\n\nOld: " + prevDueDate + "\nNew: " + newDueDate + "\nReason: "); prevDueDate = prevDueDate.split(" ")[0]; addLabelToIssue(issue, user, prevDueDate); } } } } } DueDateChanger dueDateChanger = new DueDateChanger(); dueDateChanger.dueDateChanged(event); //event is automatically given to us by CustomListener environment(?) in JIRA
As you can see, I tried excluding the case where the issue ID is 5 (subtask in our JIRA), but this had no effect. It also isn't exactly what I want, because someone might change the due date of a subtask, which should trigger the script because it's a legitimate change.
Hi Samantha,
So in a custom listener that will listen for issue Updated events you can check which field (in your case the duedate field) trigered the event using the following script
def change = event?.getChangeLog()?.getRelated("ChildChangeItem")?.find {it.field == "duedate"} if (change) { log.debug "The due date changed" def oldValue = change.oldstring def newValue = change.newstring }
regards, Thanos
This was very helpful, thank you
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.