### Summary In the following condition, `This group cannot be invited to a project inside a group with enforced SSO` error happens even if the project belongs top-level project that does not enforce SSO. * The project was forked from a project that belongs a top-level project that enforces SSO * The project belongs a top-level project that does **not** enforce SSO * The Owner of the project try to invite a group into that project ### Steps to reproduce * Prepare two top-level groups * **Group A** * **Group B** * Configure SSO and enable "[Enforce SSO-only authentication for web activity for this group](https://docs.gitlab.com/user/group/saml_sso/#sso-only-for-web-activity-enforcement)" in **Group A** * Create **ProjectA** under the **Group A** * Fork the **ProjectA** under the **GroupB** * Create a subgroup under the **Group B** * Try to invite the subgroup into the forked project → Error happens * Disable SSO enforcement in **Group A** * Try to invite the subgroup into the forked project → Error not happens * Enable SSO enforcement again in **Group A** * Try to invite the subgroup into the forked project → Error happens * [Remove fork relationship](https://docs.gitlab.com/user/project/repository/forking_workflow/#unlink-a-fork) * Try to invite the subgroup into the forked project → Error not happens ### Example Project * The project that enforces SSO (GroupA in the above steps): https://gitlab.com/groups/kkamiya_gl_ultimate_group * Original project (ProjectA in the above steps): https://gitlab.com/kkamiya_gl_ultimate_group/test20251008 * The project that not enforce SSO (GroupB in the above steps):https://gitlab.com/kkamiya_gl_premium_group * Forked project: https://gitlab.com/kkamiya_gl_premium_group/test-20251008-fork ### What is the current _bug_ behavior? `This group cannot be invited to a project inside a group with enforced SSO` error happens even if a project belongs to a top-level project which does **not** enforce SSO. ### What is the expected _correct_ behavior? A group can be invited to a project if that project belongs to a top-level project which does not enforce SSO. ### Relevant logs and/or screenshots {width="859" height="691"}  ### Output of checks <!--If you are reporting a bug on GitLab.com, uncomment below--> This bug happens on GitLab.com <!--and uncomment below if you have /label privileges--> <!--or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not--> #### Results of GitLab environment info This bug happens on GitLab.com ### Possible fixes Based on the following facts, we can say that a project forked from another project references the SSO enforcement settings of the top-level group to which the original project belongs when the user tries to invite a group. * Disable SSO enforcement in the top-level group of original project (Group A) can prevent the error * After that, if the SSO enforcement settings is reverted in the Group A, the same error will occur again. * [Remove fork relationship](https://docs.gitlab.com/user/project/repository/forking_workflow/#unlink-a-fork) can prevent the error ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!--If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"`-->