<html>

  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <p> Dear MidPoint community,</p>

    There are many new features in <a

      href="https://evolveum.com/midpoint-4-0-gutenberg/">midPoint 4.0,

      code-named “Gutenberg”</a>. 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.

    <p>Archetypes, introduced in <a

        href="https://evolveum.com/archetypes-in-gutenberg/">previous

        blog posts</a>, 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 <i>active

        employees</i> <i>high-risk business roles</i> and <i>active

        projects</i>. And there there are lists that go across archetype

      boundaries such as <i>all disabled users</i> and <i>archived

        roles</i>. It is quite obvious that we need a great deal of

      flexibility here. That’s where <a

href="https://wiki.evolveum.com/display/midPoint/Object+Collections+and+Views">collections

        and views</a> fit in.</p>

Collection allows to group objects by any reasonable criteria.

      Simply speaking a collections is just a named search filter. E.g.

      an <i>active employees</i> 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 <i>all employees</i> collection. Then the <i>active

        employees</i> can simply state, that it contains the objects

      from <i>all employees</i>, but only those that have active

      effective status. This is a way how to build a flexible and

      maintainable structure of collections.</p>

    <p>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 <i>explicit</i>

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 <i>all employees</i>

      collection when there is already <i>employee</i> archetype. We do

      not look nicely on redundancy in midPoint. Therefore archetypes

      act as <i>implicit</i> collections. The <i>active employees</i>

      collection can be created by simply referring to <i>employee</i>

      archetype and specifying an effective status filter.</p>

    <p>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.</p>

    <p>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 <i>view</i> comes in.</p>

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 <a

href="https://wiki.evolveum.com/display/midPoint/Admin+GUI+Configuration">admin

        GUI configuration</a> 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.</p>

    <p>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 <a

href="https://wiki.evolveum.com/display/midPoint/Object+Collections+and+Views+Improvements">still

        a room for improvement</a>. 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 <a

        href="https://evolveum.com/services/">midPoint platform

        subscription</a>.</p>

    (Reposted from <a moz-do-not-send="true"

      href="https://evolveum.com/collections-and-views/">Evolveum blog</a>)<br>

    <br>

    --

    <pre class="moz-signature" cols="72">Radovan Semancik

Software Architect

evolveum.com

</pre>

  </body>

</html>