Skip to content

Draft: Create internal users per-organization

What does this MR do and why?

Create internal users per-organization

Certain internal users that were previously system-wide will now be created and managed on a per-organization basis. This will allow us to package these users along with organizations and move them between Cells if necessary.

To-do

This MR will be large and exist as a proof-of-concept to keep track of what code paths need to change for this approach to work.

  • New table storing user aliases
  • Use aliases in UserReferenceFilter to create appropriate mentions
  • Display aliases in Notes / MRs / Issues
  • Display aliases in autocomplete drop-down in composer
  • Check for aliases during Namespace / User / path creation ?
  • Include aliases in NamespaceExistence in GraphQL and /users/:username/exists endpoint

Not To-Do:

The footprint of the alias system should be limited to only what is required to support the functionality needed for bots created by Users::Internal , and should not extend to:

  • routes or routing
  • general querying of users via REST or GraphQL APIs
  • reserving usernames and namespaces
  • searching for users via the search bar

This functionality can be added later if desired.

Since an Organizations::UserAlias is not a username or namespace, we will not try and "reserve" these names using traditional mechanisms for namespaces. The following call sites check for reserved usernames:

References

Screenshots or screen recordings

Before After

How to set up and validate locally

  1. Confirm on your local installation that one of the above user types does not yet exist

  2. On the Rails console, create one of above users and ensure it does not have a namespace:

    org = Organizations::Organization.default_organization
    dcrb = Users::Internal.duo_code_review_bot(org)
    dcrb.persisted?
    dcrb.namespace.present?
  3. Go to a commit and leave a comment mentioning the above user: https://gdk.test:3443/flightjs/Flight/-/commit/8749d49930866a4871fa086adbd7d2057fcc3ebb#7030d0b2f71b999ff89a343de08c414af32fc93a_7_6

  4. Ensure that the mentioned user is still linked appropriately in the comment

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #442780 (closed)

Edited by Andrew Evans

Merge request reports

Loading