Skip to content

Sync membership to organization_users table on membership create

Summary

When a user becomes a member of a group or project they implicitly gain access to the parent Organization. This access is noted by an entry in the organization_users table. We need to ensure an entry exists on member creation.

Context/Why

Generally, the users overview should show everyone that an Organization Owner can manage. This includes members of all groups and projects within that Organization, incomplete invitations, and in a future where internal visibility exists for SaaS customers as well, also accepted invitations where the user might not have joined a specific group or project yet. It should not include everyone who has ever interacted with the Organization, for instance on a public project, without actually being a member of it.

Provides quickly accessible information that is organization-level of who is the part of Organization. Organization_users will gain access (from reporter up) to internal projects.

more context here and here.

Implementation guide

  • organization_users and members is gitlab_main_cell, we will need to use a process to update the organization_users table. See final implementation decision in #419366 (comment 1695573766)
  • reasoning for placement at model layer - #419366 (comment 1498129831)
  • idea: use upsert - #419366 (comment 1681402641)
  • create/use a feature flag, update_organization_users, to guard the functionality as it is impactful to a frequent code path in GitLab

Availability & Testing

  • No End to End tests needed, only Unit / Integration
  • We should monitor performance (wrap a test in rspec-benchmark?)

Areas to handle

Edited by Doug Stull