fix bug with data access iam member #2397
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* fix bug with data access iam member * update to still allow iam_member if prefix is not in map * update to add special groups without prefixes to map * updates post create rather than using customize diff * clean up map * undo unnecessary changes to nested_query * add comment Signed-off-by: Modular Magician <magic-modules@google.com>
ghost
added
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes hashicorp/terraform-provider-google#6754
The issue is the
iam_memberfield will translate intouser_by_email,group_by_email,domainorspecial_group. The difference with these fields is thatiam_memberaccepts a string formatted asprefix:value, whereas the other fields don't accept a string with the prefix. However, the backend will use the prefix ofiam_memberto translate the value into one of those fields and send that back in the response.I change the request based on what I believe the response will be anyway, it's an assumption that the backend logic is the same. I would prefer to analyze the response instead, but couldn't figure out a good way to do that. Please let me know if there's a better way to address this issue.
Release Note Template for Downstream PRs (will be copied)
Derived from GoogleCloudPlatform/magic-modules#3741