How can I hide a transition of a parent issue and have it automatically transition programatically?

[Thomas Hardin]

I am working with an issue that creates multiple linked issues based on a field selection. There can be one or up to 9 linked issues, all blocking the parent issue. What we want is for the parent issue's Resolve transition to be hidden from users and triggered only when the last sub task's Resolve transition is triggered. This all seems pretty straight forward.

1. Parent issues is created

2. Sub tasks are created based on field selection

3. When ALL sub tasks are resolved, resolve the parent issue automatically

I was able to add the post function that triggered the Resolve transition, which works as expected, however; when I cannot get the transition to trigger when I have a condition or validator set. I have tried the following scenarios:

1. I set a condition on the parent issue's transition to ensure that all linked issues through the is blocked by link were in a Resolve status. When I tested, the sub task transitioned as expected, but the parent did not.

2. I set a validator to verify that the linked status of the sub task was in Resolved status. When I tested, I got an error indicating that the a Commit Failed.

I have tried several options with the workflow add-ons that we currently use (JSU and JWME), but nothing seems to be working properly.

I know this is pretty rudimentary, but I could really use some help.

Thank you all. 

[David Fischer]

Hi Thomas,

there are several approaches to this requirement. Using JMWE 5+, I would suggest two:

1) use a Subtask Blocking Condition on the Resolve transition (or a Linked Issues Status Condition if your subtasks are not real subtasks but rather linked issues). This will hide the Resolve transition from users unless all subtasks are resolved. Then add a Transition Parent Issue (or Transition Linked Issues) post-function on the Resolve transition (of the subtask workflow or of the shared workflow) to trigger the "Resolve" transition on the parent issue. This will silently fail if the Condition is not met.

2) hide the Resolve transition on the parent workflow from users entirely using the "Hide from users" Condition, and add a Transition Parent Issue (or Transition Linked Issues) post-function on the Resolve transition of the subtask workflow to trigger the "Resolve" transition on the parent issue, and use Conditional Execution to make sure all "sibling" subtasks are Resolved

[Thomas Hardin]

Thanks David,

I did have the workflows set up pretty much identically to what you mentioned, however; for some reason, I got an error when I attempted to transition 1 sub task, and other didn't work.

I know it sounds odd, but I'm wondering if there is an issue with workflow in general as I created them by copying and renaming each one. Could I just have a defective workflow? Is this possible?

I'm wondering if a script would be a better approach anyway. This way I could have one workflow for all the sub tasks. The trick then would be to make sure that each sub task was assigned to the respective project role.

[Thomas Hardin]

I've gone back and tried to set up a simple process based on the suggestions above and I have 1 main issue type - Termination Request, which can trigger 1 or more issue types (in this case, I am only creating a Debrief from Clearance request. 

I have 1 condition set for the Termination Request, which is on the Resolve this Issue transition.This hides the Resolve this Issue transition from the Termination Request as expected (noted in screenshot above).

For the Debrief from Clearance workflow, I have the post function to trigger the Resolve this Issue transition on the Termination Request.

When I publish and test the functionality by selecting the Resolve this Issue transition on the Debrief from Clearance request, it does not trigger the transition on the Termination Request.

Am I losing my mind? LOL.

[David Fischer]

It looks ok indeed. Did you check the "tail" of your logfile (atlassian-jira.log) after transitioning RSH-217? If any error occurred, it will be listed there. 

Did you also check the exact (case-sensitive) spelling of the "Resolve this issue" transition (or did you enter it using the transition picker)?

Also, after transitioning RSH-217, did you navigate to RSH-216 to check that the "Resolve this issue" transition was now available?

[Thomas Hardin]

I found the issue! The parent issue type required a resolution and that was not being set with the transition. So, by removing the screen in that Issue type, I was able to successfully close out the issues as expected.

Given that I am using 9 different workflows, do you by chance, have an example of a script that could potentially assign the issues based on type? The only reason I have so many workflows now is because I am assigning the issue to a role and firing off a custom event for that team. If I could add a script to do that, then I would only need 1 workflow for the sub tasks making my life a lot easier.

Thanks again David!

[David Fischer]

Note that with JMWE 5.2.0, you can actually pass a Resolution value to the transition screen using the Transition Linked Issues post-function.

As for your other question, do you mean something like using the Set Field Value post-function to set the Assignee field to the result of a Groovy script such as:

switch (issue.getAsString("issuetype")) {
  case "Bug": return "jdoe";
  case "Task": return "jblack";
  default: return "admin";
}

[Thomas Hardin]

For the most part, yes. In my scenario, I want to assign the issue to a role member based on the issue type:

Issue type = "Debrief from Clearance"

Project role = "Debrief Team"

Triggered event = "Debrief from Clearance"

With the number of issue type managed by this department, I had to set up events and roles for each one so that the issue is assigned to a role member and a notification is sent out to all members of the role so that they are all informed. I did this because, I didn't know how to determine which member of the role would get the issue and if that member was not available, one of the others could assign it to themselves and work the issue.

I do not think there would be a situation where a role would not have members due to the nature of this department, but if that situation occurred, I'd like to have the issue assigned to the department manager.

I did find some groovy scripts that resembled my needs, but have not had much luck with them.

My sad rendition:

import com.atlassian.jira.issue.CustomFieldManager
import com.atlassian.jira.issue.IssueManager
import com.atlassian.jira.issue.fields.CustomField
import com.atlassian.crowd.embedded.api.User
import com.atlassian.jira.user.util.UserManager
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.MutableIssue
import com.atlassian.jira.issue.UpdateIssueRequest
import com.atlassian.jira.event.type.EventDispatchOption
import com.atlassian.jira.bc.projectroles.ProjectRoleService;
import com.atlassian.jira.project.Project;
import com.atlassian.jira.project.ProjectManager;
import com.atlassian.jira.security.roles.ProjectRole;
import com.atlassian.jira.security.roles.ProjectRoleActors;
import com.atlassian.jira.security.roles.ProjectRoleManager;
import com.atlassian.jira.security.roles.RoleActor;

//Original script
def assignee = null
MutableIssue issue = issue
Project project = issue.getProjectObject()
ProjectRole role = null

if (issue.issueTypeObject.name == "Change Combinations")
{
ProjectRole sdTeam = projectRoleManager.getProjectRole("Service Desk Team");
ProjectRoleActors sdTeamActors = projectRoleManager.getProjectRoleActors(sdTeam, project);
issue.setAssignee(sdTeamActors.getUsers().toList()?.first());
issue.store();
}

[David Fischer]

Why don't you use multiple "Assign to Role Member" post-functions, together with a conditional execution script on each to only run if the issue's type is the expected one? This would be easier...

[Thomas Hardin]

That does sound like the best way. we are testing script runner also. do you think setting up listeners to fire events based on the issue type would work for notifying the project role members?

And I really appreciate all of your help.

[David Fischer]

I don't know much about ScriptRunner, but why don't you use the "Email Issue" post-function for that?

[Thomas Hardin]

If I could figure out how to duplicate the Issue Created event email, I would jump all over that, but our customers like the way it looks. I guess I could pull the HTML and Text templates and see if I could create something to resemble them.