Hi @david2
After our conversation, I checked with the team owning the JCMA mappings. They confirmed that the table is mapping server-side group name to Cloud group ID. So no rework will be required from your side to convert group names to groupIDs.
Hello everyone,
It’s almost a month until the deadline, but the bulk API permission issue is still not addressed, which is a blocker for many people to implement group id support and perform data migrations
https://jira.atlassian.com/browse/JRACLOUD-79363
1 Like
@VaradPingale I am working on migrating to group IDs and I’ve encountered issue with the entity_property_contains_any_user_group Connect condition. It doesn’t work for me if I put group ids into entity property, but works with group names.
What is the migration path for this condition? I hoped that Connect will support both group names and group ids until February 28th, but this seems to not be the case.
1 Like
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?
Cheers
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
We are using addon_property_contains_any_user_group condition:
{
"condition": "addon_property_contains_any_user_group",
"params": {
"propertyKey": "create-from-template-button-access"
}
}
Will it still work with group names?
I don’t see any changes in documentation: https://developer.atlassian.com/cloud/jira/platform/connect-conditions/#predefined-conditions
1 Like
We are also using the addon_property_contains_any_user_group as well. What is the approach that Atlassian recommends to replace that entity property condition?
Hey @maciej.dudziak yes, connect conditions will continue to support group names along with ids. Similar to project roles(https://developer.atlassian.com/cloud/jira/platform/connect-conditions/#entity_property_contains_any_user_role-condition), one can define group property to be a list of group names and ids. There is no change in the input format.
1 Like
G’day Atlassian Developer community!
We have decided the extend the deadline for the deprecation of Ecosystem APIs which use group-name as an identifier. The decision is based on the concerns raised by the developer community regarding the adoption of group-id. We are committed to completely resolving all concerns raised by our partners. Therefore, we have decided to extend the deadline for Ecosystem API deprecation by 2 months. The new deadline is April 30, 2023 . However, we request the community to continue adopting group-id, so that we can uncover and resolve any new concerns. We have updated the post with the latest information.
Best,
Prashanth
Jira Cloud PM
Hi @lexek-92 , thanks for reporting this. The permission issue is now fixed. From now on, READ access should be sufficient to call the GET Bulk Groups endpoint.
Hello @emre.toptanci , The permission issue is now fixed. From now on, READ access should be sufficient to call the GET Bulk Groups endpoint - rest/api/3/group/bulk.
Also, /rest/api/3/group is now deprecated in favour of /rest/api/3/group/member. Since the member API will continue to work with the group name, do you believe this is an issue?
Hi @GianlucaLaBruscoAppf , Thanks for flagging this. There was indeed a bug around the transition API and we’ve recently released a fix for it. Could you please check again if the error still persists?
Hello @TusharAgrawal,
Great to hear that /group/bulk endpoint now can be used with just the READ scope.
I feel that the same is needed for /group/member endpoint. I is still documented to require the ADMIN scope.
I mean (thanks to your latest change to /group/bulk endpoint) we can now get the groups with just the READ scope. Also, we can get users and their groups with just the READ scope, using the /user endpoint. It makes sense if we could get user/group membership info (via /group/member endpoint) also with just the READ scope.
Hi @MateuszZielinski yes, connect conditions will continue to support group names along with ids. Similar to project roles, one can define group property to be a list of group names and ids.
If this is still not working for you, please let us know.
Hi @TusharAgrawal, g’day
No worries and thanks for the prompt fix. It is now working as expected.
Cheers
CC: @VaradPingale, @david2, @ajay1
@TusharAgrawal @Prashanth_M, with the change to group ID, what field value are we supposed to provide to the openCreateIssueDialog to pre-populate group picker fields?
So far, this was
<custom field ID>: <group name>
If I change this to
<custom field ID>: <group ID>
the create issue dialog renders as follows
… and issue creation fails on “Create”.
1 Like
Hi @hannes-finesoftware, There is no change in any of the Connect JS APIs regarding the group picker custom fields. You can continue to use group names for these fields.