-
Notifications
You must be signed in to change notification settings - Fork 219
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
Team: Support org_id
attribute
#979
Conversation
In order to lower resource usage and have a faster runtime, PRs will not run Cloud tests automatically. To do so, a Grafana Labs employee must promote the Drone build. For maintainers, it's better to run only the Cloud tests you need, rather than all of them. You can do so by setting the following parameter when promoting:
|
3733a2b
to
aafcca0
Compare
e440dae
to
e87729c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good to me, but I have one question that I'd like to understand before moving on.
@@ -50,6 +51,12 @@ func ResourceDashboardPermission() *schema.Resource { | |||
Type: schema.TypeSet, | |||
Required: true, | |||
Description: "The permission items to add/update. Items that are omitted from the list will be removed.", | |||
// Ignore the org ID of the team when hashing. It works with or without it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it works with or without it, why ignoring it then? Not sure I follow 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be explained better in the comment. The reason why the org ID can be ignored is that resources that refer to each other have to be in the same org anyways (except global resources like a user). So if you specify a team that is not within the same org as the permissions, the API will fail.
And the reason why it HAS to be ignored with the set function is that 1:1
(AKA: team 1 in org 1) is functionally equivalent to team 1
(that is team 1
in an unspecified org). Lots of this is due to migration, and can definitely be improved once we deprecate the global org setting. At that point, all of the team IDs should always have the org ID in them and we can stop doing weird exceptions like this
6530b87
to
0fd8b11
Compare
Closes #747 Final resource to receive the `org_id` Allows a team to be created and managed in a separate organization without needing two provider blocks Also adds tests that a team can be created and managed in an org Note: `*_permissions` are a bit messy. I'm planning on refactoring them into blocks for their respective resources, so I'm not going to clean them up too much right now.
0fd8b11
to
25c5578
Compare
Closes #747
Final resource to receive the
org_id
Allows a team to be created and managed in a separate organization without needing two provider blocks
Also adds tests that a team can be created and managed in an org
Note:
*_permissions
are a bit messy. I'm planning on refactoring them afterwards, they mostly follow the same pattern so it should be possible to make them much nicer