Skip to content
GitLab
Next
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 44,769
    • Issues 44,769
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,331
    • Merge requests 1,331
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #328680
You need to sign in or sign up before continuing.
Closed
Open
Issue created Apr 22, 2021 by Andrei Stoicescu@astoicescuContributor

FE Research Issue: Give SaaS group owners control over accidental user overages via a `User Cap` setting

This issue is meant to break down the Front-End needs of the feature described in &5803.

Reference

  • Designs: #321934 (closed)

  • Steps flow for Self-Managed User added while User Cap enabled and SaaS Member added while User Cap enabled: &5803 (comment 556204466)

  • Useful info from the docs about GitLab.com Subscriptions: https://docs.gitlab.com/ee/subscriptions/gitlab_com/

Why should we implement this feature in SaaS, but not in Self Managed?

At the moment, only Self Managed admins can already control accidental user overages by making use of the option of setting User Caps through the Admin Settings section, like this:

This setting is available in Admin Area > Settings only for instance admins. This means that this section is not available for .COM admin customers.

We need to provide this option to .COM admin customers, but as they lack access to an Admin Settings section, we need to provide them this option elsewhere: at the Group/Project > Settings level.

Initial breakdown

  1. [FE] SaaS - Add Pending Members tab to seat usage page
  2. [Docs] SaaS - Document Pending Members tab in seat usage page
  3. SaaS - Move "Allow users to request access" setting to a new subsection
  4. [UserCap FE]: Add feature flag (closed as FF will be implemented in BE issue #332590 (closed))
  5. [UserCap FE][Pending members tab]: Add pending approval users
  6. [UserCap FE]: Add "User cap" setting to Membership area in group Settings > General
  7. [UserCap FE]: Show warning banner when adding users above user cap
  8. [UserCap FE][Invited members tab]: Add pending SaaS users to "Invited" members tab
  9. [UserCap FE][Invited members tab]: Add a “Pending owner approval” badge for members
  10. [UserCap FE][Invited members tab]: Add an “Awaiting user signup” badge for members
  11. [UserCap FE][Pending Members tab]: Add "Approve all" button
  12. [UserCap FE]: Warn group owners when changing User Cap related settings about automatically approving users
  13. [UserCap FE][Auto approval modal]: Show exact number of auto approvable members
  14. [UserCap][Pending Members tab]: Add confirmation modal for "Approve all" action
  15. [UserCap][Pending Members tab]: Add confirmation modal for "Approve" action

Extra notes

  • setting "Prevent adding new members to project membership within this group" (design) is NOT tied to this issue, even if it appears on the design
Edited Jun 28, 2021 by Andrei Stoicescu
Assignee
Assign to
Time tracking