How can I distinguish between change to issue and creation of subtask? Edited

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");
            def log = Logger.getLogger("com.acme.CreateSubtask");
            log.setLevel(Level.DEBUG);
            log.info("Field: " + field);

            //was the due date edited? was the issue in which the due date was edited the one we're concerned with?
            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
                log.info("Issue: " + issueTypeId);

                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 to a due date.

1 answer

Hi Samantha,

 

You could check the last change item for that issue and check if it is due date, for example:

def changeItems = changeHistoryManager.getAllChangeItems(issue)
if(changeItems.last().field == "duedate"){

    //some code here
}

Let me know if this works.

Thanks,

Johnson

Hi Johnson,

Thanks for your answer. However, I believe this is already what I'm doing, no? I iterate through the changeItems list, and if one of the fields modified is 'Due Date & Time', then the behavior I've defined should execute.

 

I believe the problem is that creating a subtask is technically a change to the issue, and that the script detects a change from the parent issue's current due date and the 'new' due date of the subtast. I.e. the due date of the subtask crops up as a changeItem with field 'Due Date & Time'.

 

Is there some way I can see if the 'Due Date & Time' field belongs to the parent issue, or a subtask created under this parent issue?

 

Thanks a lot!

I see what you are looking for.

Each change item contain an issueKey field so you can check if this issue key is equal to the issue key for the parent issue. You could also check if the issue.ParentObject comes back as null. If it does then you know you are in the parent object and then can do the change item checks.

When a sub task is created from a parent issue the  issue = issueEvent.getIssue() method will return the sub task that is being created. So you can use the isSubTask() method to check if it a sub task and do nothing in this case. 

Many options. I hope some make sense.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,945 views 12 18
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot