Skip to content

Adds Finder to query Nonbillable Users for Promotion mgmt

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).
  • This issue deals with adding that Promotion control for the Invite New Member flow.
  • 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)

What does this MR do and why?

This MR is part of a wider change, broken down for ease of review
Database changes + Model Changes to Queue Member Approvals !154552 (merged)
Adds Finder to allow querying Nonbillable Users to be queued for promotion <---- You are here
Modifies existing Service to allow queuing Invited Members, (we have used the above two here) !156801 (merged) (in parallel review)
Call the service modified above through Creator Service add_members method !156891 (merged)

This MR:

  • Adds new finder to pre-emptively query non-billable users, given a list of user_ids
    • We were relying on individual is_using_seat method to check per user. But we decided to move away from per individual query based on feedback here
      • is_using_seat uses highest_role which can be stale, so might result in False Negative evaluation of Promotion. We could use a version of billable? method instead.
      • But multiple individual query per user is not very performant.
  • This finder makes use of the existing billable scope to exclude billable users from the given list of user_ids
    • A parallel effort to write an original non-billable scope was done here, and eventually discarded.
  • The maximum number of user_ids from a promotion management usecase is 50, so the queries are benchmarked for 50 users.

EE: true Changelog: changed

ref: #433179 (closed)

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

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Edited by Suraj Tripathi

Merge request reports