Skip to content

Update routes for lost-and-found group and projects

Yannis Roussos requested to merge 219658-add-route-to-ghost-lost-and-found-group into master

What does this MR do?

Related to #219658 (closed)

With !31675 (merged) we partially addressed the issue of projects not being properly deleted (orphaned) when their namespace is deleted:

  1. Added a Foreign Key constraint from projects.namespace_id to namespaces.id that restricts namespaces from being deleted without all the projects that reference them being deleted first.
  2. Fixed existing inconsistencies:
    • Added a lost-and-found group owned by the Ghost User
    • Found all the Orphaned projects (i.e. those with a namespace_id not matching any namespace)
    • Made them private, marked them as archived and moved them under the lost-and-found group

This lost-and-found group is intended as a bucket to store projects that were not properly deleted. Its purpose is 100% system level, akin to Linux's lost and found directory, so that we can gather those projects and delete them at a later stage.

For that reason a route was not added for that group, nor were the routes for the moved orphaned projects, updated.

That resulted to the group not being accessible through the UI (while visible in the admin dashboard) and caused confusion to instance admins on the origin of this group and its purpose (#219658 (closed)).

This MR addresses this issue in two ways:

  1. Adds proper routes for the lost-and-found group and the Ghost user (if not already created) and updates all the routes for the orphaned projects to reflect their new path under the lost-and-found group.

    That makes both the lost-and-found group and the orphaned projects accessible for admins, so that they can inspect their contents.

  2. The description of the lost-and-found group has been updated to explain its purpose and functionality.

Migration output

Up

$  bundle exec rake db:migrate
== 20200602143020 UpdateRoutesForLostAndFoundGroupAndOrphanedProjects: migrating
== 20200602143020 UpdateRoutesForLostAndFoundGroupAndOrphanedProjects: migrated (0.1836s)

Down

$  bundle exec rake db:rollback
== 20200602143020 UpdateRoutesForLostAndFoundGroupAndOrphanedProjects: reverting
== 20200602143020 UpdateRoutesForLostAndFoundGroupAndOrphanedProjects: reverted (0.0000s)

Proof of Concept

I tested with our dev seeded data, by rolling back to before we added the foreign key in !31675 (merged) and setting the gitlab-test_1 project to point to a non existing namespace.

I then run the migrations in !31675 (merged) to add a ghost user and a lost-and-found group and move this orphaned project under it.

Before running the migration in the current MR, there are no routes for the Ghost's namespace and the lost-and-found group and the route of gitlab-test_1 project is pointing to its old path (gitlab-org/gitlab-test):

gitlabhq_development=# SELECT * FROM routes ORDER BY id desc LIMIT 3;
 id  | source_id | source_type |             path             |         created_at         |         updated_at         |               name
-----+-----------+-------------+------------------------------+----------------------------+----------------------------+----------------------------------
 117 |         1 | Project     | gitlab-org/gitlab-test       | 2020-06-02 19:24:30.000736 | 2020-06-02 19:24:30.000747 | Gitlab Org / Gitlab Test
  78 |        54 | Namespace   | Yannis_Group                 | 2020-06-02 16:00:09.135003 | 2020-06-02 16:00:09.135003 | Yannis_Group
  69 |        18 | Project     | irena/typeahead-js           | 2020-06-02 10:49:51.586452 | 2020-06-02 10:49:51.586452 | Allene Hickle / Typeahead.Js

After running the migration, the routes are properly added / updated:

gitlabhq_development=# SELECT * FROM routes ORDER BY id desc LIMIT 3;
 id  | source_id | source_type |              path              |         created_at         |         updated_at         |               name
-----+-----------+-------------+--------------------------------+----------------------------+----------------------------+----------------------------------
 119 |        53 | Namespace   | lost-and-found                 | 2020-06-02 19:30:34.071657 | 2020-06-02 19:30:34.071662 | lost-and-found
 118 |        52 | Namespace   | ghost                          | 2020-06-02 19:30:34.063488 | 2020-06-02 19:30:34.063495 | Ghost User
 117 |         1 | Project     | lost-and-found/gitlab-test_1_1 | 2020-06-02 19:24:30.000736 | 2020-06-02 19:30:34.127183 | lost-and-found / Gitlab Test_1_1

I have also tested with the local instance and both the lost-and-found group and the orphaned project under it are fully accessible.

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • [-] Label as security and @ mention @gitlab-com/gl-security/appsec
  • [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • [-] Security reports checked/validated by a reviewer from the AppSec team

Merge request reports