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.
Hello everyone,
Is it possible to promptly implement POST version of Bulk get groups?
It’s currently not possible to retrieve group ids for group names that contain special characters via ACSB due to [ACSPRING-150] - Ecosystem Jira
It’s blocking completion of data migration to replace group names with group ids and ACSB team is not very responsive on the issue
1 Like
Hello @TusharAgrawal, @Prashanth_M,
We have a blocker here.
Switching from group names to group IDs will mean (for all apps) that the group data stored by an app need to be converted. Because of the issues that were discussed in ACSPRING-150, some of the group names won’t be converted to groupIDs successfully and this means data loss.
https://ecosystem.atlassian.net/browse/ACSPRING-150
The Atlassian team working on ACSPRING-150 very recently responded to that ticket saying they will be working on a fix in the coming weeks.
I believe group name to ID conversion deadline also needs to be extended until ACSPRING-150 is resolved.
EmreT
Hello @TusharAgrawal @VaradPingale,
We still have multiple blockers which are dependent on solution that could only be implemented by Atlassian.
Hi Everyone,
All blockers for migration to groupID is now resolved.