Problem Validation: What do users want and expect from managing License Compliance at the Group / Instance level
Blockers
Migrate Groups and Projects To Namespaces Allow group owners to define compliance pipeline configurations at the group level
Wish to leverage:
- Security Orchestration policy creation
- move away from pipeline yml possibly
- add database
Problem to solve
As the person in charge of compliance, I want control of all projects to enforce policy and configuration decisions made by the enterprise.
I should be able to set my companies policies at the group and/or project level to avoid repetition/manual busy work.
Further details
Question: are there levels of people in charge of compliance at different sized organizations? Does this permissioning of this need to be a bit more granular?
Question: When users want to create license compliance rules at the group level - what specifically is their need they are solving for?
assumption: company policies (specific ones) are company or department specific and those can span multiple projects and they want to reduce overhead / avoid making a mistake due to manual work.
Question: How does setting something at Group affects projects?
assumption: I should specifically be able to indicate when setting a group policy if it should be the default (able to be changed by a project but this is a smart start) for each project, unchangeable, or a minimum (it must be used, at a minimum, but additional or more strict policies could also be enabled at the project level).
Question: if/when project level can override group policies created, how would the person setting this expect this to work, what options do they want /need?
we should explore this from a desired user features standpoint, useability standpoint, as well as our engineering framework we need to work within. We may identify areas outside of secure that we need to cordinate with other teams to improve as pre-requisties.
question: Can we set/enforce a default approver group? Who is the default approver if at the group level it's set but they aren't in a project? what happens if group changes default group to open waiting on approvals?
Is making approver group required / auto recreate when enabled a pre-requistie to this?
Proposal
Implement a group setting to define License Compliance policies that will apply to all the projects in that group. They should be able to set if the rules are the default (can be changed) or minimum (must be present but can be more strict). The interface can be consistent to what we already have at project level in the settings page.
What does success look like, and how can we measure that?
How many License Compliance policies are defined at group level.
Discovery Outcome Issues
Future desired functionality
Possible MVC (group is inherited but can be overridden perhaps? what is the easiest but most useful MVC)
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.