In midPoint 4.0 several objects were "promoted" to be able to contain assignments. Object collection was one of those. This means, that object collections can now contain policy rules. In a typical midPoint tradition of reuse, we want to apply policy rules to the collections themselves. Therefore reaching a specific threshold may be just a new constraint for a policy rule. Then the usual actions associated with policy rules can be applied. Which, once again, works very well with somehow an independent functionality with quite similar effect: Thresholds thresholds.
Object collection policy rules functionality is a synergistic feature. It is designed as an natural extension of existing midPoint features such as Policy Rules policy rules and Thresholds thresholds.
Phase 1: Collections and Views
- Lightweight recompute process that will only update policy rule situations. Currently the policy situation gets updated during full recompute. This is perfectly acceptable for consistent small-to-medium scale deployments. But for complex, large and/or partially inconsistent deployments an improvement to recompute process may be needed.
- "Quick preview" of a policy rule effect: GUI functionality that transparently sets up policy situation for the rule (or rulesets/policies) and associates a collection(s) with it.
- The concept of policy as a collection of related policy rules. The policy may be used to evaluate many related policy rules together, version them together, control their lifecycle and so on.
- It may be needed to record assignments that are not yet approved (e.g. in proposed lifecycle state). Currently such assignments are only part of the delta which is encapsulated in approval processes and work items. It is not directly observable in the objects (e.g. users).
- Support for several custom dashboards, e.g. operational dashboard, security dashboard, compliance dashboard. Each dashboard with a custom set of widgets.
- Archetypes (meta-roles) could act as implicit collections. As could any in fact any (abstract) role. As could orgs, but there the membership in collection can go deeper, which may be tricky to do implicitly. But all of this assumes that we will have full support for configurable relations. Otherwise we won't know which relation to consider for collection. E.g. we want role members (relation=default) to be members of the collection, but we do not want role owners or approvers.
- Compliance is heavily based on object collections.
- Customizable Dashboards are meant to display collection information.
Those features are anticipated in the future, but they are not yet planned to any specific midPoint version or implementation date.
JIRA server Evolveum Jira serverId 701b45f2-090c-3276-8ac9-f45eedf731bc key MID-3408 JIRA server Evolveum Jira serverId 701b45f2-090c-3276-8ac9-f45eedf731bc key MID-3517
- Policy Rules
- Object collections and views configuration
- Customizable Dashboards