[harshithmohan]

Summary

Moving scheduled-action trigger editing out of each action's accordion and into a modal. The row was holding an unsaved draft (keyed triggers, validation errors, save/reset/discard) inside a list that polls every 2s while an action is running, and it was doing two unrelated jobs: reporting an action's state and editing its triggers.

Relates to #1484.

Changes

• ScheduledActionItem.tsx — now read-only: name (truncated with a tooltip), state badge, summary line, run-now, cancel-run, an edit-triggers button and a chevron accordion of details (last run, last run by a trigger, next run, minimum interval, and the per-action note on whether a manual run counts toward the schedule). The state badge shrank and dimmed (text-sm → text-xs opacity-65) so it reads as a status next to the name rather than competing with it.
• TriggersModal.tsx (new) — the whole editor: add/remove/edit triggers, validation, save, reset to defaults and cancel. Draft is synced from the action with useSyncedState, keyed so an editor keeps its inputs when one above it is removed. Save is disabled while a reset is in flight, and the modal refuses to close mid-save or mid-reset. Validation errors clear as soon as the draft changes.
• ScheduledActionsSettings.tsx — owns the selected action and renders the modal; primary hotkey scope handed off while it is open. The header gained a line explaining that a manual run usually counts toward the schedule, and each category's divider moved from after the category to before it.
• helpers.ts — triggerTypes is keyed by type instead of searched, and getTriggerType/getTriggerLabel are gone; lookups fall back to the raw type for a trigger the WebUI does not know, which is kept as-is on save.
• TriggerEditor.tsx — follows the triggerTypes change.
• scheduled-action.ts — doc comments: "by hand" → "manual".

[hidden4003]

Review of #1521

The PR matches its description and follows the repo's patterns. I have one question and a few small items. None of them block it.

Question: modal mount model

Every other modal in the repo (EditEpisodeTitleModal, HashTypesModal, ReleaseManagementSettingsModal and so on) is always mounted. Each takes a show prop and calls both useToggleModalKeybinds(show, 'modal') and useToggleModalKeybinds(!show, 'primary').

TriggersModal is instead mounted conditionally with show hard-coded to true. It calls useToggleModalKeybinds(true, 'modal') itself, and the page hands primary back through useToggleModalKeybinds(!selectedActionID, 'primary'). As a result:

• ModalPanel's 150ms closeTimeoutMS exit animation never plays, because the modal unmounts immediately.
• Keybind ownership is split between the page and the modal.

Conditional mounting does give a fresh draft and cleared errors on every open. Is this an intentional change to our modal pattern, or should it be refactored to the show-prop convention?

Description

Two changes in ScheduledActionsSettings.tsx aren't mentioned in the PR description:

• a new explanatory line under the header about manual runs counting toward the schedule;
• each divider moved from after a category to before it.

Nitpicks

• ScheduledActionItem.tsx: the info wrapper still has text-left, left over from when it was a <button>.
• ScheduledActionItem.tsx: the Run button's inline if/else in onClick could be a named handleRun, like handleCancel.
• The badge style changed from text-sm to text-xs opacity-65. Please mention it in the description if it's intentional.