Please create a fix for this missing core feature of Jira Service Desk. Using automations as a work around for an expected, default product feature is not acceptable.

Has there been any progress on this feature? Since the update to how Automation usage is billed, the automation workaround outlined below significantly contributes to usage:

https://confluence.atlassian.com/jirakb/set-resolution-field-for-team-managed-project-jira-issues-1236437014.html

I am surprised that this basic field is messing and there is no way to set this in the team managed project.   The appropriate name for these type of projects should have been "Atlassian managed project"  I would think th eteam managed project would have complete control for the to manage the workflow as they wish.  However, I am finding more and more issues every day.  There is also no way to migrate a team managed project to a company managed project.  So we are almost stuck with using something that is not desirable on a daily basis.   

My createt vs solved dashboard look like this. Red are created and green are solved, On my vidget on my phone it says that I have 400 open issues and 0 solved issues. All exports states that my cases are not solved. I there an atvantage to this feature ? How many customers have stated that it is critical for them that a case with status Completed has a Resolution not solved ?   Part of the appeal of using a cloud system is that is a service that just works. Since this has not been fixed for 3 years at least now I guess it is not a bug, but a feature. I'm just struggeling to understant the appeal of this feature.

I'm surprised this is a thing. It's like you guys didn't think about your dashboard widgets. Even some of the most basic queues that are created automatically have resolution as part of the JQL to pull in the tickets. 

Sad to see this very basic functionality is still missing from Jira.  How can you have a workflow without the ability to properly identify how it was resolved?  This seems like such basic functionality to include for your users.  The workarounds are not sufficient and cause errors in reporting.

Its impossible to create reports based on the Resolved date, if SD next gen projects wont set it. Why have widgets that use this field if its left empty?

agree with Glen, while you can set the resolution via an automation to a status etc. there is no way to reopen an issue with post functions or automations. This eliminates the ability to use the reporting functions when issues that need to be "Reopened" have "Resolutions" and "Resolved Date" included... gives inaccurate reports on the team managed projects.

This issue summary is not accurate to the scope of the problem; not limited to just JSD projects but ALL team-managed projects including Business and Software projects.

The workaround using automation rules only partially works because if you need to re-open an issue an automation rule cannot clear the resolution field. Therefore, you have Open tickets which have resolution not empty.

Seems like such a simple fix to make the product useful, yet over three years later no one is even assigned the issue. Fantastic.

Workaround kind of works, but it's very limited. Would be much better if TMP had an actual rejected status out of the box, which asked you what resolution to set when transitioning to it.