AlexRV12andClaude Opus 5
625116e378
Operators can create, edit and delete schedules and triggers today through the API, CLI and MCP, while the operator_settings flags beside them only hide those pages. An admin who wants operators to see what is scheduled without letting them change it cannot express that. Add manage_schedules and manage_triggers as enforced settings, gated at the schedule handlers and at the generic TriggerCrud routes so every trigger kind is covered by one check. They name capabilities operators already hold, so they are granted unless withdrawn, and absence has to mean "never configured" rather than a value. The read coalesces to true; the update endpoint merges into the stored jsonb with the two fields as Option<bool>, so an omitted key keeps what is stored. operator_settings is git-synced as a whole object, so a settings file written before these keys existed reaches the endpoint on every pull, and a serde or SQL default of either polarity would turn that pull into a silent withdrawal or restoration. The rights are read through a per-process cache, so withdrawing one publishes a notify_event that drops the entry on every replica. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Dsf6VC4MVLisiEoeQkgbr4
2.6 KiB
Operator write rights
Most of workspace_settings.operator_settings is visibility: flags that hide pages from operators
so the UI stays uncluttered. They are not enforced, and were never meant to be.
manage_schedules and manage_triggers are different. They are enforced on the write paths,
because hiding the schedules page never stopped an operator creating a schedule through the API,
the CLI or MCP. An admin who wants operators to see what is scheduled without letting them change
it could not express that with a visibility flag alone.
Read them with windmill_common::workspaces::operator_manage_rights (60s cache) and gate a write
with check_operator_can_manage, naming a ManageKind. Call it before opening an RLS
transaction: it takes a connection from the root pool, and a second pooled connection held
alongside a transaction self-deadlocks on a one-connection pool.
The cache is per process, so withdrawing a right has to reach every replica: an AFTER UPDATE OF operator_settings trigger writes a notify_operator_settings_change row and process_notify_event
drops the entry. Keep both ends if you touch either, or a workspace that withdrew a right keeps
authorizing writes on every other replica until its own entry expires.
Granted unless withdrawn
These name capabilities operators already hold, so absence has to mean "never configured", not a value. That is easy to get wrong in two places, and both were wrong in the obvious first draft:
- The read coalesces to true (
operator_manage_rights), including for a workspace with noworkspace_settingsrow, which is whatOperatorManageRights::defaultis for. Coalescing to false instead revokes the right on upgrade for every workspace that ever saved operator settings, since those rows carry explicit keys and none of them is this one. - The update endpoint merges into the stored jsonb and takes these two as
Option<bool>, so an omitted key keeps its stored value. It has to:operator_settingsis git-synced as a whole object (cli/src/core/settings.tsposts the file's contents verbatim), so a settings file written before these keys existed reaches the endpoint on every pull. A serde or SQL default of either polarity turns that pull into a silent withdrawal or a silent restoration.
The visibility flags are plain bool and always serialize, so the merge is a no-op for them and
their behaviour is unchanged.
Do not model a right that an admin grants on these. Granted-by-default and granted-on-request are opposite polarities, and a gate written for one is wrong for the other.