Add CycloneDX and SBOM reports back to the Reports page

[bs-ondem]

After the introduction of the SBOM page, the CycloneDX and SBOM reports were removed from the Reports page. This can be misleading, as the Reports page is intended to contain all downloadable reports. Removing these reports from the page creates confusion about where users can access them.

[sschuberth]

the Reports page is intended to contain all downloadable reports.

That's exactly the debatable point. Actually, my goal would be to get rid of the reports page completely, and display whatever report may be get generated in a more suitable place.

The main reason for this is that ORT's reports server very diffident purposes. So instead of cramming everything into a report page just because it was created by the reporter, I'd rather group reports by their purpose and / or target audience.

Also, with SBOM being such a buzzword now, to me it makes sense to make them stand out prominently and guide the user where to find and download them from the menu, instead of "burying" them in a list of other reports.

To sum up, I think SBOMs should stay at an "SBOMs" menu in the "Compliance" section. Another entry could be "Attributions" for NOTICE files etc.

More technical reports that are not meant for distribution, like the WebApp and Static HTML report, could actually go to the "Technical" section.

Finally, there probably are a bunch of reports that are not usually needed, but that we'd still like to offer for download, but on demand. For these, I imagine an "Export" section that creates there reports on the fly, instead of creating everything "just in case" beforehand. This goes a bit into the direction of a more event-driven working paradigm, instead of the still very sequential job runs that we currently have.

[bs-ondem]

Also, with SBOM being such a buzzword now, to me it makes sense to make them stand out prominently and guide the user where to find and download them from the menu, instead of "burying" them in a list of other reports.

I agree with and like this approach! However, since the Reports page still exists and the CycloneDX/SBOM reports are missing from it, this can be misleading and cause confusion. The users might think that the reports couldn't be generated for some reason. Therefore, I would suggest keeping all generated reports available on the Reports page for now, until the separate sections for other report types are implemented. Once the new structure is in place, they can navigate more efficiently to the correct section for specific report types and the Reports page can be removed.

[sschuberth]

I would suggest keeping all generated reports available on the Reports page for now, until the separate sections for other report types are implemented.

As one is probably not much more implementation effort than the other, I'd rather go the opposite direction and quickly agree on

1. what are the reports that we always want to generate (because having the SBOM and others in dedicated menus implies that the user should not be able to disable them), and
2. where / in which sections to put these reports.

[mnonnenmacher]

implies that the user should be able to disable them

Did you mean "NOT be able"? The reporter step could be skipped, so the UI should be prepared for the SBOMs not being available.

where / in which sections to put these reports.

Keep in mind that for custom templates we cannot know the type of the report, so some "catch all" section would be required. At least as long as report types are not a feature of ORT itself so that template authors could set a type somehow.

[sschuberth]

Did you mean "NOT be able"?

Yes, I'll correct it in the original post.

The reporter step could be skipped

This is yet another thing to discuss. As said multiple times, I'd like to move away from this step-based mental model. Esp. the reporter step could be removed completely, in the sense that it is not visible to user and cannot be disabled, and some reports could always be generated, others only on demand (the "Export" functionality).

so some "catch all" section would be required.

True. We could call these "Custom reports" or so.

At least as long as report types are not a feature of ORT itself so that template authors could set a type somehow.

Hmm, interesting idea. A report type could become a report plugin property...

[hanna-modica]

I see, that the UI should not be redundant, since it will have a lot of options in the menu probably soon. I still would like a page where I can easily find all generated reports. So here I do not agree with @bs-ondem, that we can get rid of that overview later.
However, I am open to how this need for an overview can be met (should it be agreed, that this is a need :) )
Possible solutions I can think of right now are:

• Page with links to all report subpages (like the current SBOM)
• Links to all report subpages on the main page
• A report page like we have now, but better structuring via e.g. headlines

And if we would have such an overview, I would also like it to contain the information, which reports were enabled in the reporter. Of course, one can always look this up in the run configuration, but I would find it convenient to have this information right where I am looking for the report.

[sschuberth]

We've discussed this in-person with @hanna-modica and @mnonnenmacher at FOSS Backstage. The agreed plan is to introduce a "Reports" menu group with (for now) just "SBOMs" and "Other" sub-menu items, and use the current SBOM page as-is for the respective sub-menu, and put all other reports under "Other".

Perspectively, we'd like to introduce dedicated report types to ORT's reporter tool, so we can automatically use more fine-grained grouping than just "Other".