Skip to content

Fix finding modal when dismissedBy is null

What does this MR do and why?

This MR fixes a customer bug. While we can't replicate it at the moment yet, it's a severity2 and we know we can easily fix the frontend part by allowing the finding modal to handle the dismissedBy: null case. The EventItem component within the DismissalNote component can handle the case where the user is null and will render "a deleted user".

In the mean time, we're trying to find out how it was possible that the finding was dismissed without a user, which can lead to additional fixes. See more context in the issue #435425 (comment 1695706599)

Related #435425 (closed)

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before After
before after

How to set up and validate locally

Prerequisites

  1. You need an EE license
  2. You need to have runners enabled (See $2408961 for setting up a runner)
  3. Import https://gitlab.com/gitlab-examples/security/security-reports
  4. Run a pipeline on master

Validate

  1. Go to lastest pipeline > security tab
  2. Click on a finding and dismiss it in the modal, close modal
  3. In devtools, network tab: find the graphql api call for the finding (operation name: "getSecurityReportFinding"), right-click > override content. In the response, change dismissedBy object to null.
  4. Open the same finding again so the modal opens
  5. Validate the modal now loads properly and the dismissal note contains "A deleted user" as the author
Edited by Lorenz van Herwaarden

Merge request reports