Issue Summary

As presented on https://jira.atlassian.com/browse/JSDCLOUD-5901:

When an issue type is changed on a ticket, it will break the request type mapping and the request type field will be displayed as No match. However, if the ticket is viewed in the issue navigator list view, the request type field shows the previous request type value so searching for request type null/empty would not return a value.

Which resulted on:

As the original Request Type is still stored on the Issue (despite the Issue Type and Request Type not matching), we have changed the behaviour so that the original Request Type will now show on the Issue View (as it does in Filters & Queues).

On Issue View, we have highlighted that the Request Type is Invalid so that users can select a valid Request Type for that Issue Type - this will then update the Request Type value on the Issue, and the new value will show in all views (Queues, Issue View, etc).

However, providing a value to the Request Type field is not required (JSDCLOUD-8406), so if no Agent fixes the value, then any Workflow validators that would verify if this field was not populated won't work. This occurs when changing the issue type directly or moving issues to own/other projects.

Steps to Reproduce

1. Create a ticket via the customer portal. Make sure the request type is valid.
2. Change the issue type of the ticket OR move the request into another Project
3. Do not pick a new value to the "Request Type" field
4. Use any transition associated with the issue that has a Validator for "Request Type" field (Field Required Validator)

Expected Results

Transition would fail with the associated error message on the Validator

Actual Results

Issue status transition occurs even with "Request Type" presents an invalid value

Workaround

Multiple workaround options are available:

• Use Automation to set Customer Request Type When Issue is Moved or Created via Jira.
• Configure Default Request Types for your Issue Types.
• If by any reason a static Request Type value cannot be set by the above options (e.g. JSM Agents must decide the appropriate one for each issue), then it will be necessary to set a Value Field Condition instead of a Validator. That way, the transition will NOT be available, unless one of the matching Request Types is set.

Theres a caveat to the third option above, due to the bug JRACLOUD-79309 the solution shared on Using Customer Request Type in a Workflow Condition must be used, where a portalKey and Key pair for EACH request type is used as condition:

1. Get issue ID (not key) by hovering over the "move","convert to subtask", or other ption from the ".." dropdown.
2. Use the ID on the following endpoint this to the endpoint:

   https://<siteName>.atlassian.net/rest/servicedesk/1/servicedesk/request/<issueID>/request-types

   ^{Update <siteName> and <issueID> accordingly}

1. The response will contain several entries, one for each request type, look for this information:

   {
   [...]
         "id": 15,
         "cvId": 1,
         "portalKey": "itsm",
         "portalId": 1,
         "key": "newhires",
   [...]
       }
   

1. Note the "portalKey" and "key" pair values in the response, there will be one set FOR EACH Request Type available on the project.
2. Combine those in as `<portalKey>/<key>` in the workflow "Value Field" condition, using "Option ID" and you need to perform this to all possible request types available:
   
3. Ensure that you pick "Any of the Following Condition" on the Condition list:
   

This should now only allow a issue to transition into the given status if any of the valid Request Type values are associated.