I also would very much like to know about the workaround, but I'm afraid it may not work anymore after four years...
I guess that it may be very hard to implement this feature in its most general form, i.e., allowing one to change the Customer Request Type (CRT) of an issue to any of the CRTs defined in the ServiceDesk. Even using Jira's web interface, one can only change directly the field's value to other CRTs associated with the same Issue Type. In order to change it to another CRT associated with another Issue Type one has to use the "move" option in the Issues menu, going through a sequence of stages.
So, I'd like to propose an effort be made to first allow one to change the CRT via the REST API, restricted to the set of CRTs associated with the current issue's Issue Type. This should be much easier to implement (since it's already possible to do via the web interface) and it would go a long way to solve the whole problem.
I've read elsewhere people suggesting that it's already possible to specify the CRT when one creates the request via the REST API. This is good, but doesn't solve all problems. My current business case for this feature is this: We use JSD as an IT help desk portal. In it people can open different kinds of request, such as a "Service Request" and an "Incident". However, we've noticed that a significant number of Service Requests should have been created as Incidents. Some are wrongly created by user error and others are created as Service Request because it's the default CRT for requests created by email. So, we've developed a simple AI service which is invoked by a Jira webhook whenever a new request is created. It analyses the request content and is able to tell with very good accuracy (based on a few years of learning) when a Service Request is an Incident in disguise. Currently it simply adds a label to the request so that we can monitor it with a filter subscription and change the CRT by hand on Jira's web interface. We're detecting about five such cases per day, which leads to problems regarding SLA calculation and prioritization errors. It would be awesome if our agent could change the CRT automatically.
I also would very much like to know about the workaround, but I'm afraid it may not work anymore after four years...
I guess that it may be very hard to implement this feature in its most general form, i.e., allowing one to change the Customer Request Type (CRT) of an issue to any of the CRTs defined in the ServiceDesk. Even using Jira's web interface, one can only change directly the field's value to other CRTs associated with the same Issue Type. In order to change it to another CRT associated with another Issue Type one has to use the "move" option in the Issues menu, going through a sequence of stages.
So, I'd like to propose an effort be made to first allow one to change the CRT via the REST API, restricted to the set of CRTs associated with the current issue's Issue Type. This should be much easier to implement (since it's already possible to do via the web interface) and it would go a long way to solve the whole problem.
I've read elsewhere people suggesting that it's already possible to specify the CRT when one creates the request via the REST API. This is good, but doesn't solve all problems. My current business case for this feature is this: We use JSD as an IT help desk portal. In it people can open different kinds of request, such as a "Service Request" and an "Incident". However, we've noticed that a significant number of Service Requests should have been created as Incidents. Some are wrongly created by user error and others are created as Service Request because it's the default CRT for requests created by email. So, we've developed a simple AI service which is invoked by a Jira webhook whenever a new request is created. It analyses the request content and is able to tell with very good accuracy (based on a few years of learning) when a Service Request is an Incident in disguise. Currently it simply adds a label to the request so that we can monitor it with a filter subscription and change the CRT by hand on Jira's web interface. We're detecting about five such cases per day, which leads to problems regarding SLA calculation and prioritization errors. It would be awesome if our agent could change the CRT automatically.