Lightning.Projects.list_workspace_projects/2 walks the parent_id tree from the workspace root and returns every descendant. It takes no current_user parameter. SandboxLive.Index.load_workspace_projects/1 assigns the result to @sandboxes and the page renders it unfiltered.
The result is that the Sandboxes page on a parent project shows every descendant in the tree, including sandboxes the current user is not a project_users row on. Clicking those entries 404s. Worse, the same list backs the merge / edit / delete actions, so a user can trigger those on sandboxes they have no access to (gated only by their role on the parent).
This is inconsistent with the projects list, which only shows projects the current user has a project_users row on.
How it surfaced
Loom. Visible during UAT on staging where legacy sandboxes have only their creator as a member (audit: 12 on staging, 5 on prod with significant gaps, all created before sandbox provision auto-copied parent users).
What to fix
Minimal fix: list_workspace_projects/2 grows a current_user parameter and filters descendants to those where the user has a project_users row. SandboxLive.Index.load_workspace_projects/1 passes socket.assigns.current_user through. Matches projects-list behaviour today.
Cleaner option, out of scope here: a richer access model where users are assigned to "everything in workspace / all sandboxes / specific project," controlled from the parent's collaboration list.
Lightning.Projects.list_workspace_projects/2walks theparent_idtree from the workspace root and returns every descendant. It takes nocurrent_userparameter.SandboxLive.Index.load_workspace_projects/1assigns the result to@sandboxesand the page renders it unfiltered.The result is that the Sandboxes page on a parent project shows every descendant in the tree, including sandboxes the current user is not a
project_usersrow on. Clicking those entries 404s. Worse, the same list backs the merge / edit / delete actions, so a user can trigger those on sandboxes they have no access to (gated only by their role on the parent).This is inconsistent with the projects list, which only shows projects the current user has a
project_usersrow on.How it surfaced
Loom. Visible during UAT on staging where legacy sandboxes have only their creator as a member (audit: 12 on staging, 5 on prod with significant gaps, all created before sandbox provision auto-copied parent users).
What to fix
Minimal fix:
list_workspace_projects/2grows acurrent_userparameter and filters descendants to those where the user has aproject_usersrow.SandboxLive.Index.load_workspace_projects/1passessocket.assigns.current_userthrough. Matches projects-list behaviour today.Cleaner option, out of scope here: a richer access model where users are assigned to "everything in workspace / all sandboxes / specific project," controlled from the parent's collaboration list.