Page tree
Skip to end of metadata
Go to start of metadata

MidPoint 4.0 and later, but still incomplete

This feature is available in midPoint 4.0 and later. While most parts of this functionality are developed and ready to be used, some functionality is still missing.

In case that you are interested in supporting development of this feature, or even when using this functionality, we strongly recommend activating midPoint Platform subscription.

Introduction

MidPoint objects are quite a social animals. They like to be grouped together. There is often need to show collections of objects, such as employees, active users, new proposed roles and so on. MidPoint has a flexible search and filter functionality that can be used for this purpose. However, those collections are used so often that they deserve a special place in the system. Those collections deserve its own definition, its own name and its own form of presentation. That is the reason why midPoint supports functionality for object collections and views.

Collections and views are two concepts that are very related, but still somehow distinct:

  • Object collection is a core midPoint concept. There is a special object type (ObjectCollectionType) that is used to define a collection. It is first-class midPoint object. Collection defines which objects belong to the collection. The plan is that collections can be used in the entire midPoint system, e.g. collections can be used in authorizations, policy rules may be applied to them and so on. Some midPoint objects can act as an implicit collections, especially archetypes and organizational units. Object collections are designed to be solid and stable. Something that midPoint policies can rely on.
  • View is a user interface concept. View specifies how a particular collection should be displayed. It defines the columns that should be displayed, default sorting, pre-defined filter properties and so on. Views are designed to be flexible, customizable. E.g. views can adjusted and overridden in admin GUI configuration.

Although collections and view have different purposes and they are based on different mechanisms, they are almost always used together.

Object Collection

Object collection is a special midPoint objects. The collection usually specifies a search filter that is used to find all the objects that belong to the collection:

<objectCollection oid="9276c3a6-5790-11e9-a931-efe1b34f25f6">
    <name>Active Users</name>
    <type>UserType</type>
    <filter>
    	<q:equal>
    		<q:path>activation/effectiveStatus</q:path>
    		<q:value>enabled</q:value>
    	</q:equal>
    </filter>
</objectCollection>

Simply speaking this is efficiently a named object filter. The filter is specified in a single place in the object collection definition. Then the definition is reused in all other places.

It may seem that this is a very little functionality to justify its own object. However, most of the functionality is still not implemented. See Object Collections and Views Improvements page for the details.

Derived Object Collection

Some collections are often based on other collections. For example active employees collection may be based on employee archetype:

<objectCollection>
    <name>Active employees</name>
    <type>UserType</type>
    <filter>
    	<q:equal>
    		<q:path>activation/effectiveStatus</q:path>
    		<q:value>enabled</q:value>
    	</q:equal>
    </filter>
    <baseCollection>
    	<collectionRef oid="7135e68c-ee53-11e8-8025-170b77da3fd6" type="ArchetypeType"/> <!-- Employee archetype -->
    </baseCollection>
</objectCollection>

This makes it easy to maintain the collections, as the definitions do not need to be copied in the collections. The collections can refer to each other. Therefore is one definition changes, all the collections take notice.

Configuration Consistency

The use of collections in midPoint 4.0 is somehow limited. In future midPoint releases, cCollections may be reused in authorizations and policy rules. E.g. It would be nice to use just "employees" as a criterion in authorizations instead of copying the search filter everywhere. Similarly this collection may be reused in policy rule specifications. In the future there may be scanner tasks that scan just the objects that belong to the collections, bulk actions for the collections and similar improvements.

Reusing the definition on many places is not just convenience. It is important for consistency of configuration. Nothing in the IDM world is really constant. E.g. the definition what is an employee may change in time. If object collection is used properly, then that definition needs to be updated in just one place. All the authorizations, views and dashboards should adapt automatically.

Views

View is a concept from the presentation layer. Simply speaking, a view specifies details of how a specific collection should be presented. Views are defined in admin GUI configuration data structures:

    <adminGuiConfiguration>
    	<objectCollectionViews>
    		<objectCollectionView>
    			<identifier>active-users</identifier>
                <display>
                    <label>Active users</label>
                </display>
                <column>
                    <!-- customization of table columns may be here -->
                </column>
    			<type>UserType</type>
    			<collection>
    				<collectionRef oid="9276c3a6-5790-11e9-a931-efe1b34f25f6" type="ObjectCollectionType"/> <!-- Active users object collection -->
    			</collection>
    		</objectCollectionView>
    	</objectCollectionViews>
    </adminGuiConfiguration>

Once the view is defined it will be used by the user interface in all the appropriate places. For midPoint 4.0 this pretty much means that the view will appear in the menu. But more functionality will be added in future midPoint releases.

Views drive user experience with details such as labels, icons, colors, columns and so on. Views specify presentation details, while collections define the "policies". Concerns are neatly separated. The motivation to have presentation properties separate from the collection is the fact, that the same collection is often displayed in a different ways to different people. Business people will be interested in just the basic important details about users. Security personnel will want to see status of the user and risk level. System administrators will be interested in the number of accounts and technical details. And so on. Placing definition of view in admin GUI configuration makes it easy to specify all those details in the appropriate roles. Therefore all the roles will have they own customized presentation of the data.

Views And Implicit Collections

Some midPoint objects can be considered collections of their own, especially archetypes. We want to make things simple and elegant whenever possible. Therefore archetypes can be used instead of a collection in the view definition:

    <adminGuiConfiguration>
    	<objectCollectionViews>
    		<objectCollectionView>
    			<identifier>all-employees</identifier>
    			<type>UserType</type>
    			<collection>
    				<collectionRef oid="7135e68c-ee53-11e8-8025-170b77da3fd6" type="ArchetypeType"/> <!-- Employee archetype -->
    			</collection>
    		</objectCollectionView>
    	</objectCollectionViews>
    </adminGuiConfiguration>

This is also the simplest way how to get archetypes into midPoint menu. The archetypes are not  published into the menu by default, because that is seldom what people really need. There may be archetypes that are just being prepared for use, or archetypes that are used so rarely that there is no point to polute very limited real estate of system menu with them. Archetypes are not added often, therefore it is not any great burden to create a view for them. Especially in this case when they can be used as an implicit collection.

Limitations

This feature is available in midPoint 4.0 and later. While most parts of this functionality are developed and ready to be used, some functionality is still missing. Therefore the use of collections and views has some quite significant limitations:

  • Cannot be used in authorizations yet.
  • Not supported on organizational structure GUI pages.
  • Cannot be used in the search bar.
  • Not supported for compliance.
  • Only partially supported for dashboards (and even that is experimental).
  • No support for policy rules yet.
  • Customization of view presentation properties is very limited yet. E.g. support for search bar configuration is not fully supported yet.
  • Support for collection domain is experimental.
  • .. and other limitations, there are too many of them to list.

While strictly speaking collections and views are not experimental functionality, the limitations are so severe that almost all support requests may turn out to be a feature/improvement requests instead of bug reports. Therefore midPoint Platform subscription is strongly recommended when using this functionality for production purposes.

See Also


  • No labels