Fix approval group lookup within user namespaces
What does this MR do and why?
Security::ProcessScanResultPolicyWorker
started raising for a small number of projects since the application setting security_policy_global_group_approvers_enabled
for !110653 (merged) was toggled in gitlab-com/gl-infra/production#9130 (closed).
Cause for the exceptions is that user namespaces are not part of group hierarchies and therefore group lookups cannot be limited to hierarchies. See: #413989 (comment 1416518624)
How to set up and validate locally
-
Disable the setting:
Gitlab::CurrentSettings.update_attribute(:security_policy_global_group_approvers_enabled, false)
-
Create a group and add another member.
-
Create a project in your user namespace.
-
Navigate to
Security & Compliance > Policies
and create the following scan result policy:type: scan_result_policy name: Test description: '' enabled: true rules: - type: scan_finding branches: [] scanners: [] vulnerabilities_allowed: 0 severity_levels: [] vulnerability_states: [] actions: - type: require_approval approvals_required: 1 group_approvers: [cold-sunset-9379] # substitute your group
-
Create the following
run.rb
:PROJECT = Project.find(-1) # replace PROJECT.all_security_orchestration_policy_configurations.each do |config| Security::ProcessScanResultPolicyWorker.new.perform(PROJECT.id, config.id) end
-
Run it with
bin/rails runner run.rb
and verify that it does not raise. -
Check out
master
, re-runrun.rb
and verify that it raises:undefined method `by_ids_or_paths' for #<ActiveRecord::Relation [#<Namespaces::UserNamespace id:1 @root>]> (NoMethodError)
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #413989 (closed)