I haven't gotten any clarity or insight on this from Atlassian support, so wanted to ask here and see what others have done.
Basically, when we setup our Okta integration on Confluence Server years ago, limitations of Confluence and/or Okta forced us to deviate from 1:1 AD/Okta groups to Confluence local groups.
Example:
XYZ Confluence Users is assigned in Okta to the Confluence application and maps to the internal Confluence group xyz-confluence-users.
XYZ Confluence Administrators is the same, but mapped to xyz-confluence-users and xyz-confluence-adminstrators in Confluence. This was because Confluence Service doesn't support SCIM or push groups, so groups could only be assigned at the assignment level and therefore users can only be assigned to a SINGLE AD group. So we had to stack permissions like this. This has worked fine for years, but now that we're forced to the cloud with Atlassian Access, it's super messy.
From our test migration, we now have ALL of the local groups in Confluence Cloud (great!) but also, the actual AD groups are there from Access and of course, because of the naming conventions required by Confluence, can't link to the local groups. So now we have in our groups:
* XYZ Confluence Users
* XYZ Confluence Administrators
* xyz-confluence-users
* xyz-confluence-administrators
The local groups (xyz-confluence-*) have the expected membership because it was all moved with the Migration Assistant, but they of course aren't syncing with the IdP groups from Atlassian Access. So now we have a combination of orphaned local groups that came along for the migration, and the actual AD groups synced from Okta that don't actually map to anything.
With no ability to bulk change site/page permissions (though I could script something with the API, it's going to be a LOT to have it loop through 450+ spaces), how are others dealing with this post-migration?
