TF-5568 add support for project custom permissions

[rberecka]

Description

Add ability to choose custom access for team projects. Once selected, users can then choose to set a variety of customizable permissions to different levels of access. For example, if I add a team project and set the TeamProjectAccessAddOptions to include access: "custom" I can then also configure different permissions that will apply to either the project itself (project-access) or all workspace in the project (workspace-access).

Authored with @jbonhag

Testing plan

Pull down locally
Run tests below and comment out the skipUnlessBeta(t) flag. Once we have roll out the feature to TFE and remove the feature flag, we'll remove these skips as well.

External links

Output from tests

If you run atlas locally you can run the tests with the ENABLE_BETA=1 environment variable.

$ ENABLE_BETA=1 TFE_ADDRESS=http://localhost:21080/ TFE_TOKEN=<API TOKEN> go test -run TestTeamProjectAccessesAdd
$ ENABLE_BETA=1 TFE_ADDRESS=http://localhost:21080/ TFE_TOKEN=<API TOKEN> go test -run TestTeamProjectAccessesUpdate
...

[jbonhag]

Amazing @rberecka!

[jbonhag]

Just a couple of observations related to the name changes, but this looks really good.

[jbonhag]

🎉

[laurenolivia]

@rberecka Great work on this PR ✨

I noticed there is a TeamProjectAccess struct, and a TeamProjectAccesses interface. The naming is almost identical and I'm wondering if it's too late to propose something like a TeamProjectAccessMethods (interface) instead? Especially considering the commented line above the interface reads:

// TeamProjectAccesses describes all the team project access related methods that the Terraform
// Enterprise API supports

Not to mention this is customer-facing. What do you think? How can I support?

[sebasslash]

Unfortunately given go-tfe's v1.0 nature and this interface being exported, we can't rename TeamProjectAccesses to something slightly less confusing. Thankfully from a client perspective you call client.TeamProjectAccess where the naming makes more sense.

[laurenolivia]

Unfortunately given go-tfe's v1.0 nature and this interface being exported, we can't rename TeamProjectAccesses to something slightly less confusing. Thankfully from a client perspective you call client.TeamProjectAccess where the naming makes more sense.

This would be a breaking change for v1.0 but what are your thoughts for v2.0? Or is it not worth it at that point? @sebasslash

[sebasslash]

I think over time if we can identify multiple quirks with our naming conventions as well as other potentially breaking changes that would improve the DX, we can build a good case for a v2.0.

For the time being, v2.0 in go-tfe is in the way distant future.

[laurenolivia]

I think over time if we can identify multiple quirks with our naming conventions as well as other potentially breaking changes that would improve the DX, we can build a good case for a v2.0.

For the time being, v2.0 in go-tfe is in the way distant future.

Fair! Thanks for weighing-in @sebasslash
@rberecka nvm! 👍

[sebasslash]

Awesome work 🔥 ! My comments are mostly regarding code organization and testing

[sebasslash]

This PR has my approval pending the naming changes to scope these permission structs to the parent resource TeamProjectAccess. Awesome work @rberecka !!

I ran the tests locally ✅

[sebasslash]

Approved 🚀

[laurenolivia]

nit: can we capitalize here

[github-actions]

Reminder to the contributor that merged this PR: if your changes have added important functionality or fixed a relevant bug, open a follow-up PR to update CHANGELOG.md with a note on your changes.