<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=421054) </details> <!--IssueSummary end--> <!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> In previous Gitlab versions, you could configure Projects templates for a Group by specifying one of its own Sub-group. This works well when Groups are autonomous, but not when you want to share projects across multiple ones. Now, when selecting a Sub-Group to use as Group's Projects Templates, you can also pick from generally available Groups or Subgroups outside of the current Group. ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> As a DevOps engineer, I want to be able to provide common resources and templates to all the development teams. However, Instance wide templates may not be suited, since many teams could need to use templates for a similar project ("Python API" for example) but with some variations depending on the entity they belong to. Each team having its own group, I want to be able to maintain a hierarchy of files and projects that they could pick from. Currently, Instance-wide templates do not support Sub-groups rendering, preventing me from setting up a dedicated group with sub-groups to represent these entities. Group Project Templates could then be considered, but only use a Sub-Group under the Group we want to configure them for can be used. I would like to be able to select as Project Templates a Group from any generally available Group so that multiple Groups could reference the same projects. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://about.gitlab.com/handbook/product/personas/ * [Parker (Product Manager)](https://about.gitlab.com/handbook/product/personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/product/personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://about.gitlab.com/handbook/product/personas/#presley-product-designer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/product/personas/#sasha-software-developer) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/product/personas/#priyanka-platform-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/product/personas/#sidney-systems-administrator) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/product/personas/#rachel-release-manager) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/product/personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://about.gitlab.com/handbook/product/personas/#allison-application-ops) * [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator) * [Dakota (Application Development Director)](https://about.gitlab.com/handbook/product/personas/#dakota-application-development-director) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/product/personas/#dana-data-analyst) * [Eddie (Content Editor)](https://about.gitlab.com/handbook/product/personas/#eddie-content-editor) * [Amy (Application Security Engineer)](https://about.gitlab.com/handbook/product/personas/#amy-application-security-engineer) * [Isaac (Infrastructure Engineer)](https://about.gitlab.com/handbook/product/personas/#isaac-infrastructure-security-engineer) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/product/personas/#alex-security-operations-engineer) * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/product/personas/#cameron-compliance-manager) --> * [Parker (Product Manager)](https://about.gitlab.com/handbook/product/personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/product/personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/product/personas/#sasha-software-developer) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/product/personas/#priyanka-platform-engineer) * [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator) * [Dakota (Application Development Director)](https://about.gitlab.com/handbook/product/personas/#dakota-application-development-director) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/product/personas/#alex-security-operations-engineer) * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/product/personas/#cameron-compliance-manager) ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/product/ux/ux-research-training/user-story-mapping/ --> The Software Developer should be able to start a new Project from Template with a view limited to what should be used. Maintainers of Templates should be able to update them in a central place, and organize them in a way that each Entity is represented clealry. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Two ways that are not mutually exclusive: * Make Public groups available in the drop down when selecting Project Templates in a Group * Render Sub-groups in the Instance-wide Project Templates to allow nested organization instead of the current flat one ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> Having the ability of creating a hierarchy of templates will improve the user experience and help them find the right template quicker, particularly when a few instance of very similar ones are represented. Using the Built-in templates, there are currently 5 Netlify templates, all prefixed with Netlify/. It would be more intuitive and scalable to have a Netlify drop-down to list them. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? Consider adding checkboxes and expectations of users with certain levels of membership https://docs.gitlab.com/ee/user/permissions.html * [ ] Add expected impact to members with no access (0) * [ ] Add expected impact to Guest (10) members * [ ] Add expected impact to Reporter (20) members * [ ] Add expected impact to Developer (30) members * [ ] Add expected impact to Maintainer (40) members * [ ] Add expected impact to Owner (50) members Please consider performing a threat model for the code changes that are introduced as part of this feature. To get started, refer to our Threat Modeling handbook page https://about.gitlab.com/handbook/security/threat_modeling/#threat-modeling. Don't hesitate to reach out to the Application Security Team (`@gitlab-com/gl-security/appsec`) to discuss any security concerns. --> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/workflow.html * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> https://docs.gitlab.com/ee/user/group/custom_project_templates.html#set-up-group-level-project-templates will need to be updated to reflect the changes. ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the Quality Engineering quad planning and test planning processes and reach out to your counterpart Software Engineer in Test for assistance. Quad Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/quad-planning Test Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/test-engineering/#test-planning --> ### Available Tier <!-- This section should be used for setting the appropriate tier that this feature will belong to. Pricing can be found here: https://about.gitlab.com/pricing/ * Free * Premium/Silver * Ultimate/Gold --> * Premium/Silver * Ultimate/Gold ### Is this a cross-stage feature? No ### Links / references <!-- Label reminders - you should have one of each of the following labels. Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ -->