Convert sub task to issue

[gilles kekenbosch]

I have a few questions with convert sub task to issue

First of all, if the status of the source subtask exists in the target workflow, the step of defining the target status is skipped, whereas it is possible that it has to be changed.

Secondly, I don't understand how the fields to be configured are selected in the next step: they are neither all the fields nor all the mandatory fields in the target type nor anything I can think of.

Thirdly, as there is no constraint on the fields that are mandatory in the target, the resulting issue is likely to be badly initialized. Some mandatory fields may not be editable in the target status if they are hidden or read-only.

Finally, I support the request for adding a permission to run this function which is currently not considered by Atlassian, since, for the captioned reason it is best to restrict it to user with administration rights.

[Nic Brough -Adaptavist- · Accepted solution]

I do not understand what you are asking about here.

>if the status of the source subtask exists in the target workflow, the step of defining the target status is skipped, whereas it is possible that it has to be changed.

I cannot work out what you are talking about here, other than it's something about the relationship a sub-task has with it's parent and their status.  All I can tell you is that the status of parent and child are technically totally independent, but most of us do some restriction of transitions, most commonly "cannot close issue while there are open sub-tasks"

>I don't understand how the fields to be configured are selected in the next step: they are neither all the fields nor all the mandatory fields in the target type nor anything I can think of.

What "next step"?  You've not said what you are doing.

Fields are made mandatory in field configuration for the issue type.  They're not flagged as such during any process other than "edit field config"

>as there is no constraint on the fields that are mandatory in the target, the resulting issue is likely to be badly initialized.

See the bit above about field configuration

>Some mandatory fields may not be editable in the target status if they are hidden or read-only.

Jira doesn't do field level permissions, you can either edit an issue or you can not.

>I support the request for adding a permission to run this function

What function?  You have not told us what you are talking about

[gilles kekenbosch]

Hello, sorry. I am referring to the "convert to issue" entry in "more" menu when visualizing a subtask of some issue. It actives a four steps wizard of "select issue type", "select new status", "update fields" and "confirmation". 

[gilles kekenbosch]

"select new status" step is skipped when the source subtask status is found in the target issue status which is not good

in the step after "updates fields" I can not understand why some fieds are shown and other are not

in the "confirmation" step there is no check and mandatory field in the target issue can be left empty

this is a problem since they may not be editable by a user in the target issue

[Nic Brough -Adaptavist-]

I apologise for the delay, I've missed the email telling me you had given us more info.

Convert to issue has to jump through hoops because it is possible to configure issues in different ways, and data conversion may be needed.  Jira tries to keep that as simple as possible.

Select issue type is something you'll always need to do - sub-tasks are a different issue type.

Selecting the issue status only occurs when Jira can't use the current status because it's not in the workflow for the target issue type.  Remember that you're not changing status here, the issue is of the wrong type, not in the wrong place in the workflow.

Jira simplifies fields as well - it will only ask you about fields that need to change - fields that are not valid for the new type will warn you that they won't be visible or will be deleted, and any field that is mandatory in the new issue type field configuration will be checked to see if it is empty - mandatory means mandatory!

[gilles kekenbosch]

Hello thanks again ! Sorry I have been away for a while. I am still not happy with this feature. May be I should log a change request:

- I would like to be able to change the status whatever the case

- I would like Jira to prevent a user from modifying the type without providing the data in the target mandatory fields (there is no such check) 

- I would like Jira to explain in the documentation how "fields that need to change" are selected.

[Nic Brough -Adaptavist-]

That change request won't happen, it's not possible.

- status is a function of workflow, not issue type.  If the source and target issue types have compatible status in their workflows, then there's no need to change it.

- there is, you will be asked to fill in mandatory fields if they are empty.  Only ones flagged as mandatory in the field configuration for the target issue are checked though, if you're doing it some other way (validators for example) it can't check them.

- Fields that need to change are fields that are configured differently between the two issue types, and the current issue is holding data that is not compatible with the configuration of the target.  (If, for example, subtasks have a "colour" select list with red, green and blue as options, whereas stories have "colour" of cyan, magenta, yellow and black, then you'll need to select new values for colour when you convert)

[gilles kekenbosch]

Many thanks @Nic Brough -Adaptavist-