Terraform provider (atlassian-operations): no way to manage an integration's outgoing alert filter.

Question

We manage our JSM Operations setup with the atlassian/atlassian-operations Terraform provider (v2.0.6). One of our integrations is an outgoing Webhook that forwards alerts to Microsoft Teams. It should only forward alerts tagged TEAM-A or TEAM-B, using a filter like tags matches (^TEAM-A$|^TEAM-B$).

The REST API supports this as an integration-level outgoing alert filter:

GET/PATCH /v1/integrations/{integrationId}/outgoing/alert-filter/main
{"conditionMatchType":"match-all-conditions",
 "conditions":[{"field":"tags","operation":"matches","expectedValue":"(^TEAM-A$|^TEAM-B$)"}]}

The provider has no resource or attribute for it:

* atlassian-operations_api_integration doesn't expose the outgoing alert filter.
* atlassian-operations_integration_action.filter is sent for outgoing actions but doesn't control forwarding, and the action GET doesn't return it.

So we set the filter by hand in the UI. It doesn't show up in terraform plan, and drift can't be detected.

Questions:

* Is support for the outgoing alert filter planned in the provider? For example an outgoing_alert_filter block on atlassian-operations_api_integration, or a separate atlassian-operations_integration_outgoing_alert_filter resource.
* If not, could this be logged as a JSDCLOUD Suggestion? The provider's GitHub repository has issues disabled.

A tip for others using outgoing Webhook actions in Terraform: set type = "postToUrl" and put the alert action in action_mapping, e.g. action_mapping = { type = "create" }. If you use type = "create" instead, the API accepts it, but the UI then refuses to save the action ("Property [mapped action] should be one of [postToUrl]").

Mihai_LeanZero · Answer

Hi @Wiktor Ciurej,

Josh's option 1 works. Below is a concrete version, with one trap in it.

On getting it into the provider itself, the README says GitHub issues aren't used. Provider requests are filed under the JAC component "Operations - Terraform Provider" (JSDCLOUD-17980 is one). I found no ticket under that component for this filter, and the closest elsewhere is OPSGENIE-1239 for the old Opsgenie provider. Support can log a new suggestion via https://support.atlassian.com/contact/

With the Mastercard/restapi provider, this drives the documented endpoint (https://developer.atlassian.com/cloud/jira/service-desk-ops/rest/v2/api-group-integration/):

provider "restapi" {
  uri      = "https://api.atlassian.com/jsm/ops/api/<cloudId>/v1"
  username = var.email
  password = var.api_token
}

locals { f = "/integrations/{id}/outgoing/alert-filter/main" }

resource "restapi_object" "teams_filter" {
  path           = "/integrations"
  object_id      = atlassian-operations_api_integration.teams.id
  read_path      = local.f
  create_path    = local.f
  update_path    = local.f
  destroy_path   = local.f
  create_method  = "PATCH"
  update_method  = "PATCH"
  destroy_method = "PATCH"
  destroy_data   = jsonencode({ conditionMatchType = "match-all", conditions = [] })
  data = jsonencode({ conditionMatchType = "match-all-conditions", conditions = [{ field = "tags", operation = "matches", expectedValue = "(^TEAM-A$|^TEAM-B$)", not = false, key = "matches" }] })
}

The GET returns no id, hence the manual object_id. It also adds not and key to each condition, so data carries them too. The trap: leave ignore_server_additions off. In 3.0.0 it hides UI edits from plan (restapi issue #348), which is the drift you want to see. Destroy resets the filter to match-all, the default that forwards everything.

The PATCH and GET worked on a test site and the filter persisted. I haven't run terraform apply on this snippet. The token user must be admin of the integration's team.

Josh · Answer

Hi @Wiktor Ciurej, thanks for the action_mapping tip, that one catches a lot of people.

I don't know of any outgoing alert filter support in the atlassian-operations provider as of v2.0.6, and I haven't seen it announced. Until it lands, you can still keep the filter in code and get drift detection by calling the REST endpoint you already found from Terraform:

1. Generic REST provider. A community REST provider (for example a "restapi" style provider) can own the object at /v1/integrations/{integrationId}/outgoing/alert-filter/main. Feed it the integration ID from your atlassian-operations_api_integration resource and the JSON body you posted. Because the provider reads the object back on plan, a manual change in the UI shows up as drift.

2. terraform_data with local-exec. Lighter, but it only re-runs when its inputs change, so you get "apply the filter" but not drift detection. Put the filter JSON in triggers_replace so a change to the expression forces a new PATCH.

Either way, set depends_on to the integration so the filter is applied after the integration exists, and keep the API credentials in variables or environment, not in the module.

For a feature request: since issues are off on the provider's GitHub repo, the usual route is to raise it with Atlassian Support and ask them to log or link a public suggestion on jira.atlassian.com. Then post the key here so others can vote.