starred/windmill
1
0
Fork 0
mirror of https://github.com/windmill-labs/windmill.git synced 2026-10-20 08:03:28 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: say a shared object storage also reaches the parent's data from an operator fork

Browse Source 
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Guilhem Lemouel
2026-10-19 07:09:24 -07:00
co-authored by Claude Opus 5.5
parent 9670b59758
commit c7fe68738e
2 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/operator-write-rights.md
+2 -2
View File
@@ -134,8 +134,8 @@ An operator who forks is a developer in the fork: the creator row copies only `i
the rule grants an operator arbitrary code execution. Deploying scripts, flows and apps back runs
with the user's role in the parent, where the operator write checks refuse it, so an admin or a
`wm_deployers` member deploys them instead. Data is not behind that check: a data table kept on fork
(`KeepOriginal`, the default) is a pointer at the parent's database, and a `Shared` ducklake writes
the parent's lake, so code in the fork reads and writes the parent's data directly. The ruleset
(`KeepOriginal`, the default) is a pointer at the parent's database, and a shared object storage or
ducklake writes the parent's, so code in the fork reads and writes the parent's data directly. The ruleset
toggle's help text says so; an admin who turns it on accepts it, or also turns on
`RequireIsolatedForks` (`docs/fork-object-storage.md`), which binds operators too. The developer row also costs a
seat: the self-hosted seat count takes a user who is a developer in any workspace, forks included,
frontend/src/lib/components/workspaceSettings/RulesetEditor.svelte
+1 -1
View File
@@ -321,7 +321,7 @@
options={{ right: 'Allow operators to fork' }}
/>
{@render description(
"Operators cannot fork a workspace unless a ruleset turns this on. It applies to every operator, whatever the bypass list says. An operator who forks is a developer in the fork and counts as a developer seat. There they can run any code, including against this workspace's data tables and shared ducklakes, which the fork uses directly unless isolated forks are required. They still cannot deploy scripts, flows or apps back to this workspace."
"Operators cannot fork a workspace unless a ruleset turns this on. It applies to every operator, whatever the bypass list says. An operator who forks is a developer in the fork and counts as a developer seat. There they can run any code, including against this workspace's data tables and any object storage or ducklakes shared with the fork, which it uses directly unless isolated forks are required. They still cannot deploy scripts, flows or apps back to this workspace."
)}
</div>
<div class="flex flex-col gap-1">