Skip to content

[SM - Iteration 2] Don't Allow Guests to Move Themselves Into a Paid Seat

Problem to solve

Currently, a Guest user can move themselves into a paid seat by creating a project in their personal namespace or by creating a new group (there by elevating themselves as Owner).

This means that admins have less visibility and control over whether or not a user takes up a paid seat.

https://docs.gitlab.com/ee/user/permissions.html#free-guest-users-ultimate

Proposals

Recommendation: Iteration 1 + Iteration 2 -- Option A (or B pending outcome of <del data-sourcepos="11:226-11:233">data</del>) but open to all pathways: Iteration 2 -- Option D, per discussion here

Question Iteration 2 -- Option A Iteration 2 -- Option B Iteration 2 -- Option C Iteration 2 -- Option D
Audience

All Ultimate SM customers with who are adding new guests

 All Ultimate SM customers with guests All Ultimate SM customers with guests All Ultimate SM customers with Guests
Solution

Make all newly created guests external by default when created. This will only impact guests created going forward.

 Not allow guests to create personal projects + group Create an additional setting, which can be additionally enabled to limit the behavior of Guest users for SM instances who have this issue, and only after monitoring the usage of the additional setting, we should make it globally enabled by default. Create a Global instance level setting to allow Admins to disable Guest users from creating personal projects
What we need to pursue this solution

An understanding from engg if this solution is even viable.

UI change that makes it clear to the Admin that this Guest user is being added as "external" and what that means. Ideally, it's an option that they can override, which is getting handled here.

Data! See my comment here to Neil about this https://gitlab.com/gitlab-data/product-analytics/-/issues/1383

Confirmation Option B or Option A is not viable as well as UX

Discussed and decided here
Downside

Existing / newly created guests would have a different set of rules assigned to them by default, which could cause confusion. This might solve 60% of the problem, but we may have to follow-up with something like Iteration 2 -- Option C per Chase's comments here around edge cases.

 If guests are commonly creating personal projects, this change would be quite restrictive and could create lots of feedback in our user base. Although this is an unknown, my guess is this is the most complicated of the solutions. We are also create another control for the customer to learn/understand. A new control for customer to learn/understand.
Upside Would "stop the bleeding" of this problem for any guests created going forward. Cleanly fixes the problem without customer action required A less disruptive fix if guests are commonly creating personal projects A less disruptive fix if guests are commonly creating personal projects
UX

#419645 (closed)

 Not yet created Not yet created
Next Steps

Edited by Suraj Tripathi