Hi @jjohn ,
/rest/api/space/SPACEKEY?expand=permissions still doesn’t support groupId in the response. Will this be supported before the deprecation? Thanks!
Hi @jjohn ,
Jira and Confluence are doing this work separately and this change has not been planned for Jira yet so I unfortunately cannot give you a timeline for when to expect it.
Yes, it will be supported before the deprecation but we are currently blocked on some work that we need to do before we can include groupId in the response, we are hoping to get unblocked sometime in January.
moving to groupIds is a great step in the development. Is it also in your scope to use the id’s in the experimental apis, namely adding new permissions to groups via id?
Could you tell us if the experimental change are also included in the January patch? In the trello board someone has talked about updates being made in September and we haven’t gotten an update since then)
Is there a specific API you are asking about? We are almost done with adding the
groupId endpoints and I’m trying to confirm we have everything (we are still working on a few / rolling them out).
When group names become mutable does this also apply to the Confluence built-in special groups like ‘administrators’ and ‘confluence-users’? If so, will there be an API to get the ID of these groups?
How does this work with the
Will this check on both group name and group id, or something else?
I’m currently matching this on group name, but will this change?
I noticed that the group ID is not returned in the
permissions space expansion or the
restrictions content expansion. It’s not a blocker for us, but it would be nice to have it there so that we can rely on a consistent data model in our code.
any update on the inclusion of the group id in expands (e.g.
/rest/api/content/1376322144?expand=restrictions.update.restrictions.group)? January was promised, now we are in April…
Hey @jjohn, any news on all these questions?
The deprecation date of May 17, 2021 is coming really fast now.
sorry i’m on vacation (thus the lack of response), i will give more details when i get back but know that the deprecation date is not May 2021, it will be 6 months from when we finish all the work (hopefully sometime in May).
yes, the plan is to check for groupName and/or groupId - unfortunately we are waiting to get unblocked to implement this change.
sorry for the delay, we were only able to get unblocked 2 weeks ago, we are in the process of rolling out a series of changes that are necessary before this update
I am working on this now, will let you know once we have something concrete
@jjohn We don’t add/remove users from groups currently.
What we do currently is to allow a user to pick another user for a task. By default we look into the group confluence-users to allow to pick another user.
That means that our app relies on the default group name to find the default users (as long as an admin has done no configuration).
Now if Confluence Cloud had a user picker, that would help us a lot.
@jjohn we don’t have to add or remove users from these groups. Our app is creating a page and restricts access to it so that every user is allowed to read but only admins are allowed to update it. For that we use the group “administrators” to restrict write access. All this happens more or less automatically in the background which means we cannot ask a user to select the group to assign.
So we are assuming that the default group for administrative access exists and is named “administrators”.
Let me add to @RonnyWinkler : we by default check the groups named
site-admins , and
@RonnyWinkler @marc pls see Get Groups API enhanced to support group lookups based on access type for APIs to use instead of hardcoded groupnames - let me know if you have any concerns.