Populate the "Customer Request Type" in a sub-task

[ianvanzyl]

Hi there

We have a workflow that requires another activity to be executed as part of the workflow. The overall SLA incorporates the time allocated to the other dependent activity. 

One of the transitions in the workflow is an "Authorise" step which has a condition that all sub-tasks need to be in a specific state before being permitted to progress onto the "Authorise" state.

This other activity has its own workflow and may be selected from the portal as its own "Customer Request Type" but I have created a sub-task which may be used in the workflow to accomplish this same activity.

As part of the main workflow, I have create a transition which will create the sub-task by means of a ScriptRunner script to create sub-tasks. The script executes correctly and one can see the sub-task as part of the main issue.

However, when going to the queue to see all open tasks, this newly created sub-task does not have a value associated with the "Customer Request Type". The "Customer Request Type" is used by the teams to do the actual work associated with the task. Since no value is placed in this field.

If I change the workflow to create a linked task, the condition associated with the "Authorise" transition does not execute as the "Block transition until approval" condition is only applicable to sub-tasks and not linked tasks.

Please could someone provide a solution to my predicament.

Thanks in advance.

no one can determine who needs to do this work.

[ianvanzyl]

Managed to find a solution.

Create an automation rule.

https://confluence.atlassian.com/jirakb/automatically-set-customer-request-type-when-issue-is-created-via-jira-859463969.html

This works. 

[Eugene Yasiuchenko]

hello @ianvanzyl   automation rule and manual converting used to be working well for myself and our company's setup up until Nov-Dec 2018 I guess.

Since then - there are problems with displayin ticket details on clients portal. Once you convert JSD portal request to a sub-task - details disappear from the portal.

Have you faced with the same problem ? Were you able to resolve that somehow?

Thanks!

[Nic Brough -Adaptavist-]

There's a structural problem here.  A request in Jira is represented in the back-end by an issue.  A customer has a single request, and Jira is written to handle it via that single issue. 

Sub-tasks are part of the issue, added by internal users and hence not directly related to the request type.

My instinct, if I had been Atlassian, would be to cascade (read only, of course) the request type down to the sub-task from the parent, as it can be useful.  I can't see any reason not to do that.  But Atlassian have not implemented it.  I don't know why, but I'd guess because people would demand all the rest of the request information as well, which is even more code, and the easier answer is "go look at the main issue, sub-tasks are for you to just break it up a bit"

Of course, if you do "fix" it, you're going to need to be able to explain to users why the Service Desk gives them different numbers to Jira.  Think about the question "How many Requests did we handle last week?".  Service Desk might answer "80", and Jira "320", because you added an average of 3 sub-tasks to each one.