Thanks @nilieskou!

Looking at the schema, I noticed that it already doesn't include the fields that this issue captures to be hidden (#587655), is that correct?

@svedova That is the thing I tried to explain - it currently is not just !isPipelineComplete because we have the this.hasPipeline guard in place.

Without it, we could end up in a state where there is no pipeline and isPipelineIsRunning is true, right?

@svedova Apologies for jumping in, as I was also thinking about this when I suggested it to change to this 😅

isPipelineComplete is false when:

1. MR not loaded yet (mr === null)
2. MR loaded, but no pipeline
3. Pipeline running

isPipelineRunning should only be true in case 3 (Pipeline running). If we drop the hasPipeline check, then it would become true for cases 1, 2 (not loaded, no pipeline) as well.

I think this shows exactly where boolean state falls apart and is so difficult to reason about.

One idea could be using a simple state machine, which really helps to express the different states in a more digestible way:

pipelineState() {
  if (!this.mr) return 'loading';
  if (!this.mr.pipelineIid) return 'no-pipeline';
  if (this.mr.isPipelineActive) return 'running';
  return 'complete';
} 

// ...

statusMessage() {
  if (this.pipelineState === 'running') return s__('MrReports|Waiting for pipeline to complete.');
  if (this.pipelineState === 'no-pipeline') return s__('MrReports|No pipelines started yet...');
  return '';
},

The template would also be quite straightforward. Eg.:

v-if="pipelineState === 'complete'"

We could also use constants for the states.

But just an idea, and maybe something for a follow-up? 🤔

David Pisek (38286291) at 19 Mar 09:07

... and 1 more commit

David Pisek (56300fec) at 19 Mar 09:04

What does this MR do and why?

Changes:

1. Add missing specs for the code quality widget
2. Update the text to use the correct field name:

- check_name
+ engine_name

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

2. Clone this repo and create a MR similar to this: gitlab-org/govern/threat-insights-demos/frontend/mr-reports-code-quality!3
3. Run a successful pipeline and it will generate some findings
4. Expand the code quality widget, it will render the data correctly

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.

LGTM @sming-gitlab - nice work! Approved and setting-auto merge!

What does this MR do and why?

Changes:

1. Add missing specs for the code quality widget
2. Update the text to use the correct field name:

- check_name
+ engine_name

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

2. Clone this repo and create a MR similar to this: gitlab-org/govern/threat-insights-demos/frontend/mr-reports-code-quality!3
3. Run a successful pipeline and it will generate some findings
4. Expand the code quality widget, it will render the data correctly

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.

Ah, very nice @svedova! I really like the idea and will tackle it in a follow-up 🤝

On it next @sming-gitlab 👍

Thanks, Becka! I'll keep that in mind 👍

Thanks for the quick and thorough review @lorenzvanherwaarden! I followed your great suggestion and changed the token's type.

@svedova - Could you please maintainerize? 🙏

That is a great point @lorenzvanherwaarden! I could imagine that the could expand in the future, so I am changing it to malware (also following the existing pattern) 👍

David Pisek (440c2909) at 18 Mar 18:17

Yes, nice work @svedova - approved!

What does this MR do and why?

Add vulnerabilities by age chart to project dashboard

Implement the Vulnerabilities By Age chart for the project-level security dashboard, bringing feature parity with the group-level dashboard while appropriately simplifying for project-level scope.

References

Screenshots or screen recordings

How to set up and validate locally

1. Enable feature flag: project_total_risk_score_chart (http://gdk.test:3000/rails/features/project_vulnerabilities_by_age_chart)
2. Make sure to have a project with vulnerabilities
3. Visit Secure > Security Dashboard
4. Validate Vulnerabilities By Age is showing as expected

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.

Related to gitlab-org#21021

What does this MR do and why?

Handle different lifecycle for MR reports:

1. No pipeline: display status message
2. Pipeline is loading: display loading message
3. Pipeline is complete: render reports

1. No Pipeline	2. Pipeline loading	2. Pipeline complete

MR Series

References

Screenshots or screen recordings

How to set up and validate locally

1. Enable FF:
   • http://gdk.test:3000/rails/features/mr_reports_tab
2. Clone this repo and create a MR similar to this:
   • No pipeline: gitlab-org/govern/threat-insights-demos/frontend/mr-reports-tab!23
   • Has pipeline: gitlab-org/govern/threat-insights-demos/frontend/mr-reports-tab!11
3. Run a pipeline and while it's loading, click on the "Reports" tab, it should render the loading message
4. After pipeline has ran successful, click on the "Reports" tab:
   • No pipeline: it renders the status message
   • Has pipeline: it renders the report + nav (happy path)

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.

Related to #593551

thought: First off, a praise: Thanks for making this more accessible!

One thought, I think it is not ideal to remove/add live-regions from the DOM. I believe some screen readers might miss it, when we move from the "loading" to the "loaded" state.

Here is a great read around this: https://k9n.dev/blog/2025-11-aria-live

Nice one @sming-gitlab, another series to watch 🍿

The changes LGTM! I just left a non-blocking suggestion and a ally thought, so I'll also go ahead and approve 🤝

suggestion (non-blocking): maybe we could slightly improve readability here. Something like:

    hasPipeline() {
      return Boolean(this.mr?.pipelineIid);
    },
    isPipelineComplete() {
      return this.hasPipeline && !this.mr.isPipelineActive;
    },
    isPipelineRunning() {
      return this.hasPipeline && !this.isPipelineComplete;
    },
    hasNoPipeline() {
      return Boolean(this.mr) && !this.hasPipeline;
    },

But also happy to leave as-is 👍