It's been 5 years... how is this not resolved yet?

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.

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.

Its August 2024, where is that long overdue October 2023 update?

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!

Plus one on this request!

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?

Any updates with this?

Still waiting for updates - we also need a solution in regard to this topic!

Simon Herd is not available anymore. Maybe we need to wait another three years in order to get an update on this!

Bump.

Hello, It's been few months how is it going?

We really need this feature, October 2023 is over, any update?

This is key functionality that needs to be worked on.

Waiting for this feature to fix the mess with sub-task fields in Jira Service Management projects.

This is not a feature that needs to gather votes; it is a must-have to keep everything organized.

3594564a659e any updates with this?

This is well needed. The functionality exists in Jira Software.

a620038e6229 I do want to commend you on providing additional transparency.  It is definitely appreciated to get responses from your side on these bugs and suggestions.  Are there any additional ways that we can help guide prioritization for Atlassian?  I think we all try our best to vote, comment, watch, give feedback, and chat with product managers, but wondering if there is anything else we can do.

It would be really cool if you all could align on what is on your roadmap, but then list it out in order and we could all vote or something to help give you an additional metric to evaluate.  You could even implement an Admin star rating and higher ratings get a stronger vote, haha.  I would love to help with the prioritization and will chat with anyone at Atlassian to help get you resources (if it helps).  There are lots of creative no-code workarounds for certain pain points of which the larger community and Atlassian might not actually be aware... so if we knew the roadmap plan with enough notice, we might be able to show you some additional workarounds that helps the other blocked functionality like this rise to the top of being addressed.

Even for this particular suggestion, I do implement tabs in the screen scheme to help organize sub-tasks as much as possible... but there are other bugs/suggestions that we are completely blocked on.

@Jehan

Thank you for the updates.

It's clear now that Atlassian doesn't prioritize things in a good way. I mean, the 3 points you seem to be focused on have clearly workarounds through automation and others.

This one doesn't have workarounds!!!

And the impact is huge.

All the fields are messed-up for sub-tasks. Please reconsider your plan. This ticket had been opened for more than 2 years now.

Before doing new things, you should fix the mess you did by bringing the new layout experience. Sorry if that's rude, but that's the reality...

Hi all, 

Thanks for your feedback here. We are actively discussing this feature request as we agree that it is needed and highly valuable. 

We are still looking to identify the work effort so we can figure out whether or not we can do this in the short-term. 

We apologise that we can't work on this immediately, we have been prioritising the following:

1. Issue create experience updates (adding the request type dropdown and surfacing the request type configuration)
2. Changing the issue type / workflow of a request type 
3. New request type configuration experience that allows access to all fields within the project

There are obviously other initiatives we are working on but these are the ones that we have prioritised over this feature request in the short-term. 

I hope that provides some context around why we haven't been able to fix this earlier, we do agree that it is important and I'm hoping to get a team on it in the next 12 months or so. 

I will provide updates over the next 12 months as we lock in our plans.

Best regards,

Jehan Gonsalkorale

Product Manager, Jira Service Management

Guys, while selling the benefits of one product (eg. Service Desk) over another (eg. JiraWork), you should clearly state the downsides or missing features like this one.

Not being able to arrange the fields on the screen for any issue that is of subtask issue type is a huge limitation. This is a logic fail and not having an ETA on this after 2 years gives all a not so good impression.

a620038e6229 added a comment - 05/Aug/2021 9:10 AM
Hi all, thanks for your feedback here. We are currently investigating this issue and will provide an update in the next two months or so once we gone through a prioritisation exercise and understand the work involved.

I'll provide an update as soon as we know more.

Best regards,

Jehan

It's been over a year, where's the update?!

What is the tipping point in terms of votes for an issue like this to be considered?

https://getsupport.atlassian.com/browse/JST-788431

Hi Support,

Please prioritize this bug, I agree with all comments above! No need to have request type (nor request language, or any other request type related field) in sub-tasks, since sub-task is a pure internal thing. Having reqest type related fields in sub-tasks is really confusing and the layout is out of control.

Many thanks!

completely agree with @Florain Royer, I need to assign sub-tasks to more than one person

I do this for Tasks via a custom field "Assigned To (Secondary)", or via the Team field, both of which are super helpful ways to have the Task appear in more than one service desk members queue, its flexible so you can choose different combinations depending on the scenario  

I use activitytimeline which is brilliant for managing task list for SD team members, but I can only assign at Task level,  I also need that flexibility at Sub-Task level hence need to configure the sub-task screen   

Please consider  

Is there already a solution? I agree with Andy's statement. Please fix this error soon.

Thanks in advance for a positive feedback.

Please fix this bug soon.  It's crazy that we are forced to accept fields that we don't use or need and in an order that makes no sense to our agents.

Thank you

Please let us know what direction you are going to take.

As far as I understand, customers can't see subtasks in JSM. I am fine with that, but me team relly on subtasks to make some progress with the JSM request.

And today the layout is out of control, the UI is a fully mess and nobody can understand it...

We need the same feature as in Jira software (the issue layout menu) for:

• subtasks
• tasks not associated to Request types.

Later, Jira designers could imagine to have another improvement to show subtasks as request types, but that's an improvement...

This is definitely very needed. We rely on subtasks in our service desk tickets, and they are a hot mess without the ability to manage layout.

Hi all, thanks for your feedback here. We are currently investigating this issue and will provide an update in the next two months or so once we gone through a prioritisation exercise and understand the work involved.

I'll provide an update as soon as we know more.

Best regards,

Jehan

This is not a simple suggestion but a BUG and a complete misleading conception mistake. Please, provide the same feature as Jira Software ASAP.

Robert, for standard issue types you can create hidden Request Types in the project and have them set with Legacy Automation at the moment of issue creation (then you can control the screen layout and your issues can actually communicate with customers if needed... without a Request Type your comments are not going out via email).

Subtasks are completely cutoff from configuration (they cannot have a Request Type).

I'm not even looking at this from a subtask context.  This doesn't work for "regular" issue types.

Why would this be intended functionality that you cannot edit the view of a subtask screen at all?  Can we get it on the https://jira.atlassian.com/browse/JRACLOUD-70555 at least then?  This is definitely a bug for subtasks since there is absolutely no work-around since subtasks cannot have a request type.  They probably were just thinking about main issue types without Request Types (at least with those we can just make a hidden request type that gets set on them as a work-around to control the screen).

Update: I just read the linked bug.  It is mentioned in that other issue (JSDCLOUD-9226) that it is intended that the new issue view won't let you edit the fields for sub-tasks.

Thus, if that is the intention, perhaps the documentation for subtasks in Jira Service Management project should be updated to state that it is not intended that customers should see subtasks, and thus the functionality to edit/configure the agent view is not available.

In other words: Using subtasks in Jira Service Management has limited functionality, and given those limitations, Jira Service Management customers should be aware of this deficiency and either:

1) continue forward and subtasks and deal with the inability to configure the fields on the screen

2) choose to use other Jira capabilities to create issues in a separate project and link them or create a regular issue that is linked to a request type.

It just seems that perhaps the documentation should be updated to indicate this deficiency/choice to not allow this capability. 

https://support.atlassian.com/jira-service-management-cloud/docs/create-issues-and-sub-tasks/

Note the description, "In the new issue view".

This works in the old issue view just fine, it is only broken in the new issue from (what I can tell).  Unfortunately, with the old issue view going away in Q1 2021 (if I recall correctly), this is going to become a bigger issue.

I wonder why this is a suggestion though instead of a bug?  Seems like that this functionality works fine in the old view, and since it doesn't work in the new view, it should be categorized as a bug instead?

+1

I was flabbergasted that basic functionality like this was not present...