Skip to content

Sandbox access-rule decisions: delete/rename cascade, parent-admin floor #4768

@elias-ba

Description

@elias-ba

Context

Two open access-rule questions left over from PR #4763 (Sandboxes: scope visibility, tighten merge gate, drop superuser bypass). The merge-gate and superuser-bypass items in the original list shipped with that PR; these two remain.

The two open questions

1. Delete/rename cascade

Today: A user can delete or rename a sandbox if they are owner/admin of the sandbox itself, or owner/admin of the absolute workspace root. The "root cascade" lets a workspace owner manage any sandbox underneath.

Question: keep the cascade, or drop it so only direct admin/owner of the sandbox can act?

2. Parent-admin floor

Today: A user who is admin or owner on any parent project cannot be removed from a descendant sandbox, even by the sandbox's own owner. The floor is enforced both at the UI (Remove button disabled) and at the data layer (Projects.delete_project_user! raises).

Question: keep the floor, or drop it so a sandbox owner has full control over the sandbox's membership?

Why they're coupled

Both are "the workspace owner has special powers over descendant sandboxes" rules. Dropping the cascade makes the floor a one-off exception with no underlying rationale; keeping the cascade keeps both rules consistent with each other.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status

    New Issues

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions