Reports module
The reports module integrates the following three features:
- long running tasks (LRT) – report generation can be cancelled (or killed) the same way as LRT. Report shares LRT's result state (RUNNING, CANCELLED etc.).
- attachments - when a report is generated, the output data is stored as an attachment in json format. Other types of format for storing generated data can be used, too. The generated json data can be loaded again, and "transformed" to other formats - and downloaded by the client (rest endpoint).
- common dynamic forms - used as report filters. Filters are saved and used for searching data, when reports are being generated.
Example
For instance, you can have a report generated, listing all identities in xlsx format - with enabled / disabled identities (so you need to search identities by their enabled status).
Report filters
Dynamic common forms are used for storing report filters. They provide form definitions with attributes, which which can be filled in filter ⇒ executor can use this filter for searching data. IdmFormDefinitionService is used for read and update form definition for given report. Filter attributes can be added and changed (see
compatible vs incompatible changes).
Event processing
Reports are generated by event processing (event type GENERATE), registered processors to this event type:
- -1000 - generate report output json data
- 0 - save report metadata after report is completed / failed
* 1000 - send notification (websocket as default) about report being completed / having failed.
Also provided in the reports module are notification templates reportGenerateFailed and reportGenerateSuccess.
You can create your own processor in a custom module before / after each phase of report generation (or e.g. disable notification).
Security
Generated reports are secured under group REPORT. Authorization policies are implemented:
* SelfReportEvaluator