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. -
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.
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 |
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
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
|
Maintainer or below |
|
Block and alert that request is pending approval from admin or owner
|
SM
UI When a user individually changes a |
API | |
---|---|---|
Admin |
|
Provide warning message
|
Maintainer or below |
|
Block and alert that request is pending approval from admin or owner
|
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
- There was an effort to add messaging for QSR when a
-
[SM] Create transparency about User Overage process
- For SM purposes, the above epic gives us a good idea of any edge cases