Skip to content

Applies pending promotion requests

Suraj Tripathi requested to merge 433176_apply_pending_promotions into master

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

Screenshot 2024-06-29 at 6.27.01 PM.png

How to set up and validate locally

  1. Have an Ultimate License, and simulate Ultimate Self Managed setup (export GITLAB_SIMULATE_SAAS=0)
  2. Enable Setting setting = ApplicationSetting.first; setting.enable_member_promotion_management=true; setting.save!
  3. Enable FF Feature.enable(:member_promotion_management)
  4. Create promotion requests:
    1. Visit any Group as an owner of that group (e.g. http://127.0.0.1:3000/groups/gitlab-org/-/group_members)
    2. 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)
    3. you should see a banner saying "Role change request was sent to the administrator." — this means a promotion request has been created
  5. Visit local graph-iQL page (http://localhost:3000/-/graphql-explorer)
  6. Get list of pending promotion users
    1. Query for same

      {
        selfManagedUsersQueuedForRolePromotion(first:20) {
          count
          nodes {
            user {
              id
              username
            }
            newAccessLevel {
              stringValue
            }
          }
          pageInfo {
            hasNextPage
            hasPreviousPage
            startCursor
            endCursor
          }
        }
      }
      1. Sample response

        {
          "data": {
            "selfManagedUsersQueuedForRolePromotion": {
              "count": 1,
              "nodes": [
                {
                  "user": {
                    "id": "gid://gitlab/User/28",
                    "username": "i-user-0-1705348657"
                  },
                  "newAccessLevel": {
                    "stringValue": "MAINTAINER"
                  }
                }
              ]
            }
          }
        }
  7. Use the id from above list to promote the user
    1. Login as Instance Admin, and navigate to graphiQL page

    2. Use the following mutation, and variable

      mutation($processUserBillablePromotionRequestInput: ProcessUserBillablePromotionRequestInput!) {
        processUserBillablePromotionRequest(input: $processUserBillablePromotionRequestInput) {
          clientMutationId
          errors
          result
        }
      }
      
      {"processUserBillablePromotionRequestInput":{"userId":"gid://gitlab/User/93","status":"APPROVED"}}
    3. Validate you get success response

      {
        "data": {
          "processUserBillablePromotionRequest": {
            "clientMutationId": null,
            "errors": [],
            "result": "SUCCESS"
          }
        }
      } 
  8. Validate that the user is now promoted in the group you queued the promotions on.
  9. Validate the user is not getting returned in the pending promotion users list from above.
Edited by Suraj Tripathi

Merge request reports