-
Suggestion
-
Resolution: Unresolved
-
611
-
-
Issue Summary
In the new issue view, JSD allows the modification of issue layouts at the request type level. This means that for any issue types without request types, such as subtasks, there is no way to edit the issue layout.
Steps to Reproduce
- In a Service Desk project create a subtask
- Try to edit the issue layout in order to remove the request type
Expected Results
It's possible to edit the issue layout and remove the request type since it's not used.
Actual Results
It's not possible to edit the issue layout because the issue type doesn't have a request type.
Workaround
Currently, there is no known workaround for this behavior. A workaround will be added here when available.
- is cloned from
-
JSDCLOUD-9226 In the new issue view it's not possible to edit the issue layout of subtasks to remove the request type
-
- Closed
-
- mentioned in
-
Page Failed to load
[JSDCLOUD-9230] Allow editing issue layouts of issue types without request types
Everybody ready for the 5 year party?
We built our entire IT Service Desk for 12k users in DataCenter around a Parent > Sub-task relationship. Now that we're in the Cloud version, Sub-tasks look like garbage and we have had to re-teach nearly 1k agents to use the take extra clicks/time and open the submission form because the fields are nearly impossible to find.
Our only alternative is to create 100+ Sub-Task Issue Types.
In addition:
When a case is transitioning between Issue Types, and before the Request Type is amended the fields presented are related to the Issue Type it is transitioning to (for example from Emailed Request to Incident).
It would be useful to be able to amend the order of the fields in the Issue Type view. The problem with that is that currently, altering these is likely to affect all projects and not just the one in which I need to make the change.
Since the Issue Type of Incident may have 2 or 3 Request types, I need the agent to select which they need before the Status of the ticket can be transitioned to ‘Accepted’. In order to achieve this check, I blank the Request Type field so a Condition of ‘Request Type Must Be Selected’ can be checked during the Status transition.
So we are left in this pending stage where the agent needs to make that change. However, the order of the fields and, yes, the Priority field (and other system default fields) are distractions from what needs to be done in this 'transitory' view.
Hi 96677a1d9b4c , would you please give us an update on this problem? Or do you know of a way to control the layout of sub-tasks and other issue types that have no Request Type? Thanks!
This is a big miss!
Not every issue type receives a Request Type! And what about subtasks?
My subtasks in JSM look like crap! And I have no control over the layout.
I always find it funny how missing requirements are received as "Suggestions" later. I call it incompetent requirements gathering instead.
Hello Atlassian,
I would like to be able to rearrange the fields on a sub-task because it would provide more clarity around the importance of some fields over others for the Jira Agents/Assignees (i.e. they can focus on the fields on the right side status panel, but other fields that give more contextual information could be placed under description)
Also, I think it just makes sense logically since all the other issue types can have their own layout (through request types) 
Thank you for your consideration and attention!
This issue is important to our organization because we want to only display fields on the issue screen that are relevant and in a specific order of importance. Since I can't control the layout of the fields, it causes the fields to be jumbled and less important fields are higher in the issue than important fields.
We would love to see some progress on this issue as well! Thanks!
Why is everything in Jira Service Management configured in a way that causes everyone headaches?
It's been 5 years... how is this not resolved yet?