mirror of
https://github.com/windmill-labs/windmill.git
synced 2026-09-21 08:02:38 +00:00
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
41 lines
2.6 KiB
Markdown
41 lines
2.6 KiB
Markdown
# 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 no
|
|
`workspace_settings` row, which is what `OperatorManageRights::default` is 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_settings` is git-synced as a whole
|
|
object (`cli/src/core/settings.ts` posts 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.
|