Currently, when defining a policy, the user can limit the application of the policy to a set of projects.
In my particular case, I have a number of projects and a set of policies defined that apply to them. However, some of these projects don't fall under some of the policies, requiring me to limit these policies to the projects that do require policy controls. In my case, the number of these projects that don't require the policies to be applied to them is much, much smaller than the ones that do (about 4 out of 14, not accounting for the different versions of these projects). This requires me to continuously update the policies to include the new versions of the projects that these policies need to be applied to.
More concretely, I have a policy intended to enforce component license compatibility with the projects own license. Due to this not being always possible, some of the project functionality has been moved out into separate, plugin projects, which are licensed differently, to allow the use of dependent components that are under licenses incompatible with the core project.
Additionally, these cut-out projects update at a much slower pace than the core, raising the frequency at which the user is required to update the limitations.
Proposed Behavior
When defining a policy, in addition to limiting it to a set of projects, allow specifying projects that should be excluded from applying the policy to.
The one erroneous case I see a user may accidentally commit is both limiting the policy to a project and excluding the project from applying this policy to, which would be an error. This should probably be reported to the user without taking any action, keeping them at the policy definition screen, allowing them to review and update their chosen application rules.
rkg-mm
commented
1 year ago
Current Behavior
Currently, when defining a policy, the user can limit the application of the policy to a set of projects.
In my particular case, I have a number of projects and a set of policies defined that apply to them. However, some of these projects don't fall under some of the policies, requiring me to limit these policies to the projects that do require policy controls. In my case, the number of these projects that don't require the policies to be applied to them is much, much smaller than the ones that do (about 4 out of 14, not accounting for the different versions of these projects). This requires me to continuously update the policies to include the new versions of the projects that these policies need to be applied to.
More concretely, I have a policy intended to enforce component license compatibility with the projects own license. Due to this not being always possible, some of the project functionality has been moved out into separate, plugin projects, which are licensed differently, to allow the use of dependent components that are under licenses incompatible with the core project.
Additionally, these cut-out projects update at a much slower pace than the core, raising the frequency at which the user is required to update the limitations.
Proposed Behavior
When defining a policy, in addition to limiting it to a set of projects, allow specifying projects that should be excluded from applying the policy to.
The one erroneous case I see a user may accidentally commit is both limiting the policy to a project and excluding the project from applying this policy to, which would be an error. This should probably be reported to the user without taking any action, keeping them at the policy definition screen, allowing them to review and update their chosen application rules.
Checklist