@@ -139,7 +139,7 @@ The initial iteration will provide a framework to house features under `Namespac
...
@@ -139,7 +139,7 @@ The initial iteration will provide a framework to house features under `Namespac
1.**Tier**: Is there any tier functionality that is differentiated by projects and groups?
1.**Tier**: Is there any tier functionality that is differentiated by projects and groups?
1.**Documentation**: Is the structure and content of documentation impacted by these changes at all?
1.**Documentation**: Is the structure and content of documentation impacted by these changes at all?
1.**Solution proposal**:
1.**Solution proposal**:
- Think big: This analysis provides a great opportunity to zoom out and consider the feature UX as a whole. How could you make this feature lovable based on the new structure, inheritance, and capabilities afforded by `Namespaces`? Is there any UI which doesn't comply with Pajamas?
- Think big: This analysis provides a great opportunity to zoom out and consider the feature UX as a whole. How could you make this feature lovable based on the new structure, inheritance, and capabilities afforded by `Namespaces`? Is there any UI which doesn't comply with Pajamas?
- Start small: What are the product changes that need to be made to assist with the migration?
- Start small: What are the product changes that need to be made to assist with the migration?
- Move fast: Prioritise these solution ideas, document in issues, and create a roadmap for implementation.
- Move fast: Prioritise these solution ideas, document in issues, and create a roadmap for implementation.
- Use FKs cascade delete or Rails callbacks to ensure when either a `Project` or its `ProjectNamespace` is removed its
for more information.
corresponding `ProjectNamespace` or `Project` respectively is removed as well.
-**Delete project:** use FKs cascade delete or Rails callbacks to ensure when a `Project`
- Transfer project to a different group.
or its `ProjectNamespace` is removed, its corresponding `ProjectNamespace` or `Project`
- Make sure that when a project is transferred, its corresponding project namespace is transferred to the same group.
is also removed.
- Transfer group.
-**Transfer project to a different group:** make sure that when a project is transferred,
- Make sure when transferring a group that all of its sub projects, either direct or through descendant groups, have their
its corresponding project namespace is transferred to the same group.
corresponding project namespaces transferred correctly as well.
-**Transfer group:** make sure when transferring a group that all of its sub-projects,
- Export/import project.
either direct or through descendant groups, have their corresponding project
- Export project would continue to only export the project and not its project namespace in this phase. Project
namespaces transferred correctly as well.
namespace does not contain any specific information that has to be exported at this point. Eventually we want the
-**Export or import project**
project namespace to be exported as well.
-**Export project** continues to export only the project, and not its project namespace,
- Import creates a new project, so project namespace is created through Rails `after_save` callback on the project model.
in this phase. The project namespace does not contain any specific information
- Export/import group.
to export at this point. Eventually we want the project namespace to be exported as well.
- As of this writing, when importing or exporting a `Group`, `Project`s are not included in the operation. If that functionality is changed to include `Project` when its Group is imported/exported, the logic must be sure to include their corresponding project namespaces in the import/export.
-**Import project** creates a new project, so the project namespace is created through
Rails `after_save` callback on the project model.
After ensuring the above points, we plan to run a DB migration to create a `ProjectNamespace` record for every `Project`.
-**Export or import group:** when importing or exporting a `Group`, projects are not
Project namespace records created during migration should have `created_at`/`updated_at` attributes set to migration
included in the operation. If that feature is changed to include `Project` when its group is
runtime. That means that project namespaces `created_at`/`updated_at` attributes don't match their corresponding
imported or exported, the logic must include their corresponding project namespaces
project's `created_at`/`updated_at` attributes. We want the different dates to help audit any of the created project
in the import or export.
namespaces, in case we need it. We plan to run the back-filling migration in 14.5 milestone.
After ensuring these points, run a database migration to create a `ProjectNamespace`
record for every `Project`. Project namespace records created during the migration
should have `created_at` and `updated_at` attributes set to the migration runtime.
The project namespaces' `created_at` and `updated_at` attributes would not match
their corresponding project's `created_at` and `updated_at` attributes. We want
the different dates to help audit any of the created project namespaces, in case we need it.
After this work completes, we must migrate data as described in
[Backfill `ProjectNamespace` for every Project](https://gitlab.com/gitlab-org/gitlab/-/issues/337100).
