Make Vulnerability and State transition creations feature flag(`deprecate_vulnerabilities_feedback`) agnostic when user interacts with findings
Right now as part of deprecation of Vulnerabilities::Feedback
, we are creating Vulnerability when user interacts with findings (dismissing finding, creating issue or creating MR with deprecate_vulnerabilities_feedback
enabled. But as part of rollout discussion #361797 (comment 1131871406), we found that it will be reliable to create Vulnerability and State transition with Feedback creation without depending on FF, so that if anything goes wrong after FF enabling, we can revert back and not end up in inconsistent state.
Implementation plan:
We need to make sure the following places where we are checking FF, do not have impact on feedback, state transition and vulnerability creation:
-
ee/app/controllers/ee/projects/issues_controller.rb
-
ee/app/finders/security/findings_finder.rb
(we did not introduce FF here yet) -
ee/app/finders/security/vulnerabilities_finder.rb
(!102238 (merged)) -
ee/app/graphql/mutations/security/finding/create_issue.rb
(can keep this one as this mutation is not used anywhere from ui right now) -
ee/app/services/security/findings/dismiss_service.rb
-
ee/app/services/security/ingestion/tasks/ingest_vulnerabilities/create.rb
(!102238 (merged)) -
ee/app/services/security/ingestion/tasks/ingest_vulnerabilities/update.rb
(!102238 (merged)) -
ee/app/services/vulnerabilities/confirm_service.rb
(can keep this feature flag, as vulnerability or state transition creation does not depend on FF here) -
ee/app/services/vulnerabilities/dismiss_service.rb
(!102238 (merged)) -
ee/app/services/vulnerabilities/finding_dismiss_service.rb
(!102238 (merged)) -
ee/app/services/vulnerabilities/resolve_service.rb
(can keep this feature flag, as vulnerability or state transition creation does not depend on FF here) -
ee/app/services/vulnerabilities/revert_to_detected_service.rb
(can keep this feature flag, as vulnerability or state transition creation does not depend on FF here)
Issues that will be impacted by this and need (re)verification:
Edited by Subashis Chakraborty