Add report history view per subject/scope

[guettli]

The compliance monitor previously only showed the latest test result per subject/scope. All historical data was stored in the database but had no UI to browse it. This PR exposes that history.

Note: the counts reflect raw testcase results and do not distinguish required vs. recommended vs. extra testcases for a given scope version. This is intentionally a report history, not a compliance verdict history.

Changes

New endpoint GET /{view_type}/history/{subject}/{scopeuuid}
Returns a chronological list of all past reports for a given subject and scope, newest first, showing date and per-report PASS/FAIL/ABORT counts with a link to each individual report. Capped at 500 entries (most recent); a notice is shown when truncated.

📜 report history links added in two places:

• Detail pages (/page/detail/ and /page/detail_full/) — one link per subject/scope section
• Report pages (/page/report/) — links back to the history list for that subject/scope

New SQL function db_get_report_history — aggregates pass/fail/abort counts per report for a given subject and scope, ordered by date descending.

Bug fix: db_upgrade_schema crashed with TypeError on a fresh database (None >= 'v4'). Fixed the guard condition to check for None first.

No schema changes required

All historical reports were already stored. This PR only adds read paths.

[mbuechse]

The code is good, I think. I have two concerns:

• we should add Generated-by: <insert AI model here> to the commit message
• I'm wondering what this history is actually showing

Let me elaborate on the latter. The database does contain results (of the form pass/fail/abort) for combinations of subject, scope, testcase id. These results are used to compute whether a subject complies with some version of the scope. Depending on the version, only a strict subset of testcases can be required to pass that version.

This history view only counts the number of passed, failed, and aborted testcases for a given subject, scope, and report date, which means it doesn't distinguish between

• testcases that are required for a certain version,
• testcases that are merely recommended,
• testcases that are (erroneously) present in the database but not even part of any version, and
• testcases that are required but missing in the database (because they haven't been reported).

So what we see here is basically an overview of the reports, without any qualification of the data with respect to its import.

In summary, I would say this is NOT a compliance history, but merely a report history. Your mileage may vary as to how useful this is.

[guettli]

@mbuechse our use-case: See historical reports, so we can differentiate between flakes and constant failures.

[mbuechse]

@guettli I see. However, wouldn't it make more sense then to restrict the view to a specific testcase, so you can see whether the result for that given testcase oscillates? With the sums, you don't see it, because (worst case) two testcases could fail alternatingly, and then the sums stay the same, which would give the false impression of stability.

[guettli]

@mbuechse nice, that you care for our user experience. Overall I think the current view makes sense.

On top we could add a view which shows the history of one tests.

What do you think: Extend existing PR or create follow-up PR?

[mbuechse]

nice, that you care for our user experience.

@guettli I wouldn't quite put it that way. What I care for is that we don't haphazardly extend the assortment of views to cater to very particular or ad-hoc use cases.

I would actually prefer to have a discussion and a general alignment among the community on what problems we want to solve and how best to solve them, before we start working on solving them.

[mbuechse]

If you don't want to enter a discussion about what kinds of problems we want to solve and what views would be most suitable for a wide audience, I would propose to extend the endpoint

standards/compliance-monitor/monitor.py

Line 772 in f76ee40

async def get_results(

to accept a subject and scope, so you can download and evaluate results any way you like. If a subject is given, it should also be passed on to check_role, so an account without role read_any can at least download their own results.

[guettli]

If you don't want to enter a discussion about what kinds of problems we want to solve and what views would be most suitable for a wide audience, I would propose to extend the endpoint

standards/compliance-monitor/monitor.py

Line 772 in f76ee40

async def get_results(

to accept a subject and scope, so you can download and evaluate results any way you like. If a subject is given, it should also be passed on to check_role, so an account without role read_any can at least download their own results.

Wait a second. My PR is just about changing the web UI. There is a new API, but this was not the intention of he PR.

I can extend the API, but then I need to extend the docs, too.

Where is the API documented?

[mbuechse]

See here: https://github.com/SovereignCloudStack/standards/tree/f76ee406e52908b4e7450af25a99bd8ef9ed703a/compliance-monitor#endpoints

[guettli]

See here: https://github.com/SovereignCloudStack/standards/tree/f76ee406e52908b4e7450af25a99bd8ef9ed703a/compliance-monitor#endpoints

I adapted the PR, please tell me what needs to be improved.