Add parameterized actions to provide runtime values when executing (#400)
* Add typed Action parameter authoring (PR 1 for #377)
Introduce a typed parameter spec for Actions so moderators can be prompted for runtime values when executing an action (e.g. "Ban for N days"). This PR is the authoring and configuration part definition, validation, persistence, and the create/edit UI from the actions form only.
There will be a follow up prs to surface on the actions page and execution as well as handling of audit log.
Added new Actions model and added new fields to the existing actions model.
* Regenerate GraphQL types
Sync the committed `generated.ts` files with the schema after the
docstring trim that landed in 590c506 was applied without re-running
codegen. Fixes the `check_generated_graphql` CI job on PR #400.
* fix tests
* [377] Wire Action parameters through execution + persist to ClickHouse audit log (#408)
* Wire Action parameters through execution + persist to ClickHouse audit log (PR 2 for #377)
Builds on PR 1 (typed parameter authoring, #400) by routing moderator-supplied parameter values from each run UI through the publisher into the action webhook payload, adding a separate "moderator note" field on every execution path, and recording both to the `analytics.ACTION_EXECUTIONS` audit log.
Added validation for the parameters on the action page and the actions form. Added form on the actioning with modal to add details on action to be taken and ability to edit those details.
* Fix ClickHouse action_executions migration syntax
ClickHouse columns are non-nullable by default; the `NOT NULL` keyword
isn't valid in `ADD COLUMN` and was rejected by the migrator. Drop it
and rely on the explicit `DEFAULT '{}'` for back-compat.
* Gate parameterized actions behind the modal in MRT v2 + Investigation
Two paths were previously skipping the parameter prompt and silently
publishing actions with empty values:
1. MRT v2 related-action buttons (e.g. Associated User panel, thread
related actions, content view related actions) called the enqueue
callback as soon as a policy was picked, with no chance to collect
parameter values.
2. The Investigation tool's `ItemAction` rendered all parameter inputs
inline below the action selector, which got visually overwhelming
for actions with several fields and didn't match the modal-based
pattern used elsewhere.
Fix:
- New `useEnqueueActionGate` hook wraps `onEnqueueActions` at the top
of `ManualReviewJobReviewImpl`. Items whose action declares
`parameters` are queued and routed through `ActionParametersModal`
one action at a time; multiple targets enqueued for the same action
in a single batch share one prompt. Items without parameters (or
that already carry a `customMrtApiParamDecisionPayload` from another
flow) pass straight through.
- `ItemAction.tsx` now opens `ActionParametersModal` immediately when
a parameterized action is selected and shows a small "Edit"
affordance for re-opening it. Cancelling the modal removes the
staged action so required values can never be skipped.
* Add Edit affordance for parameterized actions in Other Actions panel
The Other Actions panel had no way to revise parameter values once an
action was enqueued — moderators had to remove the action and re-add it
just to fix a typo. Add a small pencil button next to each entry that
declares parameters; clicking it reopens `ActionParametersModal` in
edit mode, pre-filled with the entry's current payload, and only
updates that one entry on save.
The edit path is exposed via a new `editParameters` method on the
shared `useEnqueueActionGate` hook so the create and edit flows reuse
the same modal queue and only one modal is ever rendered at a time.