feat: [PLAT-5936] Allow-list support for private studios - #649
Merged
Conversation
sabulous
requested review from
georgi-seqera,
t0randr and
weronikasosnowskaseqera
July 22, 2026 10:14
georgi-seqera
approved these changes
Jul 24, 2026
georgi-seqera
left a comment
Contributor
There was a problem hiding this comment.
awesome, looks good to me 👍
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Ticket: PLAT-5936
This PR adds CLI support for the private-studio allow list — the users, besides the creator, who may connect to and start a private studio.
Changes
Set the list on add — Set the allowed user when creating a private studio with the
--allow-user <user>option (available on add, add-as-new, and start), where<user>is a numeric user ID, username, or email. The platform currently caps the allow list at a single additional user, so the option takes a single value.Name/email resolution — a non-numeric
--allow-uservalue is resolved to a user ID by looking it up among the organization's members and then its collaborators (a workspace participant may be either). A numeric value is used directly. The backend still enforces that the resolved user is a workspace participant.Override the list on start —
start --allow-userreplaces the existing allow list; omit it to leave the list unchanged. Only the studio creator may change it.Note: the override only applies when the studio is startable (stopped) — starting an already-running studio won't change the list.
Studio view shows the allow list — the studio view now includes an Allowed users row.
Lookup-by-name returns full detail —
view -n(andstart/updateby name) now fetch the full studio viadescribeafter resolving the name, so name-based lookups match id-based ones (the list response omitsallowedUsers).Example cli testing session with various cases
Create a private studio with an allowed user (by id)
The allowed user can also be given by username or email
Reject at the CLI: --allow-user given more than once
Reject: a user who is not a member of the workspace
Replace the allowed user on start (creator only; studio must be stopped [user 8 below is permiss@seqera.io])
Start without --allow-user leaves the list unchanged