Customers do not have a way to pull an accurate list of permissions based on role or permission source. The current exports do not factor in membership type, inheritance location, or path.
Proposal
New User Role Export Function
Create a new export endpoint that will list all users along with their associated permissions at each group and project level. This export will be sent as CSV via email notification.
Name
Username
Email
Path
Role
Membership type
Membership source
Access granted
Access expires
Last activity
{First Name} {Last Name}
{username}
{email}
{group}/{project}
{default role} or {custom role}
Direct, Inherited, Shared
{group}/{group}
{date}
{date}
{date}
Fields
Username/Name: There will be multiple rows for the user, because indirect/direct can result in multiple entries of access.
Path: The current membership path such as group, subgroup, or project level.
Role: This is the calculated and final role of the user between the three membership types.
If you are unsure about the correct group, please do not leave the issue without a group label, and refer to
GitLab's shared responsibility functionality guidelines
for more information on how to triage this kind of issue.
Joe Randazzochanged the descriptionCompare with previous version
changed the description
Joe Randazzochanged title from Iteration 1: Export an accurate record of users and their permissions for a group to Iteration 1: Export an accurate record of users and their permissions
changed title from Iteration 1: Export an accurate record of users and their permissions for a group to Iteration 1: Export an accurate record of users and their permissions
Joe Randazzochanged the descriptionCompare with previous version
changed the description
Joe Randazzochanged the descriptionCompare with previous version
@jrandazzo For self-managed I suggest we make some improvements on the current export function and user>account detail to reflect custom roles (when assigned to user). Then, have the new function in Roles/Permission page for role auditing, wdyt?
@jayswain@jarka Iteration 0.5 is not blocking. Those are existing export functions that can be updated with custom role name value. Iteration 1 is a separate export function.
@jrandazzo I'd like to clarify how this export differs from the one on the group members page.
I see the difference is that for the current export, we simply export all members of a certain group. Every user who is a member has exactly one row, even if they have multiple memberships.
But for this new export we want to get a group, all its subgroups and projects in the hierarchy and for every group/project we want to have a row for every user who is a member of that entity. Do I understand that correctly?
@jrandazzo reviewing the description and I wanted to note some columns we discussed that would be valuable to include for either this issue or a follow up:
Group or Project Name - path gives this information but would be a good addition to also include the given name
To help admins determine where to make user's role changes:
Max role
Membership source role (since membership with attached role can come to a group or project multiple ways: direct, indirect and shared and is evaluated to arrive only at a single role defined by role column)
Perhaps would be better as a separate report in follow up issue, help admins audit role changes:
To be able to export the data (role prior to change, role update date, role updated by) from audit events we would have to search audit events for all users that are being exported. We could relate "role updated by" but we would have "role prior to change" only in text format (which I suppose is fine for the export) 🤔
Could you create a follow-up issue? This is probably not a trivial request.
@dftian Would you be able to break down the FE issues for this? See the UI and Figma docs in the issue description. If you have any questions, please reach out to myself or @ipelaez1.
@jrandazzo@ipelaez1 The frontend work for this should be very straightforward, it's just a button, modal dialog, and an alert. The bulk of the work will be backend; should we create a new FE-specific issue, or use this one?
@jrandazzo some additional thoughts on the problem and goal:
pull an accurate list of permissions
How will we measure the success of accuracy? In reading through the customer issues in Group Members CSV Export List doesn't match UI ... (#390358), there is confusion and inconsistency which stems from their ability to tie in the existing export to the UI (member page).
We discussed a way to solve for confusion by providing an accompanying doc to explain how each data field is derived for the new export.
Do you know of any existing issues in the member page UI that could still read as a mis-match or inconsistent result in comparison to this new export? cc: @mnichols1 and @lohrc
@ipelaez1 This depends on the scope on where we report this from the UI. Let's consider two scopes:
Full: All users and their assignments to all groups and projects. (This issue)
Group: User membership of X group
Roles and permissions page
From the Roles and permissions page, I would expect Full scope to be used. (Current focus on this issue)
Members page
Problem-set with the members report:
It displays descendant permissions of the group. This is confusing to the users. I believe it would be inherited/indirect/direct of the group and above as this reflects the members page.
Missing the source of membership
I've revisited the original implementation and can see the confusion because it recreated the instance report to be placed at the root group level which then was repeated for each group. The confusion is driven by the placement of the export button versus the original job to be done (full scope). This raises an important question:
Will a user really need to export a group scope from the membership page, or do they just need a Full scope to export all users?
If no, then should we revisit if the membership page should have an export to prevent confusion altogether?
Will a user really need to export a group scope from the membership page, or do they just need a Full scope to export all users?
If no, then should we revisit if the membership page should have an export to prevent confusion altogether?
The current export is scoped to the group from what I have tested. I think there is a case to be made for both, and it probably depends on the permission setup and management of the user. We have users that want strict control by their admin/top-level group Owner over all access management, and they would most likely want to have a full report. But we also have customers that trust their group and project Owners to manage permissions for their groups and projects. For these cases, group and project Owners would benefit from the same report. We have users that have 100s, in some cases 1000s of members in groups and projects, so getting an overview per group in these cases is still a valid problem to solve. The way access is managed can differ significantly between industries and also the size of an implementation. See also https://docs.gitlab.com/ee/user/group/#group-structure.
@jrandazzo@jayswain I am wondering if this issue is meant only as backend issue or it includes also frontend. Adding a button is something even I could probably do. But with the modal, it gets more complex and I would probably need help there. 🤔
Jaychanged title from Iteration 1: Export an accurate record of users and their permissions to [BE] - Iteration 1: Export an accurate record of users and their permissions
changed title from Iteration 1: Export an accurate record of users and their permissions to [BE] - Iteration 1: Export an accurate record of users and their permissions
@jarka Good question. The export functionality with fall within the Premium Tier. I've added a tier breakdown on the epic here to keep track of the changes.
The page itself can only be viewed Ultimate users today. We will need to evaluate when to open that page up Premium users. My initial thought is to allow Premium users when both Default and Custom Roles are displayed on that page based on work from this issue.
@jrandazzo as the algorithm MR is in the initial review, I started working on the endpoint itself. So as you suggest leaving this functionality within Premium tier, I will check for export_user_permissions feature, which we have defined for premium.
@jrandazzo they are internal APIs but I suggest (and also started building graphQL endpoint) we create this external as try to access endpoints via GraphQL.