@mtojek I suppose we would need some changes in the TF schema + BE support

@mtojek I suppose we would need some changes in the TF schema + BE support

Thanks for taking a look, Bruno! Feel free to draft a list of BE requirements.

@mattlqx what do you think about defining a group of coder apps like the following:

resource "coder_app" "jira" {
  // ...
  slug         = "jira"
  display_name = "Jira"
  group        = "support"
  default      = true
}

resource "coder_app" "slack" {
  // ...
  slug         = "slack"
  display_name = "Slack"
  group        = "support"
}

It would look like this:

PS: Jira and Slack would be displayed in the menu as we do for the VS Code button.

Yeah, that's reasonable.

Would it be possible to make a "dummy" button be the default so that you could have it just say "Support" and the dropdown buttons be the actual actions? Clicking on any part of the default button would also expand the dropdown. If that's not clean enough, your suggested implementation is fine!

I like this, but how do you set the order for each one? +1 for a dummy button

Terraform also supports a nested syntax which is another possibility, but I'm not sure if that makes it difficult to use all fields for a sub-item

resource "coder_app" "support" {
  display_name = "Support"
  child {
    display_name = "Jira"
    external = true
    url=""
  }
  child {
    display_name = "internal"
    url = ""
    healthcheck {
       # ...
    }
  }
}

Wondering if this would be reasonable:

resource "coder_app_group" "support" {
  display_name = "Support"
  name         = "support" 
}

resource "coder_app" "jira" {
  // ...
  slug         = "jira"
  display_name = "Jira"
  group        = "support"
  default      = true
}

resource "coder_app" "slack" {
  // ...
  slug         = "slack"
  display_name = "Slack"
  group        = "support"
}

I wonder if @mtojek has thoughts here. The unfortunate trade-off there is the primary app cannot be clickable.

I think it is acceptable, but has a different behaviour than the VS Code (Desktop/Insiders) versions. I wonder if there is a clean syntax that can support both

I like this, but how do you set the order for each one? +1 for a dummy button

Parameters support the "order" column, which lets the owner sort them by order & name. Maybe we should bring a similar solution to apps?

Wondering if this would be reasonable:

I like the concept of coder_app_group. If we are concerned about the item order, then ^

Let me know your thoughts.

From Kyle over slack:

LGTM, but maybe instead of group being a string with a matching name on coder_app, maybe we make it reference by the resource ID.
e.g. group = coder_app_group.support.id
or something

After some discussion in Slack, here's an updated proposal based on @BrunoQuaresma's and tries to take into consideration the requirements discussed here.

This adds an action (alt. type) property on the group that, when set to group, will show a button named Support | v that will always show a dropdown on click, and clicking an item will not select it, but open that app. Or, when set to app, show a button that behaves exactly like the VS Code button (switching item changes the default in the browser session).

resource "coder_app_group" "support" {
  display_name = "Support"
  action = "group"|"app"
}

resource "coder_app" "jira" {
  // ...
  slug         = "jira"
  display_name = "Jira"
  group        = coder_app_group.support.id
  group_order  = 1
}

resource "coder_app" "slack" {
  // ...
  slug         = "slack"
  display_name = "Slack"
  group        = coder_app_group.support.id
  group_order  = 2
}

@kylecarbs I think modules can benefit from this feature too. For example, we can allow grouping all IDE modules so that they all show up as a dropdown on a single button.

I agree that findings ways to support more advanced UI customization is interesting, but I don't think leaning more on Terraform for layout is the right direction. We want to keep the terraform provider as small and orthogonal as possible, and UI customization is an endless vista of complexity that's better supported by a true programming layer such as a React component API.

Going to close this out for now.

Re opening due to the bump from @mattlqx.

I think @bpmct's suggested approach of using HCL's nested syntax is cleanest as it forces relevant buttons together in the code and makes refactoring easy. Plus, with that approach, it's impossible to target the wrong group name, it's impossible to create infinite group cycles, and the nesting in the code maps to the nesting in the UI.

I like the idea to grouping apps together as it would unclutter the UI for some workspaces with huge amount of defined apps.

I like the nested format and handles clutter.

If a coder_app is just a link does it make sense to be another type of resource for just links.

Because each workspace I would like to have links for help (teams), docs (confluence) and feedback (support form). Which are all external links.

Many of our IDEs are added to templates using modules. We need to support grouping such IDEs coder_apps too.

1st Proposal (My preference)

An idea is to update each module to output the coder_app.code_server.id of each coder_app they expose. Then this new grouping feature can make use of those ids to make a group.

resource "coder_app_group" "ide" {
  display_name = "IDEs"
  action       = "group"|"app"
  members      = [module.cursor.app_id, module.windsurf.app_id] 
  # No order parameter is needed as it's deducible from the `members` list.
}

module "cursor" {
  count       = data.coder_workspace.me.start_count
  source      = "registry.coder.com/modules/cursor/coder"
  version     = "1.0.19"
  agent_id    = coder_agent.example.id
  folder      = "/home/coder/project"
}

module "windsurf" {
  count       = data.coder_workspace.me.start_count
  source      = "registry.coder.com/modules/windsurf/coder"
  version     = "1.0.0"
  agent_id    = coder_agent.example.id
  folder      = "/home/coder/project"
}

Each module exposes the coder_app.id as an output with the name app_id.

2nd Proposal

And if we go with @mafredri's proposal above, we can just add new optional inputs to each module to pass in the group and group_order.

resource "coder_app_group" "ide" {
  display_name = "IDEs"
  action = "group"|"app"
}

module "cursor" {
  count       = data.coder_workspace.me.start_count
  source      = "registry.coder.com/modules/cursor/coder"
  version     = "1.0.19"
  agent_id    = coder_agent.example.id
  folder      = "/home/coder/project"
  group       = coder_app_group.ide.id
  group_order = 1
}

module "windsurf" {
  count       = data.coder_workspace.me.start_count
  source      = "registry.coder.com/modules/windsurf/coder"
  version     = "1.0.0"
  agent_id    = coder_agent.example.id
  folder      = "/home/coder/project"
  group       = coder_app_group.ide.id
  group_order = 2
}

where these new inputs get passed to the nested coder_app in the module.