FE: Display event trigger details for event-based automations

[malhotra5]

Summary

When viewing an automation detail page in the frontend, event-based automations do not display their event trigger configuration. The backend provides several fields for event triggers that the frontend does not currently render.

Backend Event Trigger Fields

The EventTrigger schema in automation/schemas.py includes the following fields:

Field	Type	Description
type	"event"	Trigger type identifier
source	string	Event source - "github" for built-in integration or custom webhook source name (e.g., "linear", "stripe")
on	string | string[]	Event key pattern(s) to match, e.g., "pull_request.opened", "push", "issue_comment.created", or ["pull_request.opened", "pull_request.synchronize"]
filter	string | null	Optional JMESPath filter expression evaluated against the raw payload, e.g., "icontains(comment.body, '@openhands')" or "repository.full_name == 'myorg/myrepo'"

Current Frontend State

The frontend AutomationTrigger interface in frontend/src/types/automation.ts only has:

export interface AutomationTrigger {
  type: string;
  schedule?: string;
  schedule_human?: string;
}

This is cron-specific and lacks the event trigger fields.

Current Display Issue

In ConfigurationSection.tsx, the trigger display logic shows:

• Trigger type: "Schedule" for cron, otherwise just the raw type string ("event")
• Schedule: Only displays schedule/schedule_human (cron-specific fields)

For event-based automations, users cannot see:

1. What event source is being listened to (GitHub, Linear, custom webhook, etc.)
2. What event types will trigger the automation
3. What filter conditions are applied

Proposed Solution

1. Update TypeScript Types

Update AutomationTrigger interface to include event fields:

export interface AutomationTrigger {
  type: string;
  // Cron fields
  schedule?: string;
  schedule_human?: string;
  // Event fields
  source?: string;
  on?: string | string[];
  filter?: string | null;
}

2. Update ConfigurationSection Component

Add conditional rendering for event triggers in configuration-section.tsx:

For event triggers, display:

• Source: Show the event source (e.g., "GitHub", "Linear", or custom webhook name)
• Event(s): Show the event pattern(s) being listened to (e.g., pull_request.opened, push)
• Filter: If present, show the filter expression (potentially with a code/monospace font since it's a JMESPath expression)

Example display for an event automation:

Field	Value
Trigger	Event
Source	GitHub
Event(s)	issue_comment.created
Filter	icontains(comment.body, '@openhands')

3. Consider UX for Complex Values

• For on field with multiple patterns (array), consider displaying as a comma-separated list or as individual badges/chips
• For filter field, consider using a monospace font and potentially truncation with expand/tooltip for long expressions

Acceptance Criteria

• Frontend types updated to include source, on, and filter fields in AutomationTrigger
• ConfigurationSection renders event source when trigger type is "event"
• ConfigurationSection renders event pattern(s) when trigger type is "event"
• ConfigurationSection renders filter expression when present (with appropriate styling)
• Hide schedule-specific fields when trigger type is "event"
• Add appropriate i18n keys for new labels

References

• Backend schema: automation/schemas.py (EventTrigger class, lines 57-173)
• Frontend types: frontend/src/types/automation.ts
• Frontend component: frontend/src/components/automations/detail/configuration-section.tsx

[linear]

APP-1496

[malhotra5]

Additional Consideration: Custom Webhook Details

For event-based automations using custom webhook sources (not the built-in GitHub integration), we should also consider displaying the associated webhook configuration.

Available Custom Webhook Fields

When an automation uses a custom source (e.g., "linear", "stripe"), the CustomWebhook entity provides:

Field	Description
name	Human-readable name (e.g., "Linear Issues", "Stripe Payments")
source	Source identifier matching the trigger's source field
webhook_url	The URL to configure in the external service
event_key_expr	JMESPath expression for extracting event type from payload
signature_header	HTTP header containing the HMAC signature
enabled	Whether the webhook is active

Proposed UX

When viewing an automation with a custom webhook source:

1. Show webhook name instead of (or alongside) the raw source identifier

   • e.g., "Linear Issues" instead of just "linear"

2. Display webhook URL (with copy button)

   • Helps users verify/configure their external service

3. Show webhook status

   • Indicate if the webhook is enabled/disabled
   • If disabled, the automation won't receive events

4. Optional: Link to webhook settings

   • Allow quick navigation to edit the webhook configuration

Implementation Notes

• The automation detail endpoint currently returns the trigger object which contains source
• We'd need to either:
  • Enrich the automation response with webhook details when trigger.type == "event" and source is not "github"
  • Or make a separate API call to fetch webhook details by source name

Updated Acceptance Criteria

• For custom webhook sources, fetch and display the webhook name
• Display webhook URL with copy functionality
• Show webhook enabled/disabled status
• Consider adding visual indicator differentiating GitHub (built-in) vs custom webhooks

[malhotra5]

UX Recommendation: Separate Webhooks Page

After further consideration, webhook configuration should live on a dedicated Webhooks page rather than being embedded in automation details.

Why: Webhooks and Automations Have Different Relationships

Webhooks are shared infrastructure — one webhook can trigger multiple automations:

• A "Linear" webhook might trigger:
  • Automation A: "Triage new issues"
  • Automation B: "Notify Slack on high-priority updates"
  • Automation C: "Sync to external tracker"

Automations are individual workflows — each defines what to do when events arrive.

Where Each Concern Belongs

Concern	Webhooks Page	Automation Detail
Create/delete webhooks	✅ Primary home	❌ Doesn't belong
Copy webhook URL	✅ Main action	⚠️ Redundant across automations
Rotate secrets	✅ Security action	❌ Doesn't belong
Enable/disable webhook	✅ Clear it affects ALL automations	⚠️ Confusing if shown here
See which automations use it	✅ Useful overview	N/A

Proposed Information Architecture

Webhooks Page (new):

• List of all custom webhooks for the org
• Create new webhook flow
• For each webhook:
  • Name, source identifier, status badge
  • Webhook URL with copy button
  • Secret rotation action
  • Enable/disable toggle
  • List of automations using this webhook
  • Delete action (with warning if automations depend on it)

Automation Detail Page (this issue):

• For event triggers, display:
  • Source (show friendly name for custom webhooks, "GitHub" for built-in)
  • Event pattern(s) from on field
  • Filter expression if present
• For custom webhook sources:
  • Status indicator if webhook is disabled (warning state)
  • "View webhook settings →" link to the webhooks page

Why This UX is Better

1. Avoids redundancy — Webhook URL doesn't repeat across multiple automation pages
2. Clear mental model — Webhooks = integrations; Automations = workflows
3. Safe actions — Disabling a webhook on dedicated page makes impact clear; in automation detail it's ambiguous
4. Discoverability — Users understand webhooks are reusable resources
5. Follows established patterns — Similar to GitHub (webhook settings separate from Actions), Zapier (connections vs. zaps), Slack (apps vs. workflows)

Updated Scope for This Issue

This issue should focus on displaying event trigger details in automation detail:

• Add source, on, filter fields to frontend types
• Display event source (friendly name for custom webhooks)
• Display event pattern(s)
• Display filter expression with appropriate styling
• Show warning indicator if custom webhook is disabled
• Add "View webhook settings" link for custom sources

A separate issue should be created for the Webhooks management page.