馃帹 Design: Bring users to organizations
Goal
As one of the first iterations of building out the organization, we want to move the membership management functionality from the Admin Area to the group level. Currently, there are three distinct jobs-to-be-done for a user overseeing the organization in terms of user management:
- Seat usage: I need to assess how many unique users are in my organization, so that I can manage seat usage, as it relates to costs for my GitLab implementation (Users)
- Audits: I need to get an overview of all the groups and projects that a specific user is a member of, so that I can check whether they have access to all the correct places. I need to see a list of groups and projects they are a member of, including the role they have at each level. (Users)
- Membership: I need to understand who the members of a specific group are, and how they got there. Were they added individually or via group sharing?
The goal of this improvement is to satisfy all three use cases in a way that makes it easy for users to get a specific job done. At the same time, we should keep in mind that we are working towards unifying the views for member management between groups, projects and the Admin Area.
Proposal
First iteration
- The owner of the top-level group/organization has membership management capabilities
- In addition to the Owner, users will only be able to see the users page, but are limited to seeing what they have access to as described here.
Design
- User links to the user profile page
Future iterations
- Adding user management capabilities to the organization, such as blocking and deleting a user (group owners cannot have this kind of power at the moment)
Open questions
In this issue
-
What is a user from the billing perspective #390205 (comment 1304580394) -
How does a user become a user of an organization #390205 (comment 1306040641) -
What user management is required #390205 (comment 1306041027)
Edited by Mike Nichols