Optionally ignoring membership inheritance for subgroups

THIS IS A WIP ISSUE, TO TRACK QUESTIONS AND PROBLEMS SPOTTED WHILE INVESTIGATING https://gitlab.com/gitlab-org/gitlab-ce/issues/30222

Problem to solve

Currently, subgroups inherit in total the members from the parent group.

While it is possible to override the members access on subgroups (for example, give master access to someone on a subgroup who has developer on the parent group), it is not possible at the moment to remove access to members on subgroups (for example, in a confidential private group, allow only members from the parent group who have some admin status to see and enter the subgroup.

Intended users

Sidney (Systems Administrator)

Further details

Proposal

Permissions and Security

Documentation

Testing

What does success look like, and how can we measure that?

Links / references

changed milestone to %12.2

added typefeature label

changed the description

1. if we implement it, should it be on root group level and touching all subgroups or each subgroup should have their own setting?

2. How do we assure backwards compatibility? If admin switched it on the root-level group, suddenly users will lose access to all subgroups.

3. what about more than 1 level down nesting? so:

• Group A - inheritance switched on
  • Group B - inheritance switched off
    • Group C - inheritance switched on

Which users should group C inherit? from group B or from group B AND A?

4. should 2fa authentication enforced on top-level group should be also inherited when new setting - inheritance - is switched off?

5. search page: in users scope, when a group is given, we search for users in ancestors, given group, and descendants of the given group. Does this behaviour should change?

Important things to remember about, that can be easily missed:

1. Gitlab::ProjectAuthorizations class
2. call RefreshAuthorizedProjectsService after settings change

Execution proposition: as this will require adding two paths of adding authorizations/checking authorizations etc, my proposition is to roll it out behind a feature flag in a really small MRs. One MR for all changes looking at the scope of changes will be unreviewable :(

mentioned in issue #30222 (moved)

This will also affect LDAP group sync as discussed in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/13435#note_203257652

changed milestone to %12.3

added missed:12.2 label

mentioned in issue #66572 (closed)

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue

mentioned in issue gitlab#17629 (closed)

marked this issue as related to gitlab#33534 (closed)