[midPoint] Blog: Collections And Views

[Radovan Semancik]

Dear MidPoint community,

There are many new features in midPoint 4.0, code-named “Gutenberg” 
<https://evolveum.com/midpoint-4-0-gutenberg/>. Archetype functionality 
is one of the big new things. Archetypes allow to divide objects to a 
very fine types with customized look and behavior. However, there is 
almost infinite ways how to sort and present objects. Archetypes would 
not be enough on their own. Therefore there is a companion feature that 
is focused on customized grouping and presentation of objects: 
collections and view.

Archetypes, introduced in previous blog posts 
<https://evolveum.com/archetypes-in-gutenberg/>, allow to define objects 
such as employees, business roles and projects. But there are more ways 
how we would like to present the data. We would like to see /active 
employees/ /high-risk business roles/ and /active projects/. And there 
there are lists that go across archetype boundaries such as /all 
disabled users/ and /archived roles/. It is quite obvious that we need a 
great deal of flexibility here. That’s where collections and views 
<https://wiki.evolveum.com/display/midPoint/Object+Collections+and+Views> 
fit in.

Collection allows to group objects by any reasonable criteria. Simply 
speaking a collections is just a named search filter. E.g. an /active 
employees/ collection groups all the users that have /employee/ 
archetype and effective status is /enabled/. But collections are more 
powerful than that. First of all, collections may be based on other 
collection. Let’s suppose that there is /all employees/ collection. Then 
the /active employees/ can simply state, that it contains the objects 
from /all employees/, but only those that have active effective status. 
This is a way how to build a flexible and maintainable structure of 
collections.

Collections are first-class objects in midPoint. Therefore a collection 
can be defined by simply putting the search filter in midPoint object 
and importing it. Those are /explicit/ collections such as the /active 
employees/ collection above. But there are many objects in midPoint that 
naturally behave like a collection. Archetype is a good example of such 
objects. It would be quite redundant to explicitly define /all 
employees/ collection when there is already /employee/ archetype. We do 
not look nicely on redundancy in midPoint. Therefore archetypes act as 
/implicit/ collections. The /active employees/ collection can be created 
by simply referring to /employee/ archetype and specifying an effective 
status filter.

Primary purpose of collections in midPoint 4.0 are to be used for 
presentation purposes. But collection is an essential concept that goes 
quite deep into midPoint core engine. Later midPoint versions will 
introduce ability to use collections in other midPoint mechanisms such 
as authorizations.

Collections define object grouping. But that is not enough to create a 
nice and user-friendly presentation. Firstly, we do not want to display 
all the collections to all the users as there could be a huge number of 
collections in the system. Displaying all of them would make navigation 
in the user interface quite difficult. We usually want to display 
different collections to different user roles. Maybe we want to use 
collections in various context that are suitable for the job at hand. 
Therefore we may want to display one set of collections in the menu, a 
different set of collections in the role selection and so on. And that 
is where the concept of /view/ comes in.

A /view/ specifies how a collection should be presented. View specifies 
whether collection should be displayed in the menu, role selection, 
search bars and so on. View is not a stand-alone midPoint object. It is 
rather part of admin GUI configuration 
<https://wiki.evolveum.com/display/midPoint/Admin+GUI+Configuration> 
data structure. It is a user interface “feature”. Therefore view can be 
bound to roles. Various job roles can see a different set of views 
customized to make their job easier. View configuration is also designed 
to be merged and overridden, which is meant to allow seamless 
combination of roles in a role hierarchy. Overall, collections and views 
are simple-to-use mechanisms that can significantly improve midPoint 
user experience and make the use of midPoint much more efficient.

We have been experimenting with collections and views for several years. 
It was always an experimental functionality. But it is Gutenberg where 
the collections and view really come of an age. Collections and views 
are now officially part of midPoint functionality. Yet, there is still a 
room for improvement 
<https://wiki.evolveum.com/display/midPoint/Object+Collections+and+Views+Improvements>. 
E.g. the use of views are currently limited to main menu, collections 
cannot be used in authorizations yet and so on. If you would like to 
improve this functionality, please consider to purchase midPoint 
platform subscription <https://evolveum.com/services/>.

(Reposted from Evolveum blog <https://evolveum.com/collections-and-views/>)

-- 

Radovan Semancik
Software Architect
evolveum.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20191205/32112bfa/attachment.htm>