CDM-403 All reports can be exported as CSV or XML document. Acceptance Criteria: -There are currently 9 reports in JON3.0.1 under /coregui/#Reports/. 6 under Subsystems and 3 under Inventory. For each of these reports a JON user should be able to download, via the UI, the contents of the individual reports for processing/review offline. -Exported reports should honour the permissions settings of the person doing the export, e.g. if the exporting user doesn't have permission to see particular data it should not be included in the exported report. Assuming the UI is already doing this, the report export should just match the UI. [No special permissions management is required to handle the Ancestry column, e.g. links to resources the exporter should not be able to see can be included, but they will be prevented from seeing any further data when following the URL. Considerations: -The first priority should be CSV exports -We use html links extensively in our report tables, since CSV doesn't lend itself well to hyperlinks (given its a plain text format) there will obviously be more columns in the CSV output than in the UI. The "Ancestry" column is a good example of this issue. There is a theoretically limitless depth of child-parent relationships all condensed into a single UI column. -No column delimiter is specified for the CSV files as part of the requirements. A standard delimiter should be used, and then obviously needs to be escaped in a standard way if the delimiter appears in the report data. -A standard (cross-platform) delimiter should be used to delimit different rows in the CSV export. This may need to be escaped also. -There will be an infinite number of ways to encode the report data in xml, lets not make the desire to get a perfect representation get in the way of building one which is good enough. -Seeing how the RHQ CLI represents similar tabular data to the reports may be instructive. -We should limit the amount of data returned when exporting a report, e.g. if we have 2million recent alerts we should not produce a 20GB export file which crushes the server when its generated. We need to place sensible limts on the report size -The UI reports also include extra data thats shown on mouse-over. If this is deemed relevant it should be included in the exported report. -There is no requirement to support exporting reports through the CLI. -One of the reports, Inventory>Drift Compliance, uses the Master + Detail model, rather than just a straight table of data. This could be more difficult to render in a single CSV export. One option could be turning: Master table: selected>M1A M1B M1C M1D M2A M2B M2C M2D Detail table: D1A D1B D1C D2A D2B D2C D3A D3B D3C into a CSV like: M1A M1B M1C M1D D1A D1B D1C M1A M1B M1C M1D D2A D2B D2C M1A M1B M1C M1D D3A D3B D3C M2A M2B M2C M2D ... M2A M2B M2C M2D...
ccrouch: UPDATE: This got erroneously triaged, setting to JON3.1
The request for this capability has come up a few times and as a result we have the following Red Hat Knowledgebase solutions describing exporting of metric type data/reports using the CLI: https://access.redhat.com/knowledge/solutions/26672 https://access.redhat.com/knowledge/solutions/19356 https://access.redhat.com/knowledge/solutions/58724 Although the capability to export the reports from the UI will not achieve all the metric export/report features being identified in previous user request, this capability would address some of the issue.
marking this verified. tested as follows https://tcms.engineering.redhat.com/run/39563/ https://tcms.engineering.redhat.com/run/39614/
Bulk closing of old issues in VERIFIED state.