Various documentation changes related to reports and dashboards

docs/admin-gui/dashboards/index.adoc

@@ -18,21 +18,22 @@ From the early days of midPoint there were two hardcoded dashboards: end-user ho
 That was fine while midPoint was a simple IDM system.
 But now we are into identity governance, compliance, risk management support and other business-oriented aspects of identity.
 Whenever a "business" is involved there is a need for quick and clear presentation of data.
-Therefore the old hardcoded dashboards are no longer adequate for the job.
+Therefore, the old hardcoded dashboards are no longer adequate for the job.
 
 == More Dashboards
 
 When it comes to data presentation, there is no single way how to do it right.
 Security officer will be interested in certain specific aspects of data, but that aspects make little sense for a business manager.
 And then data protection officer will need yet another way to present the data.
-Therefore we need something that will be flexible and customizable.
+Therefore, we need something that will be flexible and customizable.
 Such as customizable dashboards.
 
 In midPoint universe, dashboards are first-class citizens.
 Each deployment can have as many dashboards as needed, and they can contain custom "widgets" used to present interesting pieces of information.
 Simple widgets can present data from xref:/midpoint/reference/admin-gui/collections-views/[object collections], such as number of active employees, number of failed resources, suspended tasks and so.
 That is an elegant way to create _status dashboards_ showing status of important system components.
-But collections are much more powerful, especially the ability to define collection _domain_. Therefore dynamic dashboard can be used for xref:/midpoint/features/planned/compliance/[compliance] purposes.
+But collections are much more powerful, especially the ability to define collection _domain_.
+Therefore, dynamic dashboards can be used for xref:/midpoint/features/planned/compliance/[compliance] purposes.
 Data protection dashboards may be set up.
 And so on.
 
@@ -49,7 +50,7 @@ But there is one use case when dashboards and reports work together: status repo
 System administrators often like to get regular mail summary of system operation during last 24 hours.
 But we already have a dashboard functionality for the same thing.
 And here in the midPoint land we simply hate to duplicate functionality.
-Therefore there is a printable and mailable version of status dashboard.
+Therefore, there is a printable and mailable version of status dashboard.
 And that is exactly what status report is about.
 The report takes status dashboard configuration as an input.
 But instead of displaying dashboards in an interactive way it renders them in a stand-alone static way.

docs/misc/reports/configuration/collection-report.adoc

@@ -179,8 +179,6 @@ The _resource_ parameter will be set before the report is run.
 Usage of the parameter is very simple.
 We just use the name of the parameter in expression of query.
 
-// TODO
-
 image::collection-parameters.png[]
 
 .Object collection report with parameter
@@ -556,9 +554,6 @@ return object?.assignments?.findAll(a -> a.targetRef != null)
 This would be used in the `assignment` sub-report with `splitParentRow` option.
 * Finally, you can resolve these refs, but not dropping the rows to preserve the rows for the owning object.
 
-// If you wanted just a single row for multiple unresolved targetRefs, the things get complicated, but that is already beyond the scope of this example.
-// It's probably better to get `assignment.targetRef.oid` into one of the columns and use that to deal with the broken references instead.
-
 In any case, with great power comes great responsibility - and both `splitParentRow` and `removeParentRow` behavior gives you a lot of power.
 
 ==== Example of Generated Report
@@ -567,3 +562,13 @@ In the picture below we can see an example of generated HTML report of all users
 Report contains columns for Name, Full Name, Administrative status, Roles, Organizations and Accounts of every user.
 
 image::collection-example.png[]
+
+
+== See Also
+
+- xref:/midpoint/reference/misc/reports/examples/[Report Examples]
+- xref:/midpoint/reference/misc/reports/configuration/[Report Configuration]
+- xref:/midpoint/reference/misc/reports/configuration/collection-report.adoc[Collection Based Reports]
+- xref:/midpoint/reference/misc/reports/configuration/dashboard-report.adoc[Dashboard Based Reports]
+- xref:/midpoint/reference/misc/reports/configuration/report-security.adoc[Report Security]
+- xref:/midpoint/reference/misc/reports/configuration/report-task-definition.adoc[Report Task Definition]

docs/misc/reports/configuration/dashboard-report.adoc

@@ -33,23 +33,20 @@ Following code shows basic configuration of dashboard report.
 </report>
 ----
 
-// TODO rephrase
-Configuration for the dashboard report contains definition for _view_.
-The _view_ attribute in dashboard report is multivalued.
-We can configure view for every type of objects, which are showed via widgets.
-View defines columns of table in report.
 
-image::dashboard-view.png[]
+The _view_ (configuration of columns present in the report) can be defined at a couple of places in midPoint.
+
+image::dashboard-view.png[75%]
 
 For example in our picture, in the first line under screenshot, you can see the views for types `ResourceType`, `AuditEventRecordType` and `TaskType`.
 
 The final view of the widget in a dashboard report is merged from the three levels of definitions for the view.
-View in report for type of object, view in dashboard for widget and from view in object collection which contains configuration for widget.
-Columns from views are merged in a same way as in a Collection report.
-Also, we can use attribute `useOnlyReportView` for using only view defined by report.
+The view configuration in a report for the type of object, view in a dashboard for widget and from view in a object collection which contains configuration for a widget.
+Columns from views are merged in the same way as in a Collection report.
+Also, we can use attribute `useOnlyReportView` for using only views defined by report.
 
 When we don't use the _view_ parameters, the report  will contain default columns.
-In expression of column you can use the variable 'object' which represent the searched object or object defined in the _path_ property.
+In an expression for a column you can use the variable 'object' which represent the searched object or object defined in the _path_ property.
 For more information about view configuration please see xref:/midpoint/reference/admin-gui/collections-views/configuration/#views[Views].
 
 .Example of view for RoleType
@@ -122,7 +119,7 @@ return objects.size();
 </report>
 ----
 
-==== Report for asynchronous widget
+==== Report for an Asynchronous Widget
 
 A Dashboard report has two kinds of output.
 The most common case is to generate an output file with reported data.
@@ -149,10 +146,10 @@ Configuration of Dashboard report contains attribute _storeExportedWidgetData_,
 
 |===
 
-==== Example of generated report
+==== Example of Generated Report
 
-On screenshot, we can see an example of a generated report of a Dashboard report in the HTML format.
-On top, we see the table of widgets with name, message and status.
+On the screenshot, we can see an example of a generated report of a Dashboard report in the HTML format.
+On the top, we can see the table of widgets with name, message and status.
 Under the table of widgets, the report continues with one table for every widget.
 
-image::dashboard-example.png[]
+image::dashboard-example.png[75%]