Adding support for groupID field in Jira REST APIs, expressions types

So to summarize, names are staying as query parameters, and will still be present in responses when a group is retrieved?

G’day @VaradPingale
I’ve noticed a non-coherent behaviour between
POST /rest/api/2/issue/{issueIdOrKey}/comment and
POST /rest/api/2/issue/{issueIdOrKey}/transition

The first endpoint allows the following syntax for the attribute visibility:

visibility {
  type: "group",
  identifier: groupId,

I.e. we can omit value.

When I use the same syntax for the visibility attribute with the second endpoint (in this case inside update.comment[0].add as an example) I get a
400 - Incorrect request: {"comment": "Group level cannot be empty"}
which means the value attribute (holding the group name) remains mandatory.

Are you going to align the behaviour of this second endpoint to that of the first?

Yes @mike1 that is correct.

Hello @VaradPingale,

You know only these endpoints…

  • GET /rest/api/3/group (Deprecated)
  • GET /rest/api/3/group/bulk
  • GET /rest/api/3/group/member

… can be used to get the groupName of a given groupID. Considering Connect apps, all these endpoints require the ADMIN scope.

If my app needs to work with groups, sooner or later it will need to use one of these endpoints so I will be forced to add the ADMIN scope to my app. Why? My app doesn’t need to change anything on Jira. An app can get users by their IDs with just the READ scope. Why does it need the ADMIN scope just to GET groups?

Adding the ADMIN scope requires the customer to manually update the app (which is a pain all by itself) and they will bombard us with questions about why the app needs to be an ADMIN.

As @lexek-92 mentioned earlier, this is a blocker for most of us.

Any guidance?

1 Like