Organizations own Projects

Add an organization_id column to the projects table. Add the Rails associations.

Probably default organization_id = 1.

Written by @ayufan at #408175 (comment 1360612833)

I would advise that each top-level group, sub-group and project in a hierarchy does have organization_id to be set to point to organization owning this project and group, not only top-level.

This level of data duplication becomes handy in the future to easily query all belonging to organization, especially required to show filtered list of projects or groups, or quickly limit visibility of project based on organization_id. This will make all isolated queries to

This duplication basically has no up-front cost, but a ton of benefits:

• we can cheaply filter-out top-level groups (has_many :top_level_groups, -> { where(parent_id: nil) })
• we can cheaply access organization from any place
• we can easily filter out all group, projects that belong to given organization when doing find
• we can easily fetch all projects and groups in organization - which is very handy for all API accesses that are listing resources
• the downside only being: if we move group into organization, all subgroups and projects needs to be updated

Example use-cases:

1. Filter groups in dropdowns when creating new project
2. Make /api/v4/projects return all projects of your current organization
3. Make /dashboard/explore show all projects only from your organization
4. Referenced issues from another projects in a comments can be cheaply filtered in a single SQL query, in a current context by adding projects.organization_id condition check without having to do cross-join
5. And more...