Dashboards, Widgets and Reports Design Notes
|
EXPERIMENTAL
This feature is experimental. It means that it is not intended for production use. The feature is not finished. It is not stable. The implementation may contain bugs, the configuration may change at any moment without any warning and it may not work at all. Use at your own risk. This feature is not covered by midPoint support. In case that you are interested in supporting development of this feature, please consider purchasing midPoint Platform subscription. |
Responsibilities
-
Dashboards/widgets: interactive representation of data. Can change colors, can be clicked. May be used to execute additional actions. Widgets may define some logic, but that is limited to presentation logic. E.g. widgets turns red if number of errors is more that 5%. Widgets do not define other logic (e.g. notifications). That is responsibility of policy rules on collections or individual objects.
-
Reports: non-interactive representation of data. Reports usually work directly on objects or collections. Reports do not use dashboards or widgets. Except for status reports (see below).
-
Collections: specify groups of data, e.g. active employees, business roles, etc. Collections may also define rules what to do with the data by using policy rules. E.g. collection may define: "Notify security officer if the proportion of high-risk roles is more than 10% of all roles. Or "notify system administrators if more than 5% resources are down". Artifacts and other abstract roles are also implicit collections. Therefore we can also defined rules such as "notify role owner if role has more than 20 approvers".
-
Views: present data to user in a tabular form. Mostly for interactive use in the GUI. But can be used for "lightweight reports". Still not entirely clear. But it seems feasible.
Collection policy rules and widgets may cooperate using policySituation. E.g. collection policy rules set policySituation of "Resouces Up" collection to #resourceHealthDanger. Then the corresponding widget will turn color to red when the collection has such policySituation.
Reports and dashboards do not cooperate directly. They should both depend on collections. If there is something that should be common for all possible representation of the data then it should be defined in the collection. Except for one case: status reports. Those reports are static representation of the widgets. But other reports are working on objects or collections directly.
Misc
We want DashboardType as a new ObjectType in midPoint, because:
-
Authorizations. Different people may be able to see different dashboards.
-
Identification: dashboards may be referenced from several places, e.g. adminGuiConfig
-
Usablility: we want "dashboard wizard" or "dashboard editor" later on.
Policy rules on collections cannot be evaluated in normal projector processing. They do not apply on the object (collection definition) itself. They apply on the objects that the collection groups. And the policy rules may be triggered even if collection definition does not change. Therefore there is no point in processing them in projector anyway. We need a special scanner task for this. That task will evaluate the collection and process triggered policy rules.
TODO: storing trends and history in collections
Samples
Planed object with comments: https://github.com/Evolveum/midpoint-samples/tree/master/samples/experimental
Official sample which was tested: https://github.com/Evolveum/midpoint-samples/tree/master/samples/dashboard
Plan
4.0 Gutenberg
Simple status dashboards and reports. Some things hardcoded.
Full evaluation of collection policy rules not supported (no scanner task). Policy rules are only evaluated by widgets and status reports. Only direct policy rules in collection assignments are supported. No metaroles, no sophistication. Normal projector run will completely ignore policy rules with collectionStats constraint. Those wil be only evaluated by a special function that is used by widgets/reports.
No data caching. Every rendering of the dashboard will count the objects in the repo.
Later
Depends on subscribers. This is part of Flexible Dashboard planned feature. Some parts of this may be also needed for Compliance.