Applies pending promotion requests
Context
- As part of &13328 we are working on Adding controls for Admins/Owners to manage Billable Members promotion/addition in Groups and Projects (still a WIP feature).
- When PromotionManagement conditions are applicable(code)(primarily when user is non-billable and the current change would make them billable), we want to queue the User/Member Addition/Promotion request if that addition/promotion will increase the Billable count for the SM instance (We will bring this to SaaS eventually)
- This would mean queuing that request in a MemberApprovals table
- There are issues to deal with adding that Promotion control for the Invite New Member flow.
- Allowing Admin to view the requests (closed)
- Approve/reject it (this MR belongs to this issue)
- This issue deals with applying/denying the already queued pending promotions, when Admin approves/rejects the request.
- PS: this feature is behind a disabled feature flag and setting, so it isnt available on prod.
What does this MR do and why?
Applies Pending Promotions for the passed user, there by adding membership for the user in all the pending sources.
- This MR is based on top of this initial MR that added the mutation that just updated the MemberApproval objects with the status that was passed through the mutation.
- This MR
- modifies the service to actually apply each MemberApproval if the request for the user is Approved
- denies the request if the request is denied.
ref: https://gitlab.com/gitlab-org/gitlab/-/issues/433176
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
How to set up and validate locally
- Have an Ultimate License, and simulate Ultimate Self Managed setup (
export GITLAB_SIMULATE_SAAS=0
) - Enable Setting
setting = ApplicationSetting.first; setting.enable_member_promotion_management=true; setting.save!
- Enable FF
Feature.enable(:member_promotion_management)
- Create promotion requests:
- Visit any Group as an owner of that group (e.g.
http://127.0.0.1:3000/groups/gitlab-org/-/group_members
) - try promoting a non-billable GUEST member to a DEVELOPER role (this member should be non-billable on the whole instance, i.e. have a highest role as guest, see !149094 (comment 1869616221) for details)
- you should see a banner saying "Role change request was sent to the administrator." — this means a promotion request has been created
- Visit any Group as an owner of that group (e.g.
- Visit local graph-iQL page (http://localhost:3000/-/graphql-explorer)
- Get list of pending promotion users
-
Query for same
{ selfManagedUsersQueuedForRolePromotion(first:20) { count nodes { user { id username } newAccessLevel { stringValue } } pageInfo { hasNextPage hasPreviousPage startCursor endCursor } } }
-
Sample response
{ "data": { "selfManagedUsersQueuedForRolePromotion": { "count": 1, "nodes": [ { "user": { "id": "gid://gitlab/User/28", "username": "i-user-0-1705348657" }, "newAccessLevel": { "stringValue": "MAINTAINER" } } ] } } }
-
-
- Use the
id
from above list to promote the user-
Login as Instance Admin, and navigate to graphiQL page
-
Use the following mutation, and variable
mutation($processUserBillablePromotionRequestInput: ProcessUserBillablePromotionRequestInput!) { processUserBillablePromotionRequest(input: $processUserBillablePromotionRequestInput) { clientMutationId errors result } } {"processUserBillablePromotionRequestInput":{"userId":"gid://gitlab/User/93","status":"APPROVED"}}
-
Validate you get success response
{ "data": { "processUserBillablePromotionRequest": { "clientMutationId": null, "errors": [], "result": "SUCCESS" } } }
-
- Validate that the user is now promoted in the group you queued the promotions on.
- Validate the user is not getting returned in the
pending promotion users
list from above.
Edited by Suraj Tripathi