Describe the bug
When a user is added to a parent project after one of its sandboxes already exists, they don't get access to that pre-existing sandbox (project users aren't synced down to existing sandboxes, which is intentional). But the sandbox still appears in their sandboxes list, and depending on their role on the parent project they can also merge, edit, or delete it from the UI.
Projects already follow the right rule: users only see projects they have access to. Sandboxes should do the same.
Loom showing the current behaviour: https://www.loom.com/share/d2cd3f99195640e0972d0fc42dcf152a
To Reproduce
- As user A, create a parent project and provision one sandbox under it.
- As user A, add user B to the parent project as
:admin or :editor. Do not add user B to the sandbox.
- Sign in as user B and open the sandboxes list for the parent project.
- Observe that the sandbox created in step 1 is listed, even though user B is not a project user on it.
- Observe that user B can also act on it (merge / edit / delete) based on their parent-project role.
Expected behavior
The sandboxes list should only include sandboxes the current user is a project user on. Sandboxes the user cannot access should be hidden, and the corresponding actions should not be reachable. This matches how the projects list already behaves.
Additional context
This is the cheap short-term fix. The deeper question is the access model itself: today, parent-project access does not flow to sandboxes, and sandbox access does not flow to siblings. A future access model could let collaborators be added at the workspace level, at the "all sandboxes" level, or to a specific project/sandbox, and would change how visibility is computed. That redesign is out of scope here; this issue is just the visibility fix to make the current behaviour consistent with projects before the public release of sandboxes.
Describe the bug
When a user is added to a parent project after one of its sandboxes already exists, they don't get access to that pre-existing sandbox (project users aren't synced down to existing sandboxes, which is intentional). But the sandbox still appears in their sandboxes list, and depending on their role on the parent project they can also merge, edit, or delete it from the UI.
Projects already follow the right rule: users only see projects they have access to. Sandboxes should do the same.
Loom showing the current behaviour: https://www.loom.com/share/d2cd3f99195640e0972d0fc42dcf152a
To Reproduce
:adminor:editor. Do not add user B to the sandbox.Expected behavior
The sandboxes list should only include sandboxes the current user is a project user on. Sandboxes the user cannot access should be hidden, and the corresponding actions should not be reachable. This matches how the projects list already behaves.
Additional context
This is the cheap short-term fix. The deeper question is the access model itself: today, parent-project access does not flow to sandboxes, and sandbox access does not flow to siblings. A future access model could let collaborators be added at the workspace level, at the "all sandboxes" level, or to a specific project/sandbox, and would change how visibility is computed. That redesign is out of scope here; this issue is just the visibility fix to make the current behaviour consistent with projects before the public release of sandboxes.