@Joelle J. Does https://jira.atlassian.com/browse/JSDCLOUD-1835 solve your issue?

Hello everybody. I have raised this issue multiple times with Jira, this is super critical. The answer from the support was: this is how the product is designed. I am not sure how all admins raise this painful concern and having the description field as a default field (therefore if a request type is selected or empty, the description field will be displayed in the customer portal.

This if we are not mentioning the fact that even sometimes when tickets are moved between boards, the request type could not be empty but could be STALE and it dcreates the same issue! the description is not visible on the customer portal, an agent needs to open the agent view and simply click in and out of the request type field to refresh it! 

Please please fix this, we are spending endless time figuring out how to automate and fix this problem that can be solved by making the description field, like the summary field, a default field! 

Hi all, sorry for the inconvenience here. We realise this is a big problem for users and are absolutely committed to fixing this. That said, we don't currently have a team assigned to this and will have to revisit it again in several months when we review priorities.

We will provide an update once we are able to put a team on this and deliver better news.

Apologies,

Jehan Gonsalkorale

Product Manager, Jira Service Management

Hi, 

We either need the ability to automate setting a default resolution (currently unable to do to API limitations) or we need to ask for a resolution when moving tasks. This completely breaks the customer view without ensure your team is adding a resolution manually. This does not scale. 

Usability bug that causes minutes extra work each day on each ticket but despite that obvious impact I seriously doubt Atlassian will pick it up.

We are using the move feature to convert issues that come in using a workflow that does not require approvals to an issue type that does require approvals; however, the approval notifications are not sending. I am reading here/assuming that this because the request type is null. 

I would to have a recommended workaround for this. 

Any update for this? When the Request type changes, it removes customer visibility to the ticket in the Service Desk portal. I do not understand how you do not see this as a critical bug when customer visibility is concerned.
Also, how does a ticket get marked as "Gathering Interest" 3 years after the ticket is open.  

Hi,

We see this as an essential function. To update the Customer Request Type manually after moving a request just dont make much sense. At least make it default.

In our case we frequently move requests to a different request type, but within the same project. When we do we get the "No match" Customer Request Type. As a consequence the customers cannot see their original posting on the website. Please find a fix for this.

Hello,

I face 3 problems related to Customer Request Types : 

• my project have several workflows, and I have to update the issue type of a ticket, but the target issue type is linked to another workflow. For that I move the ticket from the project to itself, changing the issue type. Result : the request type has 'no match' value.
• I need to move a ticket from a SD project to another. Result : the request type has 'no match' value.
• I need to find all the tickets in this state : no way to detect them.

How can I manage this situation and fix the tickets ? No solution/workaround at this time...

Note : this is not the first time I see these attachments that have nothing to do with the subject.. 

hello, 

seems like the impact by moving issue is loosing the initial form data (in the client interface), could you please fix it?