sumologic_log_search query_parameter suggested values

[nholdsworth94]

Affected Resource(s)

sumologic_log_search

Feature Request

The query_parameter block on sumologic_log_search only supports name, description, data_type, and value (a single free-text default). There's no way to configure the "Set Values for Parameter" dropdown/suggested-values list that's available in the Sumo Logic UI's "Manage Parameter Settings" dialog when editing a saved search's parameter.

That UI feature lets you define a fixed list of suggested values (e.g. Text entries: prod, uat) that show up as a dropdown/autocomplete when running the saved search. It's a genuinely useful feature for parameterized searches shared across a team (e.g. an env parameter where you want users picking from a small known set of environments, rather than free-typing).

Right now this can only be configured by hand in the UI after terraform apply creates the resource — and because it isn't part of the resource's schema, any subsequent terraform apply that updates the search for an unrelated reason (e.g. changing the query string) re-issues a full update to the log search and appears to reset this UI-configured value list, since it's presumably stored as part of the same parameter object server-side. This makes it unreliable to rely on for anything beyond a one-off demo — teams either have to reconfigure it after every apply, or give up on it entirely and fall back to Sumo's value-history autocomplete instead.

Desired Behavior

Expose the suggested-values list as a field on the query_parameter block, e.g.:

resource "sumologic_log_search" "example" {
  # ...

  query_parameter {
    name        = "env"
    description = "Environment to query"
    data_type   = "ANY"
    value       = "prod"

    # not currently supported:
    suggested_values = ["prod", "uat"]
  }
}

so the full parameter definition (including the dropdown list) can be managed as code and survives every apply, rather than being a manual, easily-clobbered UI-only step.

Actual Behavior

No field exists for this on query_parameter. Confirmed by inspecting the LogSearchQueryParameter struct