Can't get issue type fields via createmeta REST API endpoint from Connect App (using JWT) auth

Jira Development Jira Cloud
, , , , , ,
1

I’m developing a Jira Connect App. We use the atlassian-connect-express.
We set the scopes to ADMIN in the app descriptor. (initially, we started with READ)

In the Connect App, we want to create issues. In order to do this, we need to get custom fields for the issue types.

According to developer guides and our past experience, we are trying to use the createMeta endpoint.

The issue we are facing is that when we use it with the expand=projects.issuetypes.fields param we always get an empty response. Without the param, it lists all the projects with issue types, but with no fields. We need those fields.

The stage thing is that when we send exactly the same request via REST API (/rest/api/2/issue/createmeta) with the expand param using basic (username, password) auth it works and returns what we need.

In other words:
/rest/api/2/issue/createmeta endpoint behaves differently for different authentication types.
Basic (username, password): returns all projects with issues types and fields
JWT: Returns empty array

The API documentation for this endpoint says that READ scope is enough for Connect Apps.

Thanks in advance!

6 Likes
2

I have the exact same problem. Is there any solution for that?

1 Like
3

Unfortunately I’m facing same isssue

1 Like
4

There’s an ongoing issue right now and it has been reported here: https://community.developer.atlassian.com/t/jira-connect-app-with-admin-scope-has-no-administer-permission/51714

I believe it’s the same issue.

Still no reply from Atlassian.

5

Thanks, @sergio.vieira for your reply and kind support.
I can’t access this issue. I get “Oops! That page doesn’t exist or is private.” when clicking your link.

6

It would also be great to learn if there is an alternative way to get list of fields (especially custom) for each issue type in a given project via REST API.

7

We resolved this. The issue was on our side. The root cause for this was that we were doing the request using an outdated and buggy jira-ruby client version (v.1.7).

Fix was introduced in v.1.7.1 - here is the fix.

We were also able to a get correct response without using a jira-ruby client.

1 Like