RFC: Rewrite the reports module

[robbieaverill]

Description

The Report API is essentially an abstract PHP class which you can extend in order to define your title, description, columns, source records, formatting for table cells, etc. This is relatively simple, flexible, and powerful, but is old and lenient (as opposed to being a strict, interface based API).

One of the architectural problems I see with reports is that they're "dynamic" rather than generated at a given date/time and recorded in history. This actually makes it very difficult to do any kind of auditing with the reports, since they're essentially acting more like dashboard widgets than "reports". Examples of reports that have been twisted around a bit to behave more like actual reports are the silverstripe-maintenance module and the externallinks module.

I'm proposing that we rewrite the module, providing a new ReportInterface and have reports be configured with YAML rather than magically looked up.

Suggestions

• React driven user interface
• "Generate report" button in the UI
• Cron job generates reports
  • No longer "dynamic"
  • Increase in performance for large data sets, since data list is flat and static - any custom formatting is applied when the report is generated, which is async
• Stricter PHP interface for defining reports
• Reports are no longer dynamic, but represent a pre-generated list of report data
  • Reports are generated on a cron
• Automatic cleanup
  • You can configure the maximum age for report data (e.g. 30 days), or disable it
  • You can configure the maximum pool size for report data (e.g. I only want 3 reports, then everything older is removed), or disable it
• Keep the concepts such as field formatting, but tighten up how it's implemented
• Ensure that exporting to CSV and print views use the same data (example issue: GridField: Export and print do not honour GridFieldDataColumns formatting rules silverstripe-framework#9172)
• Powered by GraphQL

Implementation ideas

I'm thinking that this wouldn't use GridField at all, but would have a custom implementation of a table. A problem with this approach would be the same as that of the React GridField RFC, e.g. how do PHP initiated report interfaces or data models adjust the report columns or formatting in a way that can be exposed through GraphQL.

In the case of this module, the PHP implementation of the report and/or report data entry for it could define the columns that should be used in the report (which is extensible), and we could use a dynamically constructed, injectable GraphQL query to retrieve those columns through the API in order to display them in the report. I think this is possible already at this point.

We could potentially abstract the parts of the frontend report UI out enough that you may be able to define a custom "MyReportRow" React component (or maybe even a cell component) for a particular report ("MyReport") which could be loaded over the OOB equivalent component from this module. Here you could control how the row, or the cell, is rendered in the report - e.g. add text formatting, add extra context, buttons, etc.

Versioning

My proposal is that we deprecate the entire existing silverstripe/reports API surface and build a completely new one, including it in a new minor release. We could allow the new system to be opt in/out via a configuration flag somewhere (or even run both alongside each other) so devs can switch to/from the new implementation easily if their project has custom reports that aren't compatible, or they've got modules with reports like this.