• Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • None
    • 26
    • 7
    • We collect Jira Service Desk feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding suggestion.

      Summary

      At the moment, it's possible to create a customer request via REST API as per this page. However, it's not possible to update/edit existing requests

      Suggestion

      Add the ability to update existing requests. This should be able to edit things like Request type

            [JSDSERVER-4609] Ability to update Customer request via REST API

            Gustavo Chaves added a comment - - edited

            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.

            Gustavo Chaves added a comment - - edited 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.

            @Fabio "Kudos to support for providing us with a working interim workaround"

            Care to share that workaround?  Unfortunately I got a flat rejection from Premier Support when I asked about workarounds.

            Richard Cross added a comment - @Fabio "Kudos to support for providing us with a working interim workaround" Care to share that workaround?  Unfortunately I got a flat rejection from Premier Support when I asked about workarounds.

            Richard Cross added a comment - - edited

            +1 - Need to be able to add Approvers to a Service Desk after the ticket is created, i.e via an automation/webhook combination.  

            We can already add participants via REST API... surely adding approvers would be no more difficult to implement?

            Without this, the Approval process in Service Desk is just too restrictive for us to make use of.

             

            Richard Cross added a comment - - edited +1 - Need to be able to add Approvers to a Service Desk after the ticket is created, i.e via an automation/webhook combination.   We can already add participants via REST API... surely adding approvers would be no more difficult to implement? Without this, the Approval process in Service Desk is just too restrictive for us to make use of.  

            +1 - If Inline editing is disabled there is no way to change the Request Type. This is especially problematic if the Issue Type changes, as JSD sets the Request Type to "No Match", which prevents customers from receiving comment notifications/emails.

            Erik Brooks added a comment - +1 - If Inline editing is disabled there is no way to change the Request Type. This is especially problematic if the Issue Type changes, as JSD sets the Request Type to "No Match", which prevents customers from receiving comment notifications/emails.

            @fabio: Can you share the workaround, please?

            Matthias Gaiser [K15t] added a comment - @fabio: Can you share the workaround, please?

            We use the rest api to update issues, and not being able to change the request type is a major hindrance.

            Kudos to support for providing us with a working interim workaround, but it's based on an unpublished api and needs multiple http calls, one to change issue type, another for request type

             

            Fabio Ermotti added a comment - We use the rest api to update issues, and not being able to change the request type is a major hindrance. Kudos to support for providing us with a working interim workaround, but it's based on an unpublished api and needs multiple http calls, one to change issue type, another for request type  

              Unassigned Unassigned
              ywoo Yit Wei
              Votes:
              34 Vote for this issue
              Watchers:
              21 Start watching this issue

                Created:
                Updated: