Home page "Reports" tile never shows the "+N this month" badge

[AKercha1]

What's wrong

On the home page, the "By the numbers" section shows a green "+N this month" badge on each tile. The Reports tile never shows one - even when reports are actively being added.

To be clear up front: no data is missing. The total count is correct and does update - the DB currently has 60 approved/visible reports and the page now shows 60 (the screenshot caught it at 58, just before two reports got approved). The bug is only the missing "+N this month" badge.

Why it happens

The "this month" number is calculated as "how many reports have a date within the last month":

// Backend/.../Data/Processors/ReportProcessor.cs  ->  GetStatisticsChanges()
var ago = DateTime.UtcNow.AddMonths(-1);
var newReports = await db.Report
    .Where(v => v.Status == ReportModelStatus.Approved && !v.IsHidden && !v.IsDeleted && v.Date >= ago)
    .CountAsync();

The catch: report.Date is the audit date typed in by whoever uploads the report — not the date the report was added to the portal. Audit reports are almost always dated more than a month before we publish them, so Date >= oneMonthAgo is basically never true. Result: the counter sits at 0 forever.

Two real examples from the reports added today:

• Volta Wallet – Zellic - uploaded today, audit date Jan 30
• Spectra Bridge – Certora - uploaded today, audit date May 1

Both brand new on the portal, both invisible to the "this month" counter.

The Vulnerabilities tile shows "+141 this month" and looks like it works - but only by accident. Vulnerability records get their date set to roughly when they're ingested (recent), while reports keep the real audit date (old). So the two tiles are measuring two different things.

Rough fix

The "new this month" metric should be based on when the report was added to the portal, not on the audit date.

Cleanest option:

• Add a created_at column to the report table (set it on insert), and change GetStatisticsChanges() to filter on created_at >= ago instead of Date >= ago.

Quick-and-dirty option (no migration):

• Filter on last_action_at >= ago instead. It's approximate (that field also moves whenever a report is edited/re-approved), but it's much closer to reality than the audit date.

While we're at it, it'd be worth making Vulnerabilities / Protocols / Auditors use the same "added to portal" date too, so all four tiles count the same way.

Affected code:

• Backend/SorobanSecurityPortalApi/Data/Processors/ReportProcessor.cs → GetStatisticsChanges()
• same pattern in VulnerabilityProcessor.cs (and the protocol/auditor equivalents)

[Johnsource-hub]

Hello, I’m a full stack developer with hands-on experience building with variety of tools including Nextjs, nodejs, nestjs, React, Typescript and more

I focus on writing clear, maintainable code and making sure features work as expected end to end, not just in isolation. I communicate progress regularly and keep things transparent as I work. I’m confident I can complete this task within an ETA of 4 HOURS

[xJeffx23]

Hello!

My name is Jefferson, and I have been contributing to open-source projects for over a year. I have participated in multiple hackathons and have experience working with backend systems, data processing logic, and web applications.

I would like to work on this issue because it affects the accuracy of an important user-facing metric. After reviewing the description, it seems the current implementation measures the audit date rather than the date a report was added to the portal, which causes the "this month" counter to remain at zero even when new reports are actively being published.

My plan would be to review the available timestamp fields in the report model, determine whether a dedicated creation timestamp already exists, and update the statistics calculation to use a portal-ingestion date instead of the audit date. I would also review the equivalent logic for vulnerabilities, protocols, and auditors to ensure all statistics are calculated consistently.

I would greatly appreciate the opportunity to contribute to the project. Thank you for your time and consideration!

[Benedict315]

Hello please I would like to work on this issue

[MAN7A-afk]

Hi Maintainer,

I would love to work on the issues with the Soroban event ingestion pipeline by improving parser observability and schema drift detection. I have experience working with TypeScript and backend systems, and I'm comfortable implementing monitoring, metrics, structured diagnostics, and health endpoints.

My approach would focus on making schema mismatches and parser rejections immediately visible, classifying unknown events separately from parse errors, and building a lightweight drift detector that compares runtime events against expected metadata. I'd also ensure rejected events include safe diagnostic information to simplify debugging without exposing sensitive data.

I'm keen to contribute a reliable solution that makes ingestion failures easier to detect, investigate, and resolve.

[Stanley-Owoh]

Good day, I would like to work on this issue. I will update the statistics logic to use a portal-ingestion timestamp rather than the audit date, ensure the Reports tile correctly reflects newly added reports, and review the related processors for consistency across all dashboard metrics. Please assign this issue to me if it is available.

[Shadow-MMN]

Hey, I have read through the issue. The goal is to fix the "Reports" tile so that the "+N this month" badge correctly reflects reports added to the portal within the last month instead of relying on the audit date stored in the report.

I will investigate the statistics calculation in ReportProcessor.GetStatisticsChanges() and update the logic to use a portal-ingestion timestamp rather than the report's audit date. Depending on the existing data model and project preference, I will either introduce a dedicated created_at field with the necessary migration and insert logic, or use an existing timestamp such as last_action_at if a migration-free solution is preferred. I will also review the equivalent implementations in the vulnerability, protocol, and auditor processors to ensure the "this month" metric is calculated consistently across all four tiles.

For validation, I will create and test records with historical audit dates but recent portal additions, verify that the total counts remain unchanged, and confirm that the monthly badges update correctly. I will also perform regression testing on the other statistics tiles to ensure the change does not affect existing counts or dashboard behavior. Screenshots and test results will be included with the PR.

ETA within 24 hours.

As for my experience, you can check my GitHub profile and see past projects that I have contributed to.

[grantfox-oss]

🦊 GrantFox — @Stanley-Owoh has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #201)
2. Your PR will be reviewed by the Inferara maintainers

Good luck! Track your progress on GrantFox.