Add MINIMAL_ACCESS user statistics

Summary

As discussed in #342125 (closed), we currently have no visibility into the billing of MINIMAL_ACCESS members in the User Statistics

Although we include these members in our billable member counts (unless on Ultimate), they're not added to the statistics, e.g.

So, given the following scenario:

Group A has 4 billable members:

• 1 No project or group
• 1 Minimal Access
• 1 Guest
• 1 Maintainer

Visiting their user stats, they'll see a billable total of 4, but only see a breakdown for 3.

Proposal

As confirmed here #342125 (comment 694781105), we should add this user level to the breakdown to add clarity and visibility for billable members.

1. Add a new column to the user_statistics table for with_highest_role_minimal_access
2. Update the UserStatistics model to include this new level
3. Update the UI to display the count

Considerations

The MINIMAL_ACCESS role is only available in EE (Premium+) so we should consider conditionally displaying the statistics etc. based on that

changed milestone to %Backlog

added backend devopsfulfillment featureaddition frontend grouputilization sectionfulfillment workflowblocked + 1 deleted label

set weight to 2

marked this issue as related to #342125 (closed)

added typefeature label

removed the relation with #342125 (closed)

@amandarueda I created this issue to split the effort out of #342125 (closed) as it's more in depth and this part can be handled independently.

I've added a weight of 2 because it has front, backend and DB work.

I suspect the frontend is likely a small change (I think we just need to add a new row here) and can likely be handled by whoever picks this up from backend

@vij which issue is this work blocked by?

@amandarueda you beat me to updating the label it's not blocked by anything, I originally thought it maybe blocked by the original issue (#342125 (closed)) but I changed my mind will update the label now!

mentioned in issue #342125 (closed)

changed milestone to %14.5

added workflowready for development label and removed workflowblocked label

added [deprecated] Accepting merge requests label

mentioned in issue gitlab-org/quality/triage-reports#4942 (closed)

mentioned in issue gitlab-org/quality/triage-reports#5011 (closed)

mentioned in issue gitlab-org/quality/triage-reports#5105 (closed)

mentioned in issue gitlab-org/quality/triage-reports#5172 (closed)

assigned to @aalakkad

added workflowin dev label and removed workflowready for development label

mentioned in merge request !73651 (merged)

removed [deprecated] Accepting merge requests label

added workflowin review label and removed workflowin dev label

I couldn't verify the changes on staging or production because it's under /admin/stats but verified locally after it got merged.

@amandarueda do we need to verify it on a real self-managed installation? if yes, do you know if we have a way to do it?

@aalakkad from gitlab.com staging:

I tried adding a user to a group with minimal access and don't see it in the role dropdown though

I don't see it in prod either - maybe it's not available on gitlab.com? firing up my SM instance ...

@amandarueda I had the same issue locally, it got resolved after deleting the license then uploading it again

But the good thing is that the new row is showing the table which is the purpose of this issue

Oh great! @aalakkad can you just post a screenshot of your example before closing? If you have any troubles just let me know and I can try it again.

On my end it looks like this

admin -> stats	adding a member

I'm thinking maybe it's like this (stats not updated) because my local instance is using .com features locally, it's not a "pure" self-managed one.

@amandarueda Do you want me to try verifying this on a real testing self-managed instance?

@aalakkad Did the feature ship in %14.5?

@amandarueda Yes, the feature got merged on the 12th and will be included in %14.5 once it's released.

ok great, let's close the issue for %14.5 in that case @aalakkad. When %14.5 is available, I'll upgrade my SM instance and test it in production. Acknowledging that this is not an ideal workflow, but since it's already merged and risk is low based on your initial tests, I think we can be flexible here.

@amandarueda verified on production self-managed instance (using nightly build to get latest changes), thanks to @sheldonled for creating the instance!

@aalakkad No problem I'll tear down that instance later today if we don't need it anymore

added workflowverification label and removed workflowin review label

removed backend label

changed milestone to %14.6

added missed:14.5 label

closed

changed milestone to %14.5

removed missed:14.5 label