Added Dashboard UI enhancements, user can control whether the delete dialog is present or not

[romil-bijarnia]

Below are the list of modifications I have made as a part of this pull request:

1. The dashboard has been hooked to the backend showing the user with the relevant information based on their usage of the system.

2. User can control if a delete dialog should be shown/not as a part of the user settings (this is restricted to deleting scans for now):

the dialog being used for delete is a browser native confirm at this stage(like the other dialogs), we should build a custom modal for dialogs later.

I have also added a compliance trend as part of the visualization metric, let me know what everyone's thoughts are.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4c266a5fd1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[du-dhartley]

@romil-bijarnia looking for some feedback on the comments provided here. It would be beneficial to understand the ENABLE_POWERSHELL_CONTROLS thought process before approving this one.

I personally dislike the ability to delete without a confirmation and think it should always require a second click, especially where data required for audits is concerned. Is this primarily a development-based function that is aimed at developers, rather than end users?

My final thought - once again we have a pull request that covers 3 distinct areas (backend, engine and frontend). We really do need to stop making changes across distinct areas like this, and separate them into their own pull requests. There are several reasons for this, most notably the fact that this will result in significant issues down the track when the contributor base is much larger and there are distinct teams for these areas.

[du-dhartley]

I quite like the dashboard revamp and think this feels more intuitive. However, there are a couple of inconsistencies.

1. If we are indicating to the user that they are looking at a trend, then we need a horizontal line that indicates the trend. It should be even, negative or positive and should be overlaid on the bar chart. The idea is that the user doesn't need to assess the whole chart and determine if the "overall" compliance percentage is increasing over time or not, especially if the bars vary significantly.

2. The compliance score stat is a good one and shows that it's working on the latest completed scan. However the 18% in the screenshot does not line up with the "53% compliance" result directly underneath it. How are these charts put together?

3. Controls that error should not be considered failures. If we are unable to determine whether a control passed or failed, we should indicate that it errored, not that the control failed. I suggest that we have a 3rd section of the pie/donut chart that indicates these errored controls, and possibly a 4th to show controls that are skipped. Controls that error when checking, or are skipped, should be counted as neither passed nor failed, otherwise we're incorrectly reporting statistics to the users.

[romil-bijarnia]

@romil-bijarnia looking for some feedback on the comments provided here. It would be beneficial to understand the ENABLE_POWERSHELL_CONTROLS thought process before approving this one.

I personally dislike the ability to delete without a confirmation and think it should always require a second click, especially where data required for audits is concerned. Is this primarily a development-based function that is aimed at developers, rather than end users?

My final thought - once again we have a pull request that covers 3 distinct areas (backend, engine and frontend). We really do need to stop making changes across distinct areas like this, and separate them into their own pull requests. There are several reasons for this, most notably the fact that this will result in significant issues down the track when the contributor base is much larger and there are distinct teams for these areas.

David, regarding the deletable scans, it is dev only. I can for sure be changed later on as needed.
Also a sidepoint to add, there is an option to enable a confirmation dialog everytime you try to delete a scan

[romil-bijarnia]

I noticed some leftover merge-conflict markers (e.g., ======= and >>>>>>>) that slipped in from a previous merge/rebase. I found them and removed them immediately so the file is clean again.