UX - Review user cap flows

Problem

As part of better handling non-billable users to enhance user caps, for both SaaS and SM, we want to understand the implication of not counting Guest Users in Ultimate Subscriptions towards billable users.

User caps should not restrict users with guest permissions to sign up (i.e guests are excluded/bypassed from user caps).

As outlined in the epic, before tackling the Guest Users we should have additional controls in place to not cause more problems when tackling exclusion of Guest Users.

How to approach this problem

Current issues we think should be tackled first:

• Guests should not be able to move themselves into a paid seat
• Admins should have control over/approve when a guest role moves into a paid seat

Outcome

• Review current user cap flows.
  • FE: Add `User Cap` setting for licensed self-managed GitLab
  • UX: Give SaaS group owners control over accidental user overages via a `User Cap` setting
• Review current blocking issues (see above)
• Outline or highlight any additional gaps in the experience that need to be addressed

At best this is an actionable breakdown of work items/issues we can collaborate towards.

Recommendations

[SM] Don't allow Guest users to move themselves into a paid seat

Original Contributions

Questions/Thoughts

• Are there any insights into how a Guest uses a personal project or if they need one? I haven't been able to find anything within our dovetail archives.
• Further investigation is needed as to whether there are other ways of creating projects/groups, i.e., via the API.

High-level proposal

• My recommendation here would be to prevent Guest's creating personal projects (which is option 1 in the proposal list)
• This would mean removing the ability to create projects + groups from the main screen and left-side menu.

Screenshot

Proposal: Create a Global instance level setting to allow Admins to disable Guest users from creating personal projects

Customer Experience	Description	Proposed Design	Do we need to make any changes?
Admin inviting user	Within a Group/Project a user can be invited specifically as a Guest. If Admin is inviting a user, this would be the time to explain the External restriction and allow them to override by perhaps unchecking a checkbox selected by default.		Yes, add checkbox that is on by default indicating external is the default setting
Viewing pending approval	Where you can already see who pending approval		No, already built
API Message	Users can be added as Guest to project/group via the API. In this scenario I'm not sure too much would need to change. Only change we could leverage here is utilize the message section in a response. And let the Admin know the Guest was added successfully but as External with restrictions.	Example of a response https://docs.gitlab.com/ee/api/invitations.html#add-a-member-to-a-group-or-project	Yes, update API response with message about external being on by default
Admin Universal Controls (also applicable for Option D)	This would allow Admins to adjust the setting according to their specific needs.		Yes, We could re-purpose the existing permissions, which in the Admin Area > Settings > General on an SM instance, and turn it into a radio option instead: Set new users to external Set all newly registered users as external by default Set all newly registered Guest users as external by default The first radio option which we currently have today would override the second. WDYT?
Sign-up + Admin Approval	When admins are approving guest sign-ups		Yes, add language that guests are external and what that means

Add Controls for Ability to Promote Guest Users

Questions/Thoughts

• The experience for SM will be slightly different to that of SaaS which is to be expected.
• Further investigation is needed as to whether there are any edge cases for promoting a Guest's role.

High-level proposal

Table is currently leaving API and SaaS flows outside. See more details here &12141

Iterations \ flows	When inviting new users to billable positions	When promoting users to billable positions
iteration 1 (SM)	Maintainer invites a user to a `> Guest` role — we silently accept that request. We don't show any messages to the actor yet. In group admin panel, we add that user to the "Invited" tab. In the instance admin panel we display this promotion request in a "Pending approval" tab, for admin to approve. If admin invites a user — that user get's added instantly (current flow).	Maintainer promotes user from non-billable to billable position. We don't show any messages to the actor yet. Question: how do we display that pending promotion state? In the instance admin panel we display this promotion request in a "Pending promotion" tab, for admin to approve. If admin promotes a user — that user get's promoted instantly (current flow).
iteration 2 & 2+ (SM)	Add messaging before and after addition.	Add messaging before and after addition.

Original Proposals

SaaS

	UI When a user individually changes a Guest's role that would convert them into a billable user or when a group is invited into another, we follow a similar pattern to User Caps.	API
Owner	Provide warning message (similar to Owner API message) to owner when they try to promote a guest to a higher role via project sharing that they must accept in order to complete action of moving guest to higher role.	Provide warning message This request will move [XX] user[s] into a billable seat. Are you sure you want to proceed?
Maintainer or below	Message the user that made the request, informing them that approval is needed. Show this information in the invited tab in the member's list. Notify Owner and Add this request to the pending tab. Show a message on the usage quotas page for the group Owner's.	Block and alert that request is pending approval from admin or owner This request would move [XX] user[s] into a billable seat and required Owner approval

SM

	UI When a user individually changes a Guest's role that would convert them into a billable user or when a group is invited into another, we follow a similar pattern to User Caps.	API
Admin	Provide warning message (similar to Admin API message) to owner when they try to promote a guest to a higher role via project sharing that they must accept in order to complete action of moving guest to higher role.	Provide warning message This request will move [XX] user[s] into a billable seat. Are you sure you want to proceed?
Maintainer or below	Message the user that made the request, informing them that approval is needed. Show this information in the invited tab in the member's list. Notify Admin and Add this request to the pending tab.	Block and alert that request is pending approval from admin or owner This request would move [XX] user[s] into a billable seat and required Admin approval

Further resources

• [QSR] [SaaS] Create transparency about User Overage process at the time of adding users
  • There was an effort to add messaging for QSR when a Guest moved into Billable seat
  • For SaaS purposes, the above epic gives us a good idea of any edge cases
• [SM] Create transparency about User Overage process
  • For SM purposes, the above epic gives us a good idea of any edge cases