Skip to content

Public group and its projects become private after migrating them with GitLab Migration

Summary

Public group and its projects become private after migrating them with GitLab Migration.

This happens when migrating within the same instance and between instances.

Steps to reproduce

Import a public group via bulk import functionality aka GitLab Migration.

Example Project

Issue can be reproduced via qa/qa/specs/features/browser_ui/1_manage/group/bulk_import_group_spec.rb e2e test

What is the current bug behavior?

Group with public visibility becomes private after import

What is the expected correct behavior?

A group/project visibility level should stay consistent with the source or inherit the visibility of the destination group the group/project lands in if the group's visibility is more strict.

Imported into public group Imported into private group
Public on source stays public becomes private
Private on source stays private stays private
Should there be special consideration for SM to SaaS migrations?

No, such consideration is not needed.

Self-managed -> gitlab.com migrations would land on a top-level group which are usually private and/or have SAML/SSO enforced. (from here)

If migrating to SaaS and group has to stay private, I think it would be possible to simply migrate in to a private group. But it seems that it's not something that has to be handled by a migration tool. The way I see it, primary objective of migration tool is to ensure consistency of migrated data. (from here)

Relevant logs and/or screenshots

1) Manage Group bulk import performs bulk group import from another gitlab instance
     Failure/Error: expect(imported_group).to eq(source_group)

       expected: {
         "name": "source-group-for-import-811d6e2f",
         "path": "source-group-for-import-811d6e2f",
         "desc...share_with_group_lock": false,
         "subgroup_creation_level": "maintainer",
         "visibility": "public"
       }
            got: {
         "name": "source-group-for-import-811d6e2f",
         "path": "source-group-for-import-811d6e2f",
         "desc...hare_with_group_lock": false,
         "subgroup_creation_level": "maintainer",
         "visibility": "private"
       }

       (compared using ==)

       Diff:
       @@ -10,6 +10,6 @@
          "require_two_factor_authentication": false,
          "share_with_group_lock": false,
          "subgroup_creation_level": "maintainer",
       -  "visibility": "public"
       +  "visibility": "private"
        }

Proposed solution

Visibility level of an imported group/project should be the same as that group/project visibility level on source, unless an imported group/project lands in a group with a more strict visibility level:

Imported into public group Imported into private group
Public on source stays public becomes private
Private on source stays private stays private

Screen_Shot_2022-12-27_at_20.54.21

#### Visibility rules

- Private groups and projects will always stay private after migration.
- Public groups and projects will:
  - Stay public when imported into a public group.
  - Become private when imported into a private group.

If on your source instance you rely on a private network to hide content from the general public, make sure to have a similar setup on the destination instance, or to import into a private group.

NOTE Draft MR by @wortschi for frontend and documentation: !107915 (merged)

Implementation details

As mentioned by Rodrigo in #331252 (comment 1188739818), using a hash with_indifferent_access should fix the problem.

Edited by Magdalena Frankiewicz