Merge branch 'main' into docs/volumes-sandbox-claude-template

Author: hcourdent

docs/core_concepts/12_staging_prod/index.md

@@ -78,3 +78,21 @@ This can be useful for non-admin (for example, operators) to share a page to pro
 ![Shareable page](./shareable_page.png.webp 'Shareable page')
 
 > This page then allows users with the right permissions to deploy the given items.
+
+## Run on behalf of
+
+When deploying a script, flow, app, or trigger to another workspace, the **"run on behalf of"** selector lets you choose which user the item will execute as in the target workspace. This is useful for controlling execution permissions across environments.
+
+There are three options:
+
+- **Keep the target workspace's existing setting** — the item continues running as whatever user was previously configured in the target workspace. This is the default for items that already exist there.
+- **Use yourself** — the item will run as your own user in the target workspace.
+- **Pick any user from the target workspace** — select a specific user (e.g. a dedicated service account) for the item to run as.
+
+Selecting a user other than yourself requires **admin** rights or membership in the **`wm_deployers`** group in the target workspace.
+
+:::tip Virtual users for fine-grained permissions
+
+For production workspaces, consider creating dedicated virtual users scoped to specific responsibilities. See [Permission compartmentalization with virtual users](../16_roles_and_permissions/index.mdx#permission-compartmentalization-with-virtual-users) for the recommended pattern.
+
+:::

docs/core_concepts/16_roles_and_permissions/index.mdx

@@ -170,10 +170,34 @@ Also, [extra permission](#extra-permissions) was given to Ruben as viewer.
 
 <br />
 
+## Run on behalf of
+
+Scripts and flows can be configured to run **on behalf of** a specific user. When set, that user's permissions are used during execution — the runnable can only access the resources, variables, and folders that user has rights to — and all runs are attributed to that user in the [audit logs](../14_audit_logs/index.mdx).
+
+For **apps**, run on behalf of is always enabled: app executions always use the permissions of the set user (usually the app's last editor).
+
+**Schedules and triggers** work in a similar manner: they use the `edited_by` user as the owner of the executions they create.
+
+## Permission compartmentalization with virtual users
+
+By combining the run on behalf of mechanism with dedicated users, you can implement fine-grained permission compartmentalization. Instead of running everything as a single admin or shared account, create users scoped to specific logical modules. For example:
+
+- A `billing-bot` user with access only to billing-related resources and folders
+- A `data-pipeline` user scoped to data processing folders and their associated variables
+
+Then set scripts, flows, schedules, and triggers to run on behalf of these virtual users. A script running on behalf of `billing-bot` cannot accidentally read or modify resources outside its scope, even if the script code itself contains a bug or misconfiguration. The audit logs will also clearly show which virtual user initiated each execution.
+
+Combined with the ["run on behalf of" selector during deployments](../12_staging_prod/index.md#run-on-behalf-of), this pattern extends across workspaces: when deploying to a production workspace, you can assign each item to the appropriate virtual user in the target environment.
+
 <div className="grid grid-cols-2 gap-6 mb-4">
 	<DocCard
 		title="Groups and folders"
 		description="Groups classify users with shared permissions, while folders group items and assign role-based access control."
 		href="/docs/core_concepts/groups_and_folders"
 	/>
+	<DocCard
+		title="Deploy to staging/prod"
+		description="Deploy items to another workspace with control over which user they run as."
+		href="/docs/core_concepts/staging_prod"
+	/>
 </div>

docs/core_concepts/52_native_triggers/index.mdx

@@ -72,6 +72,8 @@ You can also create native triggers directly from a script or flow's **Triggers*
 
 ## Nextcloud triggers
 
+Firs of all make sure you set up the [workspace integration](#workspace-integration) for Nextcloud.
+
 Nextcloud native triggers watch for file, folder, and calendar changes on a [Nextcloud](https://nextcloud.com/) instance and trigger a script or flow when events occur.
 
 ### Prerequisites
@@ -115,6 +117,8 @@ export async function main(
 
 ## Google triggers
 
+First of all make sure you set up the [workspace integration](#workspace-integration) for Google.
+
 Google native triggers watch for changes in [Google Drive](https://drive.google.com/) or [Google Calendar](https://calendar.google.com/) and trigger a script or flow when events occur.
 
 ### Prerequisites
@@ -138,7 +142,7 @@ Both use push notifications via Google watch channels. Windmill automatically re
 
 ### Event payload
 
-Google push notifications only contain metadata about the change, not the full event details. To get the actual content of the change, use the [`gworkspace` resource](../3_resources_and_types/index.mdx) created during workspace integration to query the Google API.
+Google push notifications only contain metadata about the change, not the full event details. To get the actual content of the change, use the [`gworkspace` resource type](../3_resources_and_types/index.mdx) created during workspace integration to query the Google API.
 
 ```typescript
 type GoogleTriggerPayload = {

package-lock.json

@@ -28,11 +28,11 @@ const roadmapItems = [
 			'Investigate having Windmill work locally for local workflow and script execution allowing better DX and AI agents to have immediate local feedback.'
 	},
 	{
-		title: 'Full wmill lint for agents',
+		title: 'Improve wmill lint for agents',
 		category: 'Developer',
 		issueLink: '',
 		description:
-			'Implement a full wmill lint to be used as a complete feedback tool for agents locally + clear OpenAPI specs for each kind of items writable locally by agents, for improved local dev.'
+			'The wmill lint command already works for v0. Improve it to be a more complete feedback tool for agents locally + clear OpenAPI specs for each kind of items writable locally by agents, for improved local dev.'
 	},
 	{
 		title: 'Unit tests support',
@@ -41,29 +41,17 @@ const roadmapItems = [
 		description:
 			'Investigate unit tests with Windmill, either only guidance for local tests or/and supporting it as a first class concept in Windmill.'
 	},
-	{
-		title: 'True IaC support',
-		category: 'Backend',
-		issueLink: '',
-		description: 'Full instance config can be set using yaml in the helm chart synced with the DB.'
-	},
-	{
-		title: 'Full-code App GA',
-		category: 'UI',
-		issueLink: '',
-		description: 'Finish the latest full-code app nits and move from Beta to General Availability'
-	},
 	{
 		title: 'Extend multiplayer to flows and apps',
 		issueLink: '',
 		description: 'Extend multiplayer working for scripts to flow and apps.'
 	},
 	{
-		title: 'Native triggers for common external services',
+		title: 'Add more native triggers',
 		category: 'Backend',
 		issueLink: '',
 		description:
-			'Native triggers support to allow setting Github/Nextcloud/GWorkspace events as direct triggers by setting the webhooks on the external service, and monitor their liveness'
+			'Native triggers for Nextcloud and Google are already done. Next steps are adding native triggers for GitHub, Linear, etc.'
 	},
 	{
 		title: 'Single shard performance focus',
@@ -78,11 +66,11 @@ const roadmapItems = [
 		description: 'Support multi-shards for unlimited scalability'
 	},
 	{
-		title: 'Ruleset for deployment rules',
+		title: 'Add more rulesets',
 		category: 'Backend',
 		issueLink: '',
 		description:
-			'Ruleset for deployment rules to match Github rules (read-only prod workspaces, approver rules, etc)'
+			'Add more rulesets for deployment rules to match Github rules (read-only prod workspaces, approver rules, etc)'
 	},
 	{
 		title: 'Data tables/PostgreSQL runtime v2',