Skip to content

Forking a project to a personal namespace fails with undefined method error

Summary

When SAML group sync is configured and a non-admin user attempts to fork a project from a group to their personal namespace, the operation fails with NoMethodError: undefined method 'saml_group_sync_available?' for nil:NilClass. This is a regression introduced in commit 3237c293 ("Deny project invitations on SAML lock").

Steps to reproduce

  1. Configure SAML group sync on a GitLab instance with lock_memberships_to_saml enabled
  2. Create a project in a group that has SAML group links configured
  3. As a non-admin user, attempt to fork the project to your personal namespace
  4. Observe the error in logs and failed fork operation

Example Project

NA

What is the current bug behavior?

The fork operation fails with the following error:

NoMethodError: undefined method `saml_group_sync_available?' for nil:NilClass

The error occurs because the saml_group_sync_available policy condition in ee/app/policies/ee/project_policy.rb calls @subject.group.saml_group_sync_available?, but when forking to a personal namespace, @subject.group is nil since personal projects don't belong to a group.

What is the expected correct behavior?

Non-admin users should be able to fork projects from groups to their personal namespaces successfully, even when SAML group sync is configured. The SAML group sync restrictions should only apply to group-level operations, not personal namespace operations.

Relevant logs and/or screenshots

From the application logs:

{
  "severity":"ERROR",
  "time":"2025-09-29T09:39:55.202Z",
  "correlation_id":"REDACTED",
  "meta.caller_id":"POST /api/:version/projects/:id/fork",
  "meta.feature_category":"source_code_management",
  "meta.user":"REDACTED",
  "meta.user_id":17,
  "message":"Unable to save project. Error: undefined method `saml_group_sync_available?' for nil:NilClass Project ID: REDACTED"
}

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

The issue is in the saml_group_sync_available condition in ee/app/policies/ee/project_policy.rb at line 253:

condition(:saml_group_sync_available, scope: :subject) do
  @subject.group.saml_group_sync_available?
end

This should be changed to use the safe navigation operator to handle cases where @subject.group is nil:

condition(:saml_group_sync_available, scope: :subject) do
  @subject.group&.saml_group_sync_available?
end

This will return nil (which evaluates to false) when @subject.group is nil, allowing the fork operation to proceed for personal namespaces while still applying SAML restrictions to group operations.

Root Cause: This regression was introduced in commit 3237c293 which added SAML group sync policy conditions without considering that personal projects (@subject.group is nil) would also be evaluated against these conditions. The issue only affects non-admin users because the policy rule includes ~admin (not admin), so admin users bypass this check entirely.

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard 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 for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖