Custom group project template creation fails for Developers - wrong template_project_id submitted
## Summary Developer users cannot create a project from a custom group template. The UI submits an **old/incorrect template project ID** instead of the expected template project ID, resulting in the error: ``` Template project <id> is unknown or invalid. ``` This appears to be a regression introduced around the time the `constrain_group_project_templates` feature flag was enabled. The new `Projects::GroupTemplatesFinder` code path likely resolves templates differently when duplicate template names exist across group hierarchies, returning an old/stale template instead of the correct one. Only users with the **Developer** role are affected. Users with the **Owner** role can create projects from the template successfully. ## Steps to Reproduce 1. Set up a group with a custom project template subgroup containing a template (e.g. `my-template`) 2. Ensure there is another group in the hierarchy that also has a template with the same name (`my-template`) that the Developer does **not** have access to 3. Log in as a user with the **Developer** role in the target group 4. Navigate to create a new project from a custom group template 5. Select the template from the template picker 6. Attempt to create the project 7. Observe the error: `Template project <id> is unknown or invalid` ## What is the current *bug* behavior? The form submits the wrong `template_project_id` and `group_with_project_templates_id` — pointing to an old/inaccessible template rather than the one the user selected. HAR analysis confirms the `POST` to `/projects` contains incorrect IDs. Additionally, the template picker may show templates the Developer does not have access to. ## What is the expected *correct* behavior? - The form should submit the correct `template_project_id` corresponding to the template the user selected - The template picker should only show templates the user has access to - Developers should be able to create projects from custom group templates they have access to, just as Owners can ## Suspected Cause The `constrain_group_project_templates` feature flag rollout and the associated `Projects::GroupTemplatesFinder` changes may have introduced a regression in how templates are resolved when duplicate template names exist across group hierarchies. The resolver appears to return the wrong template when names collide. Related: - [Improve group template selection when creating projects](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/235297) - [FF: `constrain_group_project_templates`](https://gitlab.com/gitlab-org/gitlab/-/work_items/586332) ## Offering - GitLab.com (SaaS)
issue