### Problem to solve Users can dismiss vulnerabilities in the security reports in case they recognize it as a false positive, or it simply doesn't apply to that specific case. Security engineers may need to kknow the reason, and to understand why the vulnerability has been dismissed. At the moment, there is no way to get this information. ### Target audience - Sasha, Software Developer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sasha-software-developer - Sam, Security Analyst, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sam-security-analyst ### Proposal Allow users to specify an optional message when dismissing vulnerabilities. This information will be saved and shown along with the dismissed item. Users that don't want/need to add the reason will go through their standard process as usual. Users interested in adding a reason can do something similar they already do to start a discussion in a comment in the issue. The dismissal information is the object that can be used to "add a comment". If that's the case, a textarea will appear (similar to comments in issues). The overall idea could be considered something similar to what Google Calendar allows to do when you accept/decline an invite. The flow should not create complexity for users, and it should be optional only. It will be available in the merge request widget, in the pipeline report, in the project and group security dashboards. ### Designs - :point\_right: :desktop: [**Prototype**](https://rnu8n7.axshare.com/#g=1&p=v9_prototype&c=1) *Second list item is actionable* #### Adding a comment and dismissing at the same time. | GIF | | ------ | |  | ##### Mocks for adding a comment and dismissing vulnerability. | Modal -initial state | Modal - initial state - hover detail | | ------ | ------ | |  |  | | Modal - adding comment | Modal - adding comment - comment complete | Modal - adding comment - empty text area - error | | ------ | ------ | ------ | |  |  |  | | Toast | Dashboard feedback | Dashboard - feedback popover | Dashboard feedback - popover long comment | | ------ | ------ | ------ | ------ | |  |  |  |  | | truncated toast | | ------ | |  | | toast truncates after 75 characters (max-width 596px) | - **After user clicks** `Add comment icon` - Modal changes to show text area and dismissal details - Text area is set to on_focus so the user doesn't have to click to enter the text area. This is not depicted in the gif properly. - **After user clicks** `Add comment & dismiss`: - Modal closes - Vuln list item changes to DISMISSED and the comment icon is added - Toast `dismissed with comment` fires following our [**toast guidelines.**](https://design.gitlab.com/components/toasts) - **If the user clicks `Cancel`**: - They will be returned to the modal in its original state. _____ #### Adding a comment to an already dismissed vulnerability. | GIF | | ------ | |  | | Modal - Vulnerability dismissed | Modal adding comment from dismissed - initial state | Modal - Vulnerability dismissed - text area empty - error | Modal - Vulnerability dismissed - comment added | | ------ | ------ | ----- | ----- | |  |  |  |  | | Toast | | ------ | |  | - **After users clicks on the text field button:** - Text area appears and is set to on_focus so the user doesn't have to click twice to type. This is not depicted in the Gif. - **After user clicks `Add comment`**: - Modal closes - Vuln list item changes to DISMISSED and the comment icon is added - Toast `Comment added` fires following our [**toast guidelines.**](https://design.gitlab.com/components/toasts) - **If the user clicks `Cancel`**: - They will be returned to the modal in its dismissed state. ______ #### Editing a comment | GIF | | ------ | |  | | Modal - Dismissed with comment | Modal - edit comment popover | Modal - editing comment | | ------ | ------ | ------ | |  |  |  | | Toast - Edit comment | | ------ | |  | - **After user clicks `Saves comment`**: - Modal closes - Toast `Comment edited` fires following our [**toast guidelines.**](https://design.gitlab.com/components/toasts) - **If the user clicks `Cancel`**: - They will be returned to the modal state with the original comment shown. ______ #### Deleting a comment | GIF | | ------ | |  | | Modal - with comment - delete hoverstate | Modal - with comment - Deletion confirmation | | ------ | ------ | |  |  | | Toast | | ----- | | | - **After user clicks `Saves comment`**: - Modal closes - Toast `Comment deleted` fires following our [**toast guidelines.**](https://design.gitlab.com/components/toasts) - Modal state returns to Dismissed with no comment. - **If the user clicks `Cancel`**: - They will be returned to the modal state with the original comment shown. #### Assets: - :mag: [**Design specs**](https://gitlab-org.gitlab.io/gitlab-design/hosted/andy/ee%2310364-Add-optional-note-when-dismissing-vuln-spec-previews/) #### Rules: - We are **not** going to support adding a comment from the quick action buttons in the Group Security Dashboard in this version. All commenting actions on dismissed vulns will start in the modal. - Only **one** comment will be supported in this version. - Anyone can comment on a vulnerability at any time. A comment does not have to happen when the user dismissed the vulnerability. - Only plain text will be supported. No markup, links, or mentions will be supported. #### Edge Cases | When there is a problem while trying to add a comment. Same error text applies to all commenting actions. | | ------ | |  | ### Permissions and Security Users that can dismiss vulnerabilities will be able to set the message. Users that can see dismissed vulnerabilities will be able to see the message. ### What does success look like, and how can we measure that? Number of messages set. --- ## Boring solutions We'll be delivering this in several steps (or MRs) to avoid one huge MR close to feature freeze and ensure it still ships, even if it slips. - [x] Displaying the dismissal as an item with the timestamp. !11028 - [x] Allow the dismisser to add a comment on dismissal creation only !11226 & !11162 - [x] Allow anyone to provide a dismissal reason after the vulnerability has been dismissed !11963 & !12067 - [-] Allowing a dismissal reason to be deleted/edited (New issue: #11721) - [-] Add the toast messages (New issue: #11720) We might combine the last two steps depending on how similar they end out being.