Add due date to vulnerability details sidebar

AJ Bitonrequested to merge
feature/vulnerability-due-date-sidebar into master

What does this MR do and why?

Adds a Due date section to the vulnerability details page sidebar, behind the vulnerability_due_date_ui feature flag (gitlab_com_derisk, default off, project actor).

Due dates can already be set through the API (bulkSetVulnerabilityFindingsDueDates) and read from Vulnerability.dueDate, but nothing in the UI shows or edits them. With this MR:

  • The sidebar shows the finding's due date, or None, under Severity.
  • While the vulnerability is open (detected or confirmed), the date uses the same overdue and due-soon treatment as work items (getDueDateStatus): the calendar-overdue or calendar-due icon plus an (overdue) or (due soon) label. Resolved and dismissed vulnerabilities always show the neutral calendar.
  • Users with admin_vulnerability get an Edit action that shows a datepicker, which turns into Apply while editing (the same pattern as work item dates). Apply, Esc, or a click outside the section saves: it sets the date, or removes it when cleared, by calling the existing mutation with the finding UUID. Success shows a toast. Mutation errors or a failed request show an alert and keep the form open.

Data follows the page's HAML → GraphQL migration contract (https://gitlab.com/gitlab-org/gitlab/-/work_items/601897): due_date is added to the helper payload, mapped in the fromHaml adapter, and selected in vulnerability_details.query.graphql. The frontend fixture now carries a due date, so the adapter contract spec covers it.

Out of scope, for follow-ups: due dates in the vulnerability report, filtering, bulk editing, and an activity or system note when a due date changes (the service does not create notes today).

References

Screenshots or screen recordings

Verified locally in GDK against gitlab-org/gitlab vulnerabilities, as a project maintainer.

State Screenshot
No due date 01_no_due_date
Editing (Edit becomes Apply) 02_editing_apply
Due soon (Nov 3, today Oct 29), after reload 03_due_soon_after_reload
Overdue (Oct 20) 04_overdue
Removed, with toast 05_removed_with_toast
Flag disabled (vulnerability still has a due date) 06_flag_off

I also checked that the database row and Vulnerability.dueDate over GraphQL matched each change (2026-11-03 after setting, null after removal), and that there were no browser console errors.

How to set up and validate locally

  1. In the Rails console, enable the feature flag:

    Feature.enable(:vulnerability_due_date_ui)

  2. As a user with at least the Maintainer role (or another role with admin_vulnerability), open any vulnerability, for example http://127.0.0.1:3000/gitlab-org/gitlab/-/security/vulnerabilities/<id>.

  3. In the sidebar under Severity, the Due date section shows None. Select Edit, pick a date, and select Apply (or press Esc, or click outside the section).

  4. Reload the page. The date persists. A past date shows (overdue); a date within the next 7 days shows (due soon).

  5. Select Edit, clear the date with the clear button, and select Apply. The section shows None again.

  6. As a Developer, the section is read-only (no Edit).

  7. Disable the flag. The section is no longer rendered.

MR acceptance checklist

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

  • No changelog entry: the feature is behind a default-off flag. A changelog and user docs will come with the rollout.
  • No database or permission changes: this reuses the existing mutation and its admin_vulnerability authorization.

🤖 Generated with Claude Code

Edited by AJ Biton

Merge request reports