Skip to content

Integrate Instance Security Dashboard frontend components

What does this MR do?

Part of the Instance Security Dashboard MVC.

This improves the integration between the existing frontend parts of the Instance Security Dashboard and gets it closer the the target UX.

In particular:

  • The ProjectManager component is now included in the root component.
  • The security dashboard store's mediator is now aware of a lazy flag for some mutations, allowing updates to filters without triggering an immediate re-fetch of vulnerabilities. This is to avoid expensive requests from firing when not necessary.
  • A new security dashboard store plugin registers the projectSelector store module, and sets up a mutation subscription to sync the dashboard's project filter dropdown with whatever projects have been chosen by the user in the ProjectManager.
  • The correct module name (projectSelector) is bound in the root component.
  • The filters/setFilterOptions action now updates the given filter's selection if the new set of options would otherwise result in an invalid selection. A nice side-effect of this is that for security dashboards with a router, if the user navigates to a URL with an invalid project_id in the URL, the project filter gets reset to 'All'. Previously, the dropdown would just render in an inconsistent state.
  • A race condition was fixed, which caused invalid projects' names not to be displayed in the flash after attempting to add them with the ProjectManager.
  • The "Add projects" button is now disabled when already adding projects (to prevent concurrent requests).
  • The project list's loading spinner was moved/re-styled to avoid the list jumping around.
  • Various derived state was refactored into store getters, e.g., isUpdatingProjects.
  • Various unused imported components were removed.
  • The initial loading spinner's padding was increased.
  • Various styling tweaks to conform better with design specifications.
Previous description

This is currently very much a WIP!

It's based on top of !18018 (closed), which itself is based on a rebased copy of !17908 (merged). In other words, this MR isn't going anywhere until those are merged, one way or another 😄

Anyway, to answer the question, this MR currently:

  • Passes through the project add and list endpoints to the ISD component.
  • Binds the correct module name (projectSelector) within the ISD component.
  • Creates a new security dashboard store plugin which registers the projectSelector store module, and sets up a mutation subscription. This subscription basically syncs up the dashboard's project filter dropdown with whatever projects have been chosen with the project manager component.
  • Adds the project manager component to the ISD component.
  • Adds a top margin to improve look of loading spinner.
  • Fixes a race condition where invalid project's names are not displayed in flash, because selectedProjects is cleared before success action runs.
  • Disables the "Add projects" button when already adding projects to prevent multiple requests.
  • Tweaks the loading spinner display logic on the project manager's project list.
  • Updates the filters/setFilterOptions action to conditionally reset that filter if the new set of options is incompatible with the currently selected options.
    • The main purpose of this is to ensure that if a user has filtered the dashboard to a particular set of projects, and they then remove one or more of those projects via the project manager, the project filter is reset to 'all'.
    • A nice side-effect of this is that if the user navigates to a URL with an invalid project_id in the URL, the project filter gets reset to 'all'. Previously, the dropdown would just render in an inconsistent state.

What does this MR do that it probably shouldn't be doing?

  • Everything from !18018 (closed) and !17908 (merged), which means all backend changes, and some entry point changes.
  • It sets equivalent-but-incorrect endpoints in the HAML page entry, so that the ISD is actually usable. The real entry points don't exist yet.
  • The technique of conditionally calling filters/setFilter means that the list of vulnerabilities can be re-fetched while the user is still interacting with the project manager. Given that the list of vulnerabilities is always re-fetched when switching back to the dashboard anyway, this means the vulnerabilities could be fetched more than once, which is not efficient.
  • The list of vulnerabilities is always re-fetched when switching back to the dashboard, regardless of whether there were any changes to the list of projects. Given we've had performance issues with the Group Security Dashboard, I would think the ISD wouldn't be any faster, so we should probably try to minimise unnecessary requests.

What does this MR not do that it probably should?

  • Add/update tests
  • Probably other things

Screenshots

Note that these screenshots can only be recreated by applying this patch to this branch, since the backend isn't in place yet.

Instance Security Dashboard Empty state

Instance Security Dashboard Project Manager

Instance Security Dashboard

Does this MR meet the acceptance criteria?

Conformity

Performance and Testing

Edited by Mark Florian

Merge request reports