For more populous orgs it would be great to have a programmatic approach to manage users and group access when utilizing the new user management beta.
I propose introducing new data sources:
spacelift_managed_user - representing our graphQL ManagedUser
spacelift_managed_user_group - representing our graphQL ManagedUserGroup, which is actually an IDP group mapping, so maybe more clear naming can be invented
and resources:
spacelift_managed_user - this might be a bit tricky since we are creating a user while sending an invitation at the same time, so either this is a single resource (see graphQL managedUserInvite mutation); that does conditional re-invitation in the case the managed user didn't accept the invitation yet but his credentials change; or we can create a separate resource for managing invitations (we have an explicit managedUserResendInvite mutation).
spacelift_managed_user_group - this one should be more straightforward, it's a regular CRUD for graphQL ManagedUserGroupIntegration
For more populous orgs it would be great to have a programmatic approach to manage users and group access when utilizing the new user management beta.
I propose introducing new data sources:
spacelift_managed_user
- representing our graphQL ManagedUserspacelift_managed_user_group
- representing our graphQL ManagedUserGroup, which is actually an IDP group mapping, so maybe more clear naming can be inventedand resources:
spacelift_managed_user
- this might be a bit tricky since we are creating a user while sending an invitation at the same time, so either this is a single resource (see graphQLmanagedUserInvite
mutation); that does conditional re-invitation in the case the managed user didn't accept the invitation yet but his credentials change; or we can create a separate resource for managing invitations (we have an explicitmanagedUserResendInvite
mutation).spacelift_managed_user_group
- this one should be more straightforward, it's a regular CRUD for graphQLManagedUserGroupIntegration