Admin GUI Configuration

Last modified 27 Oct 2021 14:02 +02:00

Admin GUI configuration is a specialized data structure that is present in system configuration object, in all the role-like objects (roles, orgs, services), in the user objects and partially also in archetype objects. The admin GUI configuration structure influences how to user interface is displayed. Despite its name it applies both to the self-service part and administration part of the user interface.

Basic Structure

The admin GUI configuration structure contains:

  • additionalMenuLink: Links that will be displayed as an additional items in the user interface menu. It can be used to point the user to other services in your deployment.

  • userDashboardLink: Application or shortcut links placed on end-user dashboard. Note: this configuration will be most likely placed inside the userDashborad in the future. However the compatibility will be maintained and this setting will also remain here.

  • objectCollectionViews: Specifies the set of pages that are used for displaying lists of objects such as Users, Roles, Orgs, …​ Influences a list of links in sidebar menu for particular object. E.g. defining objectCollection for Employees will create new link in sidebar menu under the Users, after clicking on the link, filtered list of the Employees is shown

  • objectDetails: Specifies the look and feel of the pages for displaying object details and editing of objects such as User, Role, Org,…​

  • userDashboard: (since midPoint 3.6) This setting controls which widgets are displayed on user dashboard (home screen).

  • defaultTimezone: Defines the timezone that will be used by the user interface to display date and time information.

  • preferredDataLanguage: (since midPoint 3.6) Defines the data language that will use used by the user interface to display content of objects (XML, JSON or YAML)

  • feedbackMessagesHook: Script hook configuration which can be used to modify operation results shown in GUI.

Since midPoint 4.4, the look and feel of GUI has been significantly changed. The aim was to provide better user experience and more configuration options. The old look is still available in midPoint for preview. It can be turned on in adminGuiConfiguration setting useNewDesign property to false. However, bugs and improvements will be fixed and implemented only for the new look and the old look will be completely removed in release 4.5. Old look is no more supported in 4.4. Please, migrate your configuration as soon as possible.

How It Works

The same admin GUI configuration structure may be specified in system configuration object, in all the role-like objects (roles, orgs, services) and also in the user objects (starting from midPoint v 4.1: in all AssignmentHolderType objects). Some parts of admin GUI configuration, such as objectDetails can be specified also in archetypes. When a specific user logs in, midPoint will process all of user’s roles to check for applicable authorizations. At the same time midPoint also compiles the effective admin GUI configuration. Following algorithm is used:

  • Admin GUI configuration in the system configuration object is applied first (if present).

  • Admin GUI configuration from all of the active roles, orgs and services is applied on top of that.

    • The simple single-valued configuration properties such as default timezone are overwritten. Therefore the role setting completely overrides the system global setting. If several roles specify conflicting values then the behavior is unpredictable. It is a responsibility of midPoint administrator to ensure the consistency.

    • Complex configuration structures such as objectDetails and dashboard definitions are merged. The system global definition is merged with the definition from all the roles.

  • Admin GUI config provided in the user object is applied last (if present).

The resulting merged configuration is used to display the user interface for a particular user. If the object to be displayed contains archetype definition (it has archetype assigned) then the admin GUI configuration from archetype is applied at the moment the object is going to be displayed.

This mechanism provides a very flexible customization of user interface. And the customization is inherently role-based. This mechanism can be used to display different object detail forms to different users. E.g. auditors will see the object history panel, but other user will not see it. Each role can have unique combination of the panels. And as we have a merging algorithm in place, if a user has many roles he will see all the panels specified by all the roles. Similar approach can be used to pre-define time zones and languages. If users are placed to organizational units according to their physical location then a time zone can be easily defined in that organizational unit admin GUI configuration.

The step that applies admin GUI configuration from the user object is meant to store and re-apply user’s own preferences about user interface look and feel. It is only partially implemented.

Widgets

The merged configurations for widgets have one quite specific characteristic. If no configuration is present at all, then a default configuration will be used (all default widgets). However, if only a single widget is defined then the default configuration is not applied. All widgets need to be explicitly defined. There is a limited number of widgets and they all are built to have their fixed place. This may change in the future and the dashboards may become more flexible. But they are not that flexible yet. Therefore all the widgets need to be explicitly defined in order to appear in a customized dashboard.

Object details

Object details configuration influences the look and feel of the pages for creating and editing object. MidPoint comes with default panels and default pre-defined configuration for each object available to edit and create in GUI. It is basic configuration which might be adjusted according to customer’s needs. Custom configuration defined by customer is merged with default pre-defined configuration according to the rules described in How it works.

Comparing the behavior before 4.4, there is a change in merging mechanism. Before 4.4 if any customization was made, it meant that the default configuration wasn’t taken into the account while displaying the corresponding page. Since 4.4 this behavior was changed, so any custom configuration is additional to one coming with midPoint by default. If the behavior or settings of the default panel needs to be changed, it is done with adjusting such configuration. To be able to adjust and override default configuration the identifier have to be specified and correctly used.

Every configurable feature containing identifier requires to have the identifier filled in. According to the identifier, configurations for same feature are merged. There are system defined default identifiers used for default panels which can be used to override behavior of default panels, e.g. visibility, virtual sections, etc.

Basis structure for object details configuration is:

  • type: Defines for which type is the configuration used.

  • summaryPanel: Specify the look and feel of the summary panel. Currently it is supported only partially.

  • saveMethod : Specifies the method how page save/preview buttons are shown and processed. Only few options are supported and might be changed in the future.

  • panel : Definition of individual panels which will be used on details page. According to the panel definition, also link in the detail menu to corresponding panel is generated. One panel can be nested to another. In such a case, link in the detail navigation menu will be show as a submenu under the link of the parent panel.

Panel configuration

Panel configuration contains information about two things:

  • How to generate the menu on the details page, such as label, icon, hierarchy.

  • Which panel will be shown after navigating to it using menu on the details page. Some panels are built-in and may be used as is, they might be customized directly in panel configuration, or the whole new custom panel can be implemented and used.

Following tables described basic configuration options for panels:

Property Mandatory Type Description

identifier

YES

String

Must be defined. Identifiers are used by merging algorithm. According to them, the configuration from different places (different roles, system configuration, archetypes) are merged together. Without identifier defined, it is not possible to merge the configurations correctly. Default panels have system defined identifiers stated in the table bellow.(TODO pointer to table)

description

NO

String

Free-form description (comment) intended for system administrator. Description will NOT be displayed as any part of the UI feature. The purpose is to explain the purpose or configuration details.

display

Yes

DisplayType

It is used to display the link in the menu. Currently, only label and icon/cssClass are used.

visibility

NO

UserInterfaceElementVisibilityType

Defines if the panel, and thus link in the menu on details page will be visible. Default value is automatic. If the panel should not be accessible, the value has to be set to hidden,

displayOrder

NO

Integer

It is used to specify order of the links in menu on details page. If there is a need to change the order of the link in the menu on details page, the displayOrder has to be set. E.g. on user details page, Projections are displayed as a second link in the menu. If they should be displayed later, ut has to be configured.

applicableForOperation

NO

OperationTypeType

Used to distinguish in which situation the panel will be visible. If nothing specified, configuration will be applicable for both add and modify operations. E.g. there might be panels applicable only when modifying user. In such a case, applicableForOperation must be set to modify.

container

NO

VirtualContainersSpeficiationType

Used to specify custom grouping of the attributes. According to it, virtual containers/sections are then generated in GUI. As an example, the user might need to reorganize attributes to some logic block such as personal info, basic info, additional info. Each of this section should have only attributes which belong to it, e.g. given name, family name, date of the birth are attributes corresponding to the personal info. Basic info section will contain attributes describing organizationalUnit, emailAddress or job position and additional info will contain attributes about user’s nickname and so on.

panelType

NO

String

Unique identifier pointing to the panel which will be shown. There are build-in panels in midPoint mostly mentioned in the table (TODO ref to table), but also custom panel can be implemented and used here.

listView

NO

GuiObjectListViewType

This is experimental and only partially supported. It can be used with table panels to specify object collection that will be used to select object in the view and to specify columns which will the showing table have.

panel

NO

ContainerPanelConfigurationType

Sub-panel definition. If defined, it will be placed as a submenu of parent panel configuration in the menu on details page.

default

NO

Boolean

If the panel is set to default = true, that after navigating to object details, this panel will be shown by default. Only one panel can be default. In midPoint, each object type has its default panel defined. If there is a wish to change it, make sure there is only one panel set to default = true at the end.

It is very important to be aware of difference between identifier and panelType. The attribute identifier points to the concrete instance of the panel idenfied by the identifier. This identifier is used to identify the same panel across different places where is might be configured and according to the identifier all related configurations are merged. The attribute panelType represents the type of the panel which will be instantiated and used to represent data. There might be different panel configurations with different identifier for the same panelType. In such a case, different menu links on details page will be generated and each will display instantiated panelType with the corresponding configuration in panel.

MidPoint itself comes with default panels with the identifiers specified. Those are stated in the tables bellow divided by the types for which they applies.

Panels applicable for all AssignmentHolderType object (except ResourceType):

Panel Identifier Description Default order Panel type

Basic

basic

Panel displaying default properties, such as name, fullName, …​

10

basic

Panels applicable for all FocusType objects:

Panel Identifier Description Default order

Projections

projections

Table with listed projections and possibility to show projection details.

20

Assignments

assignments

No panel at all, just to group different types of assignments under one details navigation

30

All assignments

allAssignments

Panel for all assignments. In details menu present as a submenu of assignments

10

Construction assignments

constructionAssignments

Panel for resource assignments. In details menu present as a submenu of assignments

50

Indirect assignments

indirectAssignments

Panel showing direct and also indirect assignemnts. In details menu present as a submenu of assignments

Data protection assignments

dataProtectionAssignments

Experimental, showing data protection assignments. In details menu present as a submenu of assignments

Org assignments

orgAssignments

Panel for org assignments. In details menu present as a submenu of assignments

30

Role assignments

roleAssignments

Panel for role assignments. In details menu present as a submenu of assignments

20

Service assignments

serviceAssignments

Panel for service assignments. In details menu present as a submenu of assignments

40

Password

password

Password panel, might be grouped under credentials in the future

50

Activation

activation

40

Cases

focusCases

Table of cases related to the object. E.g. waiting approval cases for user, etc.

70

History

history

History panel for object.

60

Triggers

focusTriggers

Table of triggers related to the object.

110

Panel applicable for all AbstractRoleType objects:

Panel Identifier Description Default order

Applicable policies

applicablePolicies

60

Inducements

inducements

No panel at all, just to group different types of inducements under one details navigation

70

Policy rule assignments

policyRuleAssignments

Policy ryle related assignemnts.In details menu present as a submenu of assignments.

60

Focus mappings assignments

focusMappingsAssignments

Focus mappings assignments. In details menu present as a submenu of assignments.

70

All inducements

allInducements

10

Construction inducements

constructionInducements

50

Focus mappings inducements

focusMappingsInducements

80

Induced entitlements

inducedEntitlements

70

Org inducements

orgInducements

30

Policy rule inducements

policyRuleInducements

60

Role inducements

roleInducements

20

Service inducements

serviceInducements

40

Panels applicable only for users:

Panel Identifier Description Default order

Consent assignments

gdprAssignments

Experimental, consent related assignments. In details menu present as a submenu of assignments.

Personas

personas

80

Delegations

userDelegations

90

Delegated to me

delegatedToMe

100

Panels applicable only for roles:

Panel Identifier Description Default order

Role members

roleMembers

80

Role governance

roleGovernance

90

Panels applicable only for services:

Panel Identifier Description Default order

Service members

serviceMembers

80

Service governance

serviceGovernance

90

Panels applicable onlu for archetypes:

Panel Identifier Description Default order

Archetype members

archetypeMembers

80

Archetype governance

archetypeGovernance

90

Archetype policy

archetypePolicy

140

Panels applicable only for organizations:

Panel Identifier Description Default order

Org members

orgMembers

60

Org governance

orgGovernance

70

Panels applicable only for cases:

Panel Identifier Description

Approval case

approvalCase

Case work item

caseWorkItems

Child cases

childCases

Manual case

manualCase

Operation request case

operationRequestCase

Panels applicable only for object collections:

Panel Identifier Description Default order

Base collection

baseCollection

40

Default view

defaultView

50

Domain

domain

60

Collection options

objectCollectionOptions

70

Panels applicable only for object templates:

Panel Identifier Description Default order

Object template items

objectTemplateItems

30

Iteration specification

iterationSpecification

20

Object template mappings

objectTemplateMappings

40

Panels applicable only for reports:

Panel Identifier Description Default order

Collection parameter

reportCollectionParameter

90

Collection subreport

reportCollectionSubreport

100

Collection view

reportCollectionView

80

Panels applicable only for resources:

Panel Identifier Description Default order

Resource accounts

resourceAccounts

30

Connector

resourceConnector

70

Resource details

resourceDetails

10

Resource entitlements

resourceEntitlement

40

Resource generics

resourceGenerics

50

Resource tasks

resourceTasks

20

Panels applicable only for tasks:

Panel Identifier Description Default order

Statistics

statistics

50

Activity

activity

15

Control flow

controlFlow

Show under Activity details menu

20

Distribution

distribution

Show under Activity details menu

20

Environmental performance

environmentalPerformance

Shown under Performance details menu

50

Task errors

taskErrors

50

Internal performance

internalPerformance

Shown under Performance details menu

50

Operations

operation

60

Performance

performance

No panel at all, used only to group different types od statistics

50

Reporting

reporting

Show under Activity details menu

50

Results

results

70

Schedule

schedule

15

Subtasks and worker threads

subtasks

50

Work

work

Specific work definition configured in archetype is displayed.

10

Examples

Show Only Some Default Forms

Suppose you want to show only "Basic", "Password", "Activation" and "Assignment" panels in the user details page. Then you can define a role like this:

<role>
     ...
     <adminGuiConfiguration>
        <objectDetails>
            <objectDetailsPage>
              <type>c:UserType</type>
              <panel>
                <identifier>projections</identifier>
                <visibility>hidden</visibility>
              </panel>
              <panel>
                <identifier>focusCases</identifier>
                <visibility>hidden</visibility>
              </panel>
              <panel>
                <identifier>history</identifier>
                <visibility>hidden</visibility>
              </panel>
              <panel>
                <identifier>focusTriggers</identifier>
                <visibility>hidden</visibility>
              </panel>
              <panel>
                <identifier>personas</identifier>
                <visibility>hidden</visibility>
              </panel>
              <panel>
                <identifier>userDelegations</identifier>
                <visibility>hidden</visibility>
              </panel>
              <panel>
                <identifier>delegatedToMe</identifier>
                <visibility>hidden</visibility>
              </panel>
            </objectDetailsPage>
        </objectDetails>
    </adminGuiConfiguration>
</role>

If user has this role then he will see only basic, password, activation and assignments menu links. The projections, history and other menu links will be hidden. Of course, if the user has more roles that gives access to more panels than he will see these tabs as well.

Customize assignments views

With new configuration there are several options how to cutomize assignemnts views. E.g.:

  1. Hiding "All assignments" panel.

    <adminGuiConfiguration>
        <objectDetails>
            <objectDetailsPage>
              <type>c:UserType</type>
              <panel>
                  <identifier>assignments</identifier>
                  <panel>
                      <identifier>allAssignments</identifier>
                      <visibility>hidden</visibility>
                  </panel>
                </panel>
            </objectDetailsPage>
        </objectDetails>
    </adminGuiConfiguration>
  2. Change display name and icon for "Service assignments".

    <adminGuiConfiguration>
      <objectDetails>
        <objectDetailsPage>
          <type>c:UserType</type>
          <panel>
              <identifier>assignments</identifier>
              <panel>
                  <identifier>serviceAssignments</identifier>
                  <display>
                    <label>Applications</label>
                    <icon>
                      <cssClass>fa fa-gamepad</cssClass>
                    </icon>
                  </display>
              </panel>
            </panel>
        </objectDetailsPage>
      </objectDetails>
    </adminGuiConfiguration>
  3. Define custom collection for role assignments with default role panel.

    <adminGuiConfiguration>
      <objectDetails>
        <objectDetailsPage>
          <type>c:UserType</type>
          <panel>
              <identifier>assignments</identifier>
              <panel>
                  <identifier>custom-role-assignments</identifier>
                  <display>
                      <label>My own role assignments</label>
                      <tooltip>Custom assignments table requests</tooltip>
                  </display>
                  <panelType>roleAssignments</panelType>
                  <listView>
                      <identifier>role-assignmnets-view</identifier>
                      <collection>
                          <collectionRef oid="e97b857f-3228-4df5-a920-67157b77d736" relation="org:default" type="c:ObjectCollectionType">
                              <!-- Custom collection definigion (mainly filtering) -->
                          </collectionRef>
                      </collection>
                  </listView>
                </panel>
            </panel>
        </objectDetailsPage>
      </objectDetails>
    </adminGuiConfiguration>
  4. Customize role assignment details by creating virtual sections.

    <adminGuiConfiguration>
      <objectDetails>
        <objectDetailsPage>
          <type>c:UserType</type>
          <panel>
              <identifier>assignments</identifier>
              <panel>
                  <identifier>roleAssignments</identifier>
                  <container>
                      <identifier>basicAssignmentAttributes</identifier>
                      <display>
                          <label>Description attributes</label>
                      </display>
                      <item>
                          <path>assignment/documentation</path>
                      </item>
                      <item>
                          <path>assignment/description</path>
                      </item>
                  </container>
                  <panelType>roleAssignments</panelType>
              </panel>
            </panel>
        </objectDetailsPage>
      </objectDetails>
    </adminGuiConfiguration>
  5. Customize assignment menu - show only role and org assignments on top level.

    <adminGuiConfiguration>
      <objectDetails>
        <objectDetailsPage>
          <type>c:UserType</type>
          <panel>
              <identifier>assignments</identifier>
              <visibility>hidden</visibility>
          </panel>
          <panel>
              <identifier>top-role-assignments</identifier>
              <display>
                <label>Roles</label>
                <icon>
                  <cssClass>fe fe-role</cssClass>
                </icon>
              </display>
              <panelType>roleAssignments</panelType>
          </panel>
          <panel>
              <identifier>top-org-assignments</identifier>
              <display>
                <label>Orgs</label>
                <icon>
                  <cssClass>fa fa-building</cssClass>
                </icon>
              </display>
              <panelType>orgAssignments</panelType>
          </panel>
        </objectDetailsPage>
      </objectDetails>
    </adminGuiConfiguration>

Virtual sections for different panel

Suppose you need to somehow re-arrange basic properties for object or you have a lot of extension attributes which need to be divided to different sections. Since midPoint 4.4 it is possible to use virtual sections for different panels. Bellow are some examples:

  1. Virtual sections for user basic panel.

    <adminGuiConfiguration>
      <objectDetails>
        <objectDetailsPage>
          <type>c:UserType</type>
          <panel>
              <identifier>basic</identifier>
              <container>
                  <identifier>basicAttributes</identifier>
                  <display>
                      <label>Basic attributes</label>
                  </display>
                  <item>
                      <path>familyName</path>
                  </item>
                  <item>
                      <path>givenName</path>
                  </item>
                  <item>
                      <path>fullName</path>
                  </item>
              </container>
              <container>
                  <identifier>contactAttributes</identifier>
                  <display>
                      <label>Contact attributes</label>
                  </display>
                  <item>
                      <path>emailAddress</path>
                  </item>
                  <item>
                      <path>telephoneNumber</path>
                  </item>
                  <item>
                      <path>employeeNumber</path>
                  </item>
              </container>
              <panelType>basic</panelType>
          </panel>
        </objectDetailsPage>
      </objectDetails>
    </adminGuiConfiguration>
  2. Custom panel with multi-value extension attribute

    <adminGuiConfiguration>
      <objectDetails>
        <objectDetailsPage>
          <type>c:UserType</type>
          <panel>
              <identifier>address-panel</identifier>
              <description>Custom panel for multivalue extension attribute address</description>
              <display>
                  <label>Address</label>
                  <icon>
                      <cssClass>fa fa-map-o</cssClass>
                  </icon>
              </display>
              <container>
                  <identifier>address</identifier>
                  <display>
                      <label>Address</label>
                  </display>
                  <path xmlns:ext="http://example.com/midpoint">c:extension/ext:address</path>
              </container>
              <panelType>formPanel</panelType>
          </panel>
        </objectDetailsPage>
      </objectDetails>
    </adminGuiConfiguration>
  3. Virtual section on role assignment details panel

    <adminGuiConfiguration>
      <objectDetails>
        <objectDetailsPage>
          <type>c:UserType</type>
          <panel>
              <identifier>assignments</identifier>
              <panel>
                  <identifier>roleAssignments</identifier>
                  <container>
                      <identifier>basicAssignmentAttributes</identifier>
                      <display>
                          <label>Description attributes</label>
                      </display>
                      <item>
                          <path>assignment/documentation</path>
                      </item>
                      <item>
                          <path>assignment/description</path>
                      </item>
                  </container>
                  <panelType>roleAssignments</panelType>
              </panel>
            </panel>
        </objectDetailsPage>
      </objectDetails>
    </adminGuiConfiguration>

Change ordering of the menu links in details panel.

<adminGuiConfiguration>
  <objectDetails>
    <objectDetailsPage>
      <type>c:UserType</type>
      <panel>
          <identifier>password</identifier>
          <displayOrder>11</displayOrder>
      </panel>
      <panel>
          <identifier>activation</identifier>
          <displayOrder>12</displayOrder>
      </panel>
    </objectDetailsPage>
  </objectDetails>
</adminGuiConfiguration>

Change default panel

Set another panel as basic panel to be shown as a default panel after opening user details page.

<adminGuiConfiguration>
  <objectDetails>
    <objectDetailsPage>
      <type>c:UserType</type>
      <panel>
          <identifier>password</identifier>
          <default>true</default>
      </panel>
      <panel>
          <identifier>basic</identifier>
          <default>false</default>
      </panel>
    </objectDetailsPage>
  </objectDetails>
</adminGuiConfiguration>

New Custom Form in a Role

TODO:

Hiding User Dashboard Widgets

Following example can be used to customize the look of the user dashboard (home screen).

<role>
     <name>Common User</name>
     ...
     <adminGuiConfiguration>
        <userDashboard>
            <widget>
                <identifier>http://midpoint.evolveum.com/xml/ns/public/gui/component-3/dashboard/widget#shortcuts</identifier>
                <visibility>automatic</visibility>
            </widget>
            <widget>
                <identifier>http://midpoint.evolveum.com/xml/ns/public/gui/component-3/dashboard/widget#myRequests</identifier>
                <visibility>automatic</visibility>
            </widget>
        </userDashboard>
    </adminGuiConfiguration>
</role>

The users that have this role will see only a very limited dashboard. They will see only the shortcuts and "my requests" box. There will be no search, no work items, not anything else.

Let’s have another role:

<role>
     <name>Approver</name>
     ...
     <adminGuiConfiguration>
        <userDashboard>
            <widget>
                <identifier>http://midpoint.evolveum.com/xml/ns/public/gui/component-3/dashboard/widget#myWorkItems</identifier>
                <visibility>automatic</visibility>
            </widget>
        </userDashboard>
    </adminGuiConfiguration>
</role>

This role defines just one widget. Therefore if a user has just this one role then he will see only the workitems widget. But if the user has both roles then the configuration will be merged and he will see all three widgets.

Possible visibility values are:

Value Description

automatic

The element will be visible if the authorisations of the current user allows to see (at least a part) of the content that the element displays.

visible

The element will be always visible.

vacant

The element will not be visible. Not even if the authorizations allow to see its content. But if any other role specifies the element as visible or automatic then it will be visible. This setting is easily overridden.

hidden

The element is never visible. Even if any other role specifies the element as visible then the element will still remain invisible. This setting cannot be overridden

Possible widget identifiers on the self dashboard page:

Identifier Widget

http://midpoint.evolveum.com/xml/ns/public/gui/component-3/dashboard/widget#search

Search widget

http://midpoint.evolveum.com/xml/ns/public/gui/component-3/dashboard/widget#myWorkItems

User work items data widget

http://midpoint.evolveum.com/xml/ns/public/gui/component-3/dashboard/widget#shortcuts

Dashboard links widget

http://midpoint.evolveum.com/xml/ns/public/gui/component-3/dashboard/widget#myRequests

User requests data widget

http://midpoint.evolveum.com/xml/ns/public/gui/component-3/dashboard/widget#myAssignments

User assignments data widget

http://midpoint.evolveum.com/xml/ns/public/gui/component-3/dashboard/widget#myAccounts

User accounts data widget

Custom columns configuration

To customize columns in the object list table, please, see use the following example

<!-- configuring custom columns for the RoleType objects table -->

<adminGuiConfiguration>
   <objectCollectionViews>
      <objectCollectionView>
         <type>c:RoleType</type>
         <column>
            <name>nameColumn</name>
            <path>name</path>
            <display>
               <label>Custom Name Column</label>
            </display>
         </column>
         <column>
            <name>displayNameColumn</name>
            <path>displayName</path>
            <display>
               <label>Custom Display Name Column</label>
            </display>
            <previousColumn>nameColumn</previousColumn>
         </column>
      </objectCollectionView>
   </objectCollectionViews>
</adminGuiConfiguration>
image2017 10 12 15 45 53

Column can be configured with the following attributes

Attribute Description

name

Column name (identifier). This element is not displayed to the user. It is used for identification of the column and referencing (e.g. previous column). The column definitions that have the same name in different layers (global, role, user) will be merged together.

description

Free-form description. It is not displayed to the user. It is supposed to be used by system administrators to explain the purpose of the configuration.

path

Path of the item (property) that this form display or that is taken as an primary input for the expression (planned for future). Even if expression is used to display the column value, we need some reference field that will be used to sort the table when sorting by this column is selected. We cannot sort by the output of the expression as that is not stored in the repo.

display

Specification of column display properties. This can be used to override the default column label or presentation style. display attribute can contain:

* label

* tooltip (not implemented yet)

* help (not implemented yet)

* cssStyle (not implemented yet)

* cssClass (not implemented yet)

visibility

Defines, whether this column will be visible or it will be hidden.
If not specified then it defaults to automatic visibility.

previousColumn

Name of the column that has to be displayed before this column. This value defines ordering in which the columns should be displayed. The first column has no value in this element. If there are multiple columns that specify the same preceding columns then the implementation may choose any ordering of such columns. However, the algorithm should be deterministic: the same ordring should be used every time (alphabeting ordering based on "path" or displayOrder from the schema are good candidates for deterministic ordering).

Custom actions for object lists

Starting from midpoint 3.9, there is a possibility to configure a custom action to be run from the object list table. This functionality is intended e.g. to start the specified task template for one object or for a group of the selected objects. To configure custom actions, please, use the following example

<adminGuiConfiguration>
    <objectCollectionViews>
            <objectCollectionView>
                <type>c:UserType</type>
                <action>
                    <name>Custom action</name>
                    <display>
                        <label>Run task template</label>
                    </display>
                    <taskTemplateRef xmlns:tns="http://midpoint.evolveum.com/xml/ns/public/common/common-3" oid="78a39955-743b-480f-86c0-9dbeafdbaba6" relation="org:default" type="tns:TaskType">
                        <!-- Change description task template -->
                    </taskTemplateRef>
                </action>
            </objectCollectionView>
        </objectCollectionViews>
</adminGuiConfiguration>

Xml for the task template object you can find by the following link. After custom action is configured in the admin gui configuration section, you can find action link among menu items on the appropriate type object list panel.image::custom_action_screen.png[]

Admin GUI Configuration and Authorizations

At the first sight the use of admin GUI configuration to define object forms and dashboard widgets may seem to be redundant. It may look that authorization mechanism provides the same services. But there are subtle differences.

  • The authorization mechanism is designed to answer one very specific question: can subject S do action A with object O? However, in user interface it is often desired to hide information that the user is entitled to see. E.g. maybe we do not want to display the default assignments tab (even though the user can read assignments) because we want to replace it with a simplified custom tab. Maybe we do not want to display some dashboard widgets to keep the dashboard simple. There may be many use cases when authorizations allow something but we still do not want to display it.

  • The authorizations are designed for very easy, efficient and unambiguous merging. The authorizations defined by many roles are all executed together. It is not good if one authorization allows something (e.g. read access to assignment container in the user object) but other authorization subtly influences the decision (e.g. do not display the default assignments tab). It is best if all authorizations in midPoint remain "positive" (allow authorizations). If we want to follow that principle then we would need special authorization for every little GUI element and typical end user will need to have them all. This is very likely to multiply the number of required authorization and it might easily make the system unmaintainable.

  • The authorizations are designed to be very efficient. They are evaluated for every operation (even several times in some cases). We have to do this as authorizations are our security barrier and there must be no way how to go around them. We do not really want to overuse authorizations as that may impact system performance. On the other hand, look and feel of user interface is not critical. We can afford to pre-process the settings and keep a cached copy of the results. We do not need to re-evaluate it every time.

However, the autorizations and the admin GUI configuration work together in several cases.

Firstly, shortcuts and menu links may explicitly specify an authorization (action) that is required for this shortcut/link to be displayed:

    <adminGuiConfiguration>
        <userDashboardLink>
            <targetUrl>http://example.com/swashbuckle</targetUrl>
            <label>Swashbuckle</label>
            <authorization>http://example.com/xml/ns/autz-1#swashbuckle</authorization>
        </userDashboardLink>
    </adminGuiConfiguration>

This link will be displayed only if the user has authorization that allow the action specified in the link.

Secondly, inclusion of default forms and the automatic visibility mode of widgets are authorization-sensitive. This means that form or widget will be displayed only if the user has access to the data that are displayed.

Feedback Messages Hook

Feedback messages hook configuration allows operation result preprocessing before it’s shown in GUI. Currently processed OperationResultType is set as "input" variable available in script. Script should return OperationResultType. If script returns null, then result is dropped and not shown on page. To see changes made in this part of configuration, user needs to do logout/login as they are cached in session.

<adminGuiConfiguration>
   <feedbackMessagesHook>
      <operationResultHook>
         <script>
            <code>
               import com.evolveum.midpoint.xml.ns._public.common.common_3.*;

               // input is OperationResultType
               input.setStatus(OperationResultStatusType.IN_PROGRESS);
               input.setMessage("Have a nice day");

               // if result has userFriendlyMessage filled in, then it takes precedence and it's show in UI as "main"
               // result message (not in result details), as you can see in this commented out example

               // LocalizableMessageType msg = new LocalizableMessageType();
               // msg.setKey("PageRepositoryQuery.resultException");
               // msg.setFallbackMessage("Some fallback if we can't translate key"); // otherwise result message will be used

               //
               // // params can be added for translation
               // LocalizableMessageArgumentType arg = new LocalizableMessageArgumentType();
               // arg.setValue("'Some cool value'");
               // msg.getArgument().add(arg);
               //
               // input.setUserFriendlyMessage(msg);

               return input;
            </code>
         </script>
      </operationResultHook>
   </feedbackMessagesHook>
</adminGuiConfiguration>

Security

Some parts of admin GUI configuration may contain expressions. Expressions are pieces of code that are executed inside midPoint server. As such expressions has to be inherently trusted. Therefore do not allow untrusted users to define sensitive parts of admin GUI configuration.