Ability to add/list/remove group members of groups and projects using the API
Problem to solve
The current API endpoints to see members of a group or project only lists user accounts, not any groups that have access to the targeted resource.
- GET /groups/:id/members/all
- GET /projects/:id/members/all
Adding a member to a group requires a user_id, so it's not possible to add a group as a member to another group or a project.
Using the web gui this concept is possible.
A setup could look like this:
Under the group called members
there are two groups for roles created our-developers
and our-maintainers
, these can then be given access to other groups or projects.
Browsing to the projects
group and viewing the members section we can see both users who have access as well as groups that have access. Using the API it's not possible to see that the our-developers group have access (with the developer permission).
Intended users
Further details
As the current API only lists the users that have access to a specific group or project some of the actual access might be hidden from the API.
Proposal
It would be great if the current members endpoints could be expanded upon so that it's possible to perform CRUD operations of groups that are members of groups and projects using the API. Perhaps by adding a /group-members
endpoint to avoid issues with backwards compatibility.
Permissions and Security
The permissions should work exactly the same as the current API endpoint for /members
Documentation
Either the members API documentation would need to be expanded, or a new page for /group-members would need to be created. https://docs.gitlab.com/ce/api/members.html
Availability & Testing
Similar tests as those done for the current /members API
What does success look like, and how can we measure that?
When it is possible to add, list, update and delete group members to a project or another group.
What is the type of buyer?
In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
I would view this as a core feature since information is missing in the current API.