It would be nice if we could access users' groups in Terraform (as a data source?) since customers like to use generalized templates with team-specific options.

It would be nice if we could access users' groups in Terraform (as a data source?) since customers like to use generalized templates with team-specific options.

It will be soon be possible to get a user's groups with data.coder_workspace_owner.me.groups having a list of all available groups would make the UX more useful.

A good candidate for a feature request for https://github.com/coder/terraform-provider-coder

@matifali Interesting. I'll open a different issue there since this may impact shared ports as well.

Do you envision that enabling this flow? Some conditional to check that the group matches?

resource "coder_app" "code-server" {
  agent_id     = coder_agent.dev.id
  slug         = "code-server"
  ...
  count = contains(data.coder_workspace_owner.me.groups, "data-sci") ? 1 : 0
  share        = "authenticated"
}

If we could just pass the group name/id to the share attribute this would be extremely smooth. TBF this may be a more limiting abstraction.

resource "coder_app" "code-server" {
  agent_id     = coder_agent.dev.id
  slug         = "code-server"
  ...
  share        = "group"
  group        = "data-sci" # or group id
}

@stirby I think a better way would be to be able to set share = owner|username|groupname|authenticated|public.

resource "coder_app" "code-server" {
  agent_id = coder_agent.dev.id
  slug     = "code-server"
  ...
  share    = "owner|matifali|data-sci|authenticated|public"
}

Setting share =

1. owner --> default only workspace owner
2. matiafli --> share with user matifali
3. data-sci --> shate with group data-sci
4. authenticated --> share with all coder users in current organization
5. public --> share with anyone on the network

This is increasing the share level as we move from owner to public

BONUS: If this can be done from the dashboard share-ports UI too.

I don't think that kind of string abuse is a good idea. In the | separator suggestion, a group named "public" or "owner" could not be selected. A user might try to target a group named "public" and unknowingly make their shared URL public to the internet.

Also, we have tended to represent RBAC state in the DB as opposed to in Terraform. There are good reasons to do this consistently, e.g. when a Group is deleted or renamed we don't want Templates to fail.

Instead, I propose we add another share-level in between "owner" and "authenticated": "template". When a URL is shared to the "template", anyone that can use the template can also visit the URL.

| is not a separator here but just showing all mutually exclusive possible values for share. I agree that a change in group name can break the template.
Using a new share level named inherited or template sounds a better approach.

I don't think that kind of string abuse is a good idea. In the | separator suggestion, a group named "public" or "owner" could not be selected. A user might try to target a group named "public" and unknowingly make their shared URL public to the internet.

I was thinking about supporting group/user names/IDs directly but stopped because of this exact collision.

Instead, I propose we add another share-level in between "owner" and "authenticated": "template". When a URL is shared to the "template", anyone that can use the template can also visit the URL.

I'm fine with this.

Some customers still use general templates across multiple teams. However, I agree that we should signal templates-per-team.

December update: I was wrong. After discussion with multiple customers, I realize that template-per-team is not a typical pattern. For example, devcontainer-centric development may mean only one template for the entire org.

Just adding a comment: templates-per-team is not how we organize our templates. One template is used by the entire company, and teams are subsets of that. I think of templates as the structure around how you define what a workspace is, and groups as a permission structure. Doing this on the code level is also insufficient.

For my use case, what's needed is sharing workspaces to a user or group, as the two entities that represent access control in the Coder app. The workflow should look like this:

1. Open up my workspace
2. Go to Open ports
3. Enter a port number (e.g. '12345')
4. Select Sharing Level: 'custom'
5. Click some multi-select dropdown that allows me to specify individual users or groups.

I would also be interested in this feature