Jira Service Desk Cloud next-gen projects and Connect apps

JSM Development JSM Cloud
,
1

TL;DR - The Jira Service Desk Cloud team has found common problems in marketplace apps

  • The Jira Service Desk Cloud team has found common problems in marketplace apps and would like to share them and solutions so marketplace apps can address them.
  • If you need more information on the impact on developing for Jira Service Desk, please read this blog, and for Jira, please read this blog.

Jira Service Desk Cloud introduced next-gen projects in Feb 2019, which support installing marketplace apps. Some marketplace apps functionality is degraded when working with next-gen projects. The Jira Service Desk Cloud team has found common problems in marketplace apps and would like to share them and potential ways to address each.

Common problems

Project scoped entities

Next-gen projects introduced the concept of project scoped entities. The entities that are project scoped entities in next-gen projects are:

  • Jira Platform
    • Project roles
    • Screens
    • Workflows
    • Fields
    • Issue Types
    • Status
  • Jira Service Desk
    • Request Types
    • Request Type Fields
    • Request Type Groups

A lot of marketplace apps are exposing some or all of these project scoped entities outside of their project scope.

Marketplace apps usually break project scope in one of two ways:

  • The marketplace app lists project scoped entities outside of the project they are scoped to
  • The marketplace app attempts to perform an action on a project scoped entity outside of the project it is scoped

Marketplace apps should update any lists of project scoped entities they are displaying to be filtered by the project they are scoped to e.g.

  • If a next-gen project is selected from a projects dropdown, then all other dropdowns should only include entities scoped to that project.

Creating requests

Some marketplace apps have the functionality to create requests. Requests are failing to be creating though due to problems with mappings to the Request types fields. Request types are now project scoped and as such, have project scoped fields. If fields are required and the create request call doesn’t include them, the call will fail.

Additionally, some marketplace apps are failing to render request create forms due to not having mappings for all custom field types.

The recommended way to get request types and their fields is to use the following REST APIs

Links

Some marketplace apps have links that can be updated to account for next-gen settings locations e.g.

  • Links to create, update or delete Request and Issue types should both now go to {baseUrl}/projects/{projectId}/settings/issuetypes

Documentation

Some marketplace apps have documentation that needs to be updated to account for next-gen mental models, permission, and settings locations e.g.

  • Marketplace apps that have a configuration screen in project settings will need to update the reference to that location to be Project settings → Apps → <configuration-page> .
  • Marketplace apps that require users update Portal , Widget or Email settings will need to update the reference to their location to be Project settings → Channels → Portal/Widget/Email .

Jira Service Desk features missing in classic

Some Jira Service Desk Cloud features have not been ported yet from classic to next-gen.

  • Language support
  • Approvals
  • Asset management
  • Customer transitions
  • Custom field types
    • Time tracking
    • Cascading select

We are currently working on porting these classic features to next-gen, and the solution is to wait or display a notification to customers from inside app views that those features are not currently available in next-gen projects.

2

Hi @shwa,

We have noticed that you can’t move fields: Description and Attachements to Internal Fields in Request Type configuration. What is the reason behind this?

In classic project our app displays Dynamic Form on Customer portal, to make it work, fields are displayed by our app ( to avoid duplication, those fields need to be removed from request type, but still need to be added to create screen). In classic project the only field that was required to be left in request type config was Summary.

3

G’day @maciej.dudziak,

The reason you can’t move the description and attachments fields to the internal fields bucket is they cannot be displayed in the sidebar on the agent view.

The Customer portal fields category is only for fields that can be:

  • Displayed on the portal
  • Displayed in the content section of the agent view

The Internal fields category is for fields that can be:

  • Hidden from the portal
  • Displayed in the sidebar on the agent view

In next-gen projects all request types require the summary field and additionally the Email request request type requires the description and summary fields.

Therefore, you can remove the description and attachments fields so they won’t be displayed on the customer portal, however, they then will not display on the agent view either. Therefore, if you implement them for the custom portal you will also need to implement them for the agent view.

Let me know if this answers your question and thanks a lot for asking and for being interested in making your app as great as possible with next-gen.

Cheers,

Joshua

4

Thanks for this update and highlighting these points @shwa. I have a question related to this.

We have an integration (via new OAuth 3LO) to Jira that allows users to create issues from a remote system. In that integration, the user selects a project (incl. JSD projects) and then picks an issue type based on the project selection.
Overall this has been working well so far, however, we have a customer for which it seems the API request to fetch issue types (for a JSD project via Jira platform API v2) returns 200 but does not actually return any issue types. After reading this

Request Types are backed by Issue Types in next-gen projects and can now be retrieved and modified using the Jira platform REST API Issue Type endpoints. (source)

I am wondering if this was not already the case before next-gen projects? Is our assumption wrong? Cloud the empty 200 response to fetch issues types for a JSD project be related to this?

Until now we did not manage to replicate the behavior the customer is seeing.

5

G’day @tbinna,

Which endpoint are you using? If you’re using the get all issue types for user endpoint it may be returning an empty list with a 200 because of permissions.

Permissions required: Issue types are only returned as follows:

  • if the user has the Administer Jira global permission, all issue types are returned.
  • if the user has the Browse projects project permission for one or more projects, the issue types associated with the projects the user has permission to browse are returned.

It may be better to use the get project endpoint with the expand issueTypes query parameter and will work well with next-gen projects.

6

I am using GET /rest/api/2/issue/createmeta?projectIds={projectId}. After the user has selected a project in the UI we fetch the issues types for that project using /issue/createmeta?projectIds={projectId}. I understand that this could return an empty response as highlighted in the docs:

Note that invalid project, issue type, or project and issue type combinations do not generate errors.

However, if it’s a permission issue I’d expect a 403 or similar, the empty 200 response is like a fail silent behavior.

We could change this to use the “get project” endpoint if that makes a difference - but from what I understand it shouldn’t, right? The Browse projects permission still applies.

7

Hey @tbinna,

You’re right it doesn’t look like permission issues.

Since you are using the same method for retrieving the projects as the issue types you could just pass expand=projects.issuetypes to the createmeta endpoint to get the project and the issue types in the first call and not have to make a subsequent call. You can even use expand=projects.issuetypes.fields to get all the fields since I assume you’ll need them if you’re creating a request.

8

@shwa you are exactly right but I am not sure if this will solve the actual problem. It may just expose the same issue when the user tries to select a project. I will try to get some more details from the customer regarding this issue, but so far the 200 response just doesn’t look right to me.