-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Resource: User Group Memberships #416
New Resource: User Group Memberships #416
Conversation
|
|
Hi, @ymylei! Thanks for submitting this PR. Do you think it's worth deprecating the |
I don't think it would be a good idea yet, as long as this resource is able to be used at scale decently, and then we create a "reversed" version where the group is the primary key, at that point I think it would be safe to deprecate since we'd have a way to replace the relationships efficiently for either design choice. But we should probably let this and the other "bed in" for a bit and iron out any bugs that the normal terraform testing / small scale usage will find difficult to uncover. |
…do unnecessary existance checks
Updated acceptance test after my fiddling with the resource checks:
|
In an effort to correct some of the mistakes posed by the use of the resource
okta_group_membership
(#252), I'm creating/proposing this newokta_user_group_memberships
resource.This is basically a clone of
okta_group_membership
, however the read functionality and handling is modified so the groups are handled in bulk on a per user basis. This allows for significant reduction in API calls during theREAD
phase (and create phase) when doing the validation of memberships of groups. This is because the standard API endpoints for users will allow you to get all groups, so it's better due to the API limits imposed to compute as much as we can IMO.