URL context parameters in Jira Service Desk not working with JSD customer

In my app descriptor I have a Service Desk action defined as follows:

{
	"serviceDeskPortalRequestViewActions": [{
		"key": "sd-portal-request-view-action-my-action",
		"name": {
			"value": "My action"
		},
		"url": "/sd/portal/request/view/action/dialog/show?issue.key={issue.key}&project.id={project.id}",
		"target": {
			"type": "dialog"
		}
	}]
}

When the action is clicked, it opens the modal dialog specified in the url with context parameters issue.key and project.id.

If the logged in user is a standard Jira user this works as expected. However, if the logged in user is a Jira Service Desk customer the two context parameters are empty.

Is this the expected behaviour or a bug? I would expect the context parameters to be provided they same way as with standard Jira users.

@msamy can you help?

~Yes this is expected. These context parameters are only supported by Jira and should not be used on service desk pages. The service desk context parameters are outlined here: https://developer.atlassian.com/cloud/jira/software/context-parameters/#a-name-additional-parameters-jira-a-jira-context-parameters~

This has indeed been identified as a bug and should be fixed soon.

Thanks for the quick response @msamy. That’s unfortunate. I guess I can work with servicedesk.requestId instead of issue.key as servicedesk.requestId is basically the same as issue.id.
For project.id I will have to introduce an additional REST API call in the backend to fetch the Service Desk request and resolve the project id that way.

Is there any plan to ever support Jira context parameters in Service Desk? I think this would be super useful because there is anyways a 1-1 mapping between these entities:

service desk <=> project
request <=> issue

@msamy just wanted to ask again. Are you sure that this is the expected behaviour? I am asking because I have a Service Desk request view panel defined as follows:

{
    "serviceDeskPortalRequestViewPanels": [
      {
        "key": "sd-portal-request-view-panel-my-panel",
        "url": "/servicedesk/portal/request/view/panel/show?issue.id={issue.id}&project.id={project.id}&project.key={project.key}"
      }
    ]
}

In this case all the parameters get resolved as expected - even for Jira Service Desk customers!

I am wondering why the behaviour here is different from the request view action.

Changing my code to not rely on issue and project context parameters in JSD introduces quite a significant amount of work. With these parameters available, I am able to re-use the same panel and dialog implementation that I also use for the normal Jira issue view. If they are really not meant to be available, I will have to manage two different implementations, one for normal Jira and one for Jira Service Desk.

That’s strange… I’m looking into this more. @tbinna what is the use-case for needing the issue key and project id on a servicedesk request?

Thanks @msamy!

Regarding my use case: Clicking the action opens a modal dialog that when submitted writes data to issue entity properties. I use issue.key to know to which issue to write (here I could also use servicedesk.requestId). project.id is used on my server side to fetch some data from the database.

Basically, the main advantage of having the underlying issue and project properties available is that I can use the exact same code that I also render on the Jira issue view. Not having these values would mean I have to maintain a separate implementation that either in the frontend or the backend resolves servicedesk. serviceDeskId to project.id (because that’s what I store in my database).

I hope this makes sense.

ok I’ve done some more investigation and it looks like this indeed should be working as you expect. I’ve tracked down the problem and created a fix. This should be live soon. Thanks for your patience @tbinna.

1 Like

That’s great to hear :tada: Thanks @msamy!!

Could you please check that this works ok now on your side?

1 Like

Yup, I just tested it and can confirm that it works now. Thanks again for fixing this quickly.

1 Like