### Summary When **personal project creation is disabled** for a user (`projects_limit = 0`), they **cannot import projects by URL into a group namespace**. Clicking **New project → Import project → Repository by URL** immediately returns a **403 “You do not have permission to import projects”** error, even when the user has sufficient permissions in the target group. ### Steps to reproduce 1. Configure SAML / user settings so that **personal projects are disabled** for the user (`projects_limit = 0`). 2. Ensure the user is an **Owner/Maintainer** of a group where they are allowed to create projects. 3. In that group, go to **New project → Import project → Repository by URL**. 4. Observe that a **403** error is returned immediately, before any URL or credentials are entered. ### What is the current bug behavior? * The user sees **“You do not have permission to import projects.”** as soon as they click **Repository by URL**. * This happens **even though they can create projects in the group** and other import mechanisms still work. * The error appears **before** any URL or credentials input, indicating it’s failing early on permission checks. ### What is the expected correct behavior? * A user who **cannot create personal projects** but **can create projects in a group namespace** should still be able to: * Access **Import project → Repository by URL**. * Successfully import a project **into a group** where they have the necessary permissions. * Personal project restrictions should **not** block group imports by URL. ### Relevant logs / configuration * Example customer report and logs: GitLab Support ticket **712326** (GitLab internal Zendesk). * Affected users have `projects_limit = 0`, coming from SAML / account-level configuration to disable personal projects. ### Suspected cause A recent change added a permission check that always verifies the user can import into their **personal namespace**, even when they are importing into a **group namespace**: `unless can?(current_user, :import_projects, current_user.namespace) return access_denied!(s_('ProjectImportByURL|You do not have permission to import projects.')) end ` When `projects_limit = 0`, the user **fails** this check for their personal namespace, so the import is blocked **before** we consider the target group namespace or `namespace_id`. ### Impact * Any user with **personal projects disabled** is currently **blocked from importing projects by URL into groups**, even if: * They are **Owner/Maintainer** of the target group. * Other import methods (e.g. from other sources) still work. * This is effectively a **regression** for customers who rely on URL-based imports and use SAML or policy to disable personal projects. * Marking as **Severity 2**: * Affects multiple users (all with personal projects disabled) on affected instances. * There is a workaround (other import methods), but URL import is the preferred/most efficient path for some workflows. ### Possible fixes * Adjust the permission check so that: * If a `namespace_id` is provided (group import), we check the user’s ability to import/create projects **in that group** instead of (or in addition to) their personal namespace. * Users with `projects_limit = 0` can still import by URL into groups where they have the appropriate role (e.g. Owner/Maintainer).