`authentik_event_rule.destination_event_user` silently dropped on UPDATE — breaks NotificationRule webhook firing

[ohrekap]

Summary

authentik_event_rule.destination_event_user is accepted at TF plan/apply time but the provider doesn't actually persist it to the Authentik API on UPDATE operations (CREATE works correctly). The Workspace reports ReconcileSuccess but the live rule keeps destination_event_user = false, breaking the firing of bound webhook transports — Authentik 2025.12's NotificationRule logic skips transport invocation when there are no recipients (no destination_event_user, no destination_group).

Versions

• terraform-provider-authentik 2025.10.x (latest at time of filing)
• Authentik server: 2025.12.4
• Terraform: 1.5.7 (run via Crossplane provider-terraform; same behavior reported with vanilla TF 1.10.x)

Reproducer

resource "authentik_property_mapping_notification" "audit_webhook_signed" {
  name       = "Audit webhook test"
  expression = <<-EOT
    return {"signed_payload": "{}", "signature": "x"}
  EOT
}

resource "authentik_event_transport" "audit_webhook" {
  name                 = "Audit webhook test"
  mode                 = "webhook"
  webhook_url          = "https://example.invalid"
  webhook_mapping_body = authentik_property_mapping_notification.audit_webhook_signed.id
  send_once            = false
}

resource "authentik_event_rule" "audit_log" {
  name                   = "Audit log test"
  severity               = "notice"
  transports             = [authentik_event_transport.audit_webhook.id]
  destination_event_user = true   # <-- this is the field that drops on UPDATE
}

resource "authentik_policy_event_matcher" "audit" {
  name   = "audit-event-login_failed"
  action = "login_failed"
}

resource "authentik_policy_binding" "audit" {
  target  = authentik_event_rule.audit_log.id
  policy  = authentik_policy_event_matcher.audit.id
  order   = 0
  enabled = true
}

Steps to reproduce

1. Apply the above HCL. Verify via API: curl /api/v3/events/rules/<rule-pk>/ → destination_event_user: true ✅ (CREATE works).
2. Modify any other field on the rule (e.g. severity = "warning"). Apply.
3. Re-query the rule via API: destination_event_user is now back to false. ❌

Observed behavior

• TF plan shows no diff for destination_event_user on the second apply (provider treats config and live state as matching).
• Live state actually has destination_event_user: false.
• The provider's UPDATE PATCH body to /api/v3/events/rules/<pk>/ does not include destination_event_user.

Expected behavior

The provider's UPDATE method should include destination_event_user in the PATCH body whenever the schema field has a value, matching CREATE behavior.

Why it's load-bearing

In Authentik 2025.12, NotificationRule.send_notification (events/tasks.py) iterates recipients computed from destination_group ∪ (destination_event_user ? [event.user] : []). If recipients is empty AND no Notification was created, the loop over transports doesn't fire — including webhook transports. So a rule with bound webhook transport but no destination_event_user and no destination_group is silently inert.

Direct API check works

curl -X PATCH /api/v3/events/rules/<pk>/ -d '{"destination_event_user": true}' → 200, field persists. So the API accepts the partial update.

Current workaround

A side-car k8s CronJob runs hourly, reads the live value via /api/v3/events/rules/<pk>/, and PATCHes back to destination_event_user: true if drifted. Painful but reliable. See also #895 (same drift family on a different attribute).

Suggested fix

Inspect internal/provider/resource_event_rule.go Update method — destination_event_user is likely missing from the PATCH body construction or is gated behind a condition that only fires on CREATE.