Workspaces can be created under user or project namespaces (#417894) · Issues · GitLab.org / GitLab

Workspaces can be created under user or project namespaces

<details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=417894) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=417894) </details>  MR: Pending   ## Description `As a workspaces user, I want to be able to start a workspace under my personal user namespace so that I am not required to create it under a group.` This should likely be expanded to include `ProjectNamespace` as well, as the changes to policies should be very similar and we [already will have the actual policy logic abstracted and reusable](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145387#note_1837834104). Related discussions and issues: - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145387#note_1837834104 - https://gitlab.com/gitlab-org/gitlab/-/issues/417894#note_1842375075 - https://gitlab.com/gitlab-org/gitlab/-/issues/444860+ ## Acceptance Criteria - [ ] Users can create workspaces under their user namespace - [ ] Cleanup up all unnecessary creation of group fixtures in the specs. E.g. just use `agent.project.project_namespace` instead of unnecessarily creating the agent's project with a group. We can still have some isolated integration-level tests (e.g. one of the `main_integration_spec.rb`) to test all possible namespace sub types: `Group`, `UserNamespace`, `ProjectNamespace` ## Technical Requirements See [this thread](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145387#note_1837834104) on https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145387+ for a patch with a preliminary implementation of this. NOTE: The following collapsed section contains the previous Technical Requirements section, but this is likely outdated and irrelevant due to the implementation of https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145387+ and https://gitlab.com/gitlab-org/gitlab/-/issues/444860+ <details><summary>Previous Technical Requirements (outdated)</summary> See [this internal slack thread](https://gitlab.slack.com/archives/C03KE0L9NC9/p1688670374483219) for a discussion and investigation of this. Here are some notes from that thread around the investigation: --- Looking at the code for this, haven’t had time to debug it yet, but leaving notes here for when I (or someone else) can: * We use the `ee/app/assets/javascripts/remote_development/graphql/queries/get_group_cluster_agents.query.graphql` query * Which is in the scope of the “group” (in this case a user namespace) * Which uses the pre-existing cluster agents resolver `app/graphql/resolvers/clusters/agents_resolver.rb` * Which uses the pre-existing finder `app/finders/clusters/agents_finder.rb` * Which looks up in the context of the “group” using `#cluster_agents` in `ee/app/models/ee/group.rb` * Which uses `all_projects`, which has this definition: ``` def all_projects namespace = user_namespace? ? self : self_and_descendant_ids Project.where(namespace: namespace) end ``` You can see here if the “group” is a `user_namespace`, then it’s defined as **ONLY** the projects for the current namespace. So, presumably this **SHOULD** pick up the agent if it’s on a project **somewhere** in the same `user_namespace`. But it doesn’t seem to be. Interestingly though, it does seem to pick it up if it’s in the same project: > As an aside, I CAN create a workspace where the devfile and cluster agent reside in the same repo. This knocks out one of the possibilities we were looking at earlier in the conversation. Would have to debug this scenario to see exactly what’s going on. --- Looking at the code for this, haven’t had time to debug it yet, but leaving notes here for when I (or someone else) can: * We use the `ee/app/assets/javascripts/remote_development/graphql/queries/get_group_cluster_agents.query.graphql` query * Which is in the scope of the “group” (in this case a user namespace) * Which uses the pre-existing cluster agents resolver `app/graphql/resolvers/clusters/agents_resolver.rb` * Which uses the pre-existing finder `app/finders/clusters/agents_finder.rb` * Which looks up in the context of the “group” using `#cluster_agents` in `ee/app/models/ee/group.rb` * Which uses `all_projects`, which has this definition: ``` def all_projects namespace = user_namespace? ? self : self_and_descendant_ids Project.where(namespace: namespace) end ``` You can see here if the “group” is a `user_namespace`, then it’s defined as **ONLY** the projects for the current namespace. So, presumably this **SHOULD** pick up the agent if it’s on a project **somewhere** in the same `user_namespace`. But it doesn’t seem to be. Interestingly though, it does seem to pick it up if it’s in the same project: > As an aside, I CAN create a workspace where the devfile and cluster agent reside in the same repo. This knocks out one of the possibilities we were looking at earlier in the conversation. Would have to debug this scenario to see exactly what’s going on. --- </details> ## Implementation Guide See Technical Requirements section above, which contains a link to a comment with a preliminary patch implementation. NOTE: The following collapsed section contains the previous Implementation Guide section, but this is likely outdated and irrelevant due to the implementation of https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145387+ and https://gitlab.com/gitlab-org/gitlab/-/issues/444860+ <details><summary>Previous Implementation Guide (outdated)</summary> If this gets picked up as ~"Seeking community contributions", please see the "Technical Requirements" section above. The main thing needed to move this issue forward is to explore the behavior of the `all_projects` method, and explain why it does not pick up projects under a user namespace. This initial investigation should not require you to set up or necessarily know anything about Workspaces or the Remote Development feature. </details> ## Design Requirements No UI changes needed, this is only changing the underlying declarative policy authorization rules. ## Impact Assessment This will allow wider adoption and usage of the Workspaces feature, by not requiring usage of or access to group-level authorization when mapping agents and creating workspaces for those agents.

issue