Names of Groups no longer immutable after March 27, 2022

What is changing?

Confluence Cloud is moving away from groupName towards groupId as the unique identifier for Groups . See Updates to Group REST APIs and Group Webhook Events for more details and Get Groups API enhanced to support group lookups based on access type for new APIs to get groups based on their roles.

Confluence Cloud is officially starting the 6 month deprecation period. At the end of the 6 months deprecation period, ie, Mar 27, 2022, groupNames will no longer be immutable.

What do I need to do?

  1. Determine if your team is impacted and needs to make the switch to use the new field groupId instead of groupName .
  2. Make the changes in the next 6 months.

By when do I need to do it?

Mar 27, 2022

REST APIs with groupName will still be available for use but groupName will no longer be immutable after this date.

4 Likes

is this planned for Jira Cloud as well?

2 Likes

Very good question. Right now there doesn’t seem to be a concept of groupId in Jira.

Also, if group name is no longer immutable, do the connect conditions that are currently based upon group names also magically start working with groupIds too?? — I think there may be a Jira issue for that somewhere.

I have seen groupId in some Jira Rest Endpoints recently and wondered, that it does not exist consistently in all REST Endpoints … So something might already going on on behind the scenes :slight_smile:

Hi @jjohn

There seems to be a bug with one of the new Confluence group APIs not being available in the expected scope. I saw this on Forge (Custom UI) but it’s presumably an issue for OAuth too.

In particular, I am getting HTTP 401 when requesting a group by ID, but a regular HTTP 200 when requesting a group by name, all from the same session.

The original get-group-by-name API indicates that the required scope is read:confluence-groups, which the app has.

The new get-group-by-ID API does not list any scopes at all in the documentation. Even though the app already has read:confluence-groups scope as mentioned above, requests to this endpoint return:

{"code":401,"message":"Unauthorized; scope does not match"}

I assume the docs are automatically generated from code, so perhaps the absence of a scope listed there points to a deeper problem? Or is a separate scope needed? (It works fine on Connect.)

1 Like

@jjohn

Also, as @david already asked, what is the migration path for the “space_property_contains_any_user_group” Connect condition? Although we have both group names and IDs stored in entity properties, used to conditionally display content, I don’t see any condition that uses group IDs.

Is there a new condition that is simply not yet documented, or will the existing condition work with group IDs? Or is there a gap in the migration strategy?

Scott

3 Likes

Thanks for reporting this @scott.dudley , I will get someone to look into it

Hey @david connect conditions should now work for groupNames and/or groupIds

1 Like

Hi @jjohn – thank you. I pinged the Forge forum earlier this week, and @XavierCaron mentioned that they too were trying to escalate (What scopes are required to fetch a Confluence group by ID? - #2 by XavierCaron).

I can also confirm that the existing Connect conditions work with group IDs. Thanks!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.