Files

hsiegeln e71edcdd5e docs(alerting): add BL-002 for native provider integrations + Mustache auto-complete

BL-002 / gitea#138 tracks deferred native provider types (Slack Block Kit,
PagerDuty Events v2, Teams connector) with shipped templates as a post-v1
fast-follow once usage data informs which providers matter.

Spec §13 folds in context-aware variable auto-complete for the shared
<MustacheEditor /> component used in rule editor, webhook overrides, and
outbound-connection admin. Available variables filter by condition kind.
Completion engine choice added to §20 as a planning-phase decision.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-04-19 15:10:00 +02:00

5.5 KiB

Raw Blame History

Backlog

Deferred items surfaced during design / planning / execution that we've decided not to build right now but want to keep visible. Append-only — close items by marking them and moving to the "Closed" section with a link to the delivering commit/spec.

Open

BL-001 — Managed CA bundles for outbound HTTPS

Opened: 2026-04-19 Surfaced by: Alerting design — TLS trust section Tracking: gitea#137 Status: Open

Context. The alerting feature introduces server → external HTTPS webhooks, which makes outbound TLS trust a cross-cutting concern (joining the existing OIDC token-exchange / JWKS fetch paths). Alerting v1 handles this with a shared OutboundHttpClientFactory + system config (cameleer.server.outbound-http.trusted-ca-pem-paths) + a per-webhook TrustMode override (SYSTEM_DEFAULT / TRUST_ALL / TRUST_PATHS). CA files in v1 are filesystem-resident, managed via deployment config — there is no in-app upload surface.

What's deferred.

In-app CA bundle management. Admin UI to upload, list, and delete trusted CA PEMs. Storage in PG (trusted_ca_certs table) so all replicas see a consistent set without a filesystem sync step. Likely lives under /admin/outbound-http (new admin surface) or as a tab on the existing admin navigation.
SaaS-layer CA reuse — design investigation (do first). The SaaS layer already manages CA material for the server (for its reverse-proxy → OIDC path and related). Before building in-app CA management in the OSS server, investigate whether the SaaS CA mechanism can be extended/exposed so the server can consume trust material from the SaaS layer directly. Goal: KISS + DRY — don't duplicate a CA store in the server if the SaaS side already owns one. If reuse is viable, in-app CA upload in the server may never be needed — the SaaS layer becomes the authoritative admin surface and the server just reads.

Acceptance criteria.

Investigation concludes with a one-page decision: reuse SaaS / build in-server / hybrid, with rationale and an implementation sketch.
If "build in-server" is chosen: spec + plan + implementation following the normal flow. Must include PG-backed storage, audit logging on CA change (category already introduced: OUTBOUND_HTTP_TRUST_CHANGE), and cluster-consistent propagation.
If "reuse SaaS" is chosen: spec for the extension on the SaaS side + a small server-side consumer; the server's current file-path-based trust config remains as the OSS fallback for non-SaaS deployments.

Why we're not doing it now.

Alerting v1's file-based trust config is identical to how the server handles other trust material today (OIDC issuer URIs, Ed25519 keys), so it's no regression.
Building in-server CA management before the SaaS reuse investigation risks duplicating work we may throw away.
Most early alerting users will target public SaaS webhooks (Slack, PagerDuty, Teams) whose certs chain to public roots — no custom CA needed.

Links.

cameleer-server-app/src/main/java/com/cameleer/server/app/http/ (v1 outbound HTTP module — the investigation will extend this)
OIDC trust touch-points in OidcProviderHelper, OidcTokenExchanger (alignment reference)

BL-002 — Native provider integrations for alerting (Slack, Teams, PagerDuty with shipped templates)

Opened: 2026-04-19 Surfaced by: Alerting design — §2 Out of scope Tracking: gitea#138 Status: Open

Context. Alerting v1 ships with generic outbound webhooks + JMustache templates — users paste their Slack incoming webhook URL (or PagerDuty Events API key, or Teams connector URL) and write the body from scratch. A natural fast-follow is to elevate the most common providers to first-class connection types with tuned default templates, provider-specific config hints, and test actions that speak each provider's native format.