Are service desk APIs meant to disallow portal/customer users from accessing them?



Jira Service Desk for Server provides Java APIs that list available service desks and the request types on them. These APIs take an ApplicationUser object and perform a security check to confirm that the user is allowed to access the service desk etc.

As far as I can tell, none of those APIs work for customers — ie portal-only users. The APIs respond with data when accessed by a normal Jira user, but not customers. This doesn’t make sense to me: customers can use the JSD portal website just fine… but the APIs refuse to provide the service desks and request types those same customers see in the portal.

This code demonstrates the problem:

  public Response getTest(@PathParam("serviceDeskId") int serviceDeskId, @PathParam("requestTypeId") int requestTypeId) {

    ApplicationUser user = jiraAuthenticationContext.getLoggedInUser();
    String userKey = user.getKey();

      serviceDeskService.getServiceDeskById(user, serviceDeskId).fold(
          (error) -> userKey + " getServiceDeskById error: " + error.getMessage(),
          (serviceDesk) -> userKey + " getServiceDeskById OK: " + serviceDesk.getProjectName()

      portalService.getPortalForId(user, 1).fold(
          (error) -> userKey + " getPortalForId error: " + error.getMessage(),
          (portal) -> userKey + " getPortalForId OK: " + portal.getName()

    RequestTypeQuery requestTypeQuery = requestTypeService.newQueryBuilder().serviceDesk(serviceDeskId).requestType(requestTypeId).build();
      requestTypeService.getRequestTypes(user, requestTypeQuery).fold(
          (error) -> userKey + " getRequestTypes error: " + error.getMessage(),
          (requestTypes) -> userKey + " getRequestTypes OK: " + requestTypes.size() + " request types"

      serviceDeskService.getServiceDesks(user, new SimplePagedRequest(0, 100)).fold(
          (error) -> userKey + " getServiceDesks error: " + error.getMessage(),
          (serviceDesks) -> userKey + " getServiceDesks OK: " + serviceDesks.size() + " service desks"

    return Response.ok("Done").build();

That code should load a service desk, a portal, and a request type, then log the results. It works fine for administrators and Jira agents, resulting in logs like this:

admin getServiceDeskById OK: Test Desk
admin getPortalForId OK: Test Desk
admin getRequestTypes OK: 1 request types
admin getServiceDesks OK: 2 service desks

But for a customer who only has portal access, the logs are: getServiceDeskById error: sd.agent.servicedesk.error.project.nopermission : 'You don't have permission to access this Service Desk.' getPortalForId error: sd.portal.error.permission : 'You do not have permission to view this Portal.' getRequestTypes error: sd.agent.servicedesk.error.project.nopermission : 'You don't have permission to access this Service Desk.' getServiceDesks OK: 0 service desks

The API is telling us that the customer cannot access that service desk, or indeed any service desks at all.

So my questions are:

  • Is this a bug?
    It seems wrong that APIs refuse permission to customers, because it is all information they can see in the portal. But perhaps it is deliberate? I have seen some bugs raised on this, such as JSDECO-80 and this question, but there has been no indication from Atlassian whether it considered a bug or not.

  • How are we meant to access the APIs for customers?
    Is there some other way we are meant to retrieve this data for customers? We could possibly use the ServiceDeskManager class which doesn’t take a user or perform a security check, but then how do we make sure the customer is authorised to view the service desk? ServiceDeskPermissionService doesn’t have any suitable methods to let us perform that security check ourselves.

Note that I tested this in several versions of Jira Service Desk (3.3.0, 3.5.0, 3.7.0 and 3.9.0) and found they all have the same behaviour.


Hi Charlie,

Permissions with JSD customers are a confusing thing, there is not much in the way of documentation, some actions are just refused by default for customers due to permission checks.

Have you tried executing your code via the CustomerContextService?

I ran into a similar problem yesterday whilst trying to use the IssueService as a portal user, and have seen similar problems when interacting with the JSD API’s. I think the Service Desk Customer - Portal Only permission only applies when executed in the customer context.

Do any Atlassian’s have some tips on how we should be performing actions as JSD Customers? Is the CustomerContextService the correct service to be using?


Thanks @reece, it looks like CustomerContextService is exactly what I need!

I just ran the example code above inside a customerContextService.runInCustomerContext() call and found those API calls now work. The logs for a portal-only user are now: getServiceDeskById OK: Test Desk getPortalForId OK: Test Desk getRequestTypes OK: 1 request types getServiceDesks OK: 2 service desks

So my guess is that this behaviour isn’t a bug, but we’re probably expected to use CustomerContextService whenever calling an API as a customer?

I am concerned that I’d never heard of this until now. I just searched the Atlassian Developer site and the only mention of CustomerContextService is in the Jira 7.6 upgrade notes… and nothing explaining that we should use CustomerContextService, or when and how to use it. The documentation for Jira Service Desk Server is very limited overall, but this in particular seems like an important omission.

Are there any Atlassians here who can update that documentation?


Glad to hear you made some progress Charlie. I too would like to see some confirmation from Atlassian that this is actually the correct approach to use when dealing with portal only users.

As far as I can see this is not documented anywhere to clearly indicate that this is the correct approach to use, I only stumbled across it after browsing the JSD API Javadoc.

Working with JSD is time consuming and frustrating, often things do not work as you would expect them to in any other area of Jira. I think some of the frustration could be alleviated if we actually had access to the JSD source code: JSDSERVER-397