Make securityFindingDismiss mutation idempotent

Summary

Original comment

@mokhax I found another bug related to the dismissal of findings (or could be a design choice). When using the securityFindingDismiss mutation and providing a dismissalReason, the reason only gets applied if the finding is not in the dismissed state. If it is already dismissed, the reason of the finding remains null (i.e.: project.pipeline.securityReportFinding.dismissalReason = null).

This is in contrast to the comment field of that mutation, which can be updated even though the finding is already dismissed (so that is working).

Is this related to Make securityFindingDismiss mutation idempotent (#411210 - closed) • Gregory Havenga • 16.4 • On track @ghavenga created and attached to the epic where this issue belongs to?

When using mutation.securityFindingDismiss it's impossible to re-dismiss with a different dismissal reason.

Problem

Dismissing a finding with mutation.securityFindingDismiss works fine if it isn't dismissed yet. However, when editing the dismissal (editing comment or providing/editing the dismissal reason) with this mutation, the provided dismissal reason is not applied.

This becomes more apparent with Provide & edit dismissal reason in finding modal (#412841 - closed) • Lorenz van Herwaarden • 16.4 • On track because this will allow the user to edit the dismissal reason in a finding.

Implementation plan

• Backend update the FindOrCreateFromSecurityFinding service to permit the updating of dismissal reasons on existing vulnerability state transitions.