We want to make `Organization` a required attribute of `Namespace`. We have three types of namespaces (`Group`, `Project`, `User`). This is about `UserNamespace` , ie Personal Namespaces. They also need an Organization When we create an User, we create two relations to Organization: - Direct: Add an entry to `organization_users` table. This establish Organization membership - Indirect: Add a user namespace. A User namespace needs (just like all namespaces) an Organization For human users, there is no issue: they will be assigned to an organization. The personal namespace will be part of that organization. For non-human users, we need to decide: - What organization they are member of (considering the scope of the bot) - Do we need personal namespaces for those? And if yes, what organization to use for that? ## User types | USER_TYPES | id | Just one? | Scope | Used by group | Contact | |------------|----|-----------|-------|---------------|---------| | `human` | 0 | NO | Organization | gitlab~33056464 | N/A | | `support_bot` | 1 | YES | Instance | gitlab~10690691 for service desk | @donaldcook @gweaver | | `alert_bot` | 2 | YES | Instance | \~"group::respond" for alerts | None, community-led category | | `visual_review_bot` | 3 | YES | Instance | gitlab~10690708 see <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/458442">removal</a> | @drew @rutshah | | `service_user` | 4 | NO | Unsure. Check if it can be removed | gitlab~10046106 Not a bot but <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/198438">user type</a> | @blabuschagne @hsnir1 | | `ghost` | 5 | YES | Instance | gitlab~33056464 for user deletion | @adil.farrukh @hsutor | | `project_bot` | 6 | NO | Organization (group/project account) | gitlab~33056464 for PrATs | N/A | | `migration_bot` | 7 | YES | Instance | gitlab~10309854 for Snippets | @dpoosarla @mcbabin | | `security_bot` | 8 | YES | Instance | ~"group::security insights" for vuln fix MRs | @ryaanwells @svedova | | `automation_bot` | 9 | YES | Instance | gitlab~10690691 to generate iterations | @donaldcook @gweaver | | `security_policy_bot` | 10 | NO | Organization (Project scoped) | gitlab~10690753 for security policy pipelines | @alan @g.hickman | | `admin_bot` | 11 | YES | Instance | gitlab~33056464 admin ops on SM | @adil.farrukh @hsutor | | `suggested_reviewers_bot` | 12 | YES | Instance | ~"group::code review" for suggested reviewer token | @francoisrose @phikai | | `service_account` | 13 | NO | Self-managed: Instance. SaaS: Organization | gitlab~33056464 for service accounts | N/A | | `llm_bot` | 14 | YES | Instance | gitlab~31287875 for content attribution | @mnohr @jordanjanes | | `placeholder` | 15 | NO | Organization | gitlab~40896338 | | | `duo_code_review_bot`. | 16 | YES | Instance. | gitlab~31287876 | | ### Scope: Organization These are User Types that are now related to a Group (or Project). If we create a User, we know the Organization we are currently working in and we can assign both the User Namespace and the Organization Membership to the Organization ### Scope: Instance They are created on the fly, when needed. These users are not related to a specific Group / Project which makes it difficult to assign these to an Organization. For example, `ghost_user` is used to replace deleted users. It works across Organizations Some ideas - Assign these Internal Users to an (hidden?) Bots or Cells Organization - Do not assign these users to an Organization #### Assign these Internal Users to a 'Cells' or 'Bots' Organization Create a special Cells organization that can be used to accomodate different tasks related to the managed of Cells. It will serve as a Cells-level container, similar to current Instance-level All cells will have one Cell Organization #### Do not assign these users to an Organization These users will still be created on the fly on each cell but they are not part of any Organization. We do not create a Personal Namespace for them (because we do want all namespaces to be part of an Organization)