wiki: to xref: fixes, local docs using xref, minor formatting fixes

docs/admin-gui/admin-gui-config/admin-gui-configuration-4-0.adoc

@@ -9,7 +9,9 @@
 :page-upkeep-status: yellow
 :page-toc: top
 
-Admin GUI configuration is a specialized data structure that is present in wiki:System+Configuration+Object[system configuration object], in all the role-like objects (roles, orgs, services) and also in the xref:/midpoint/architecture/archive/data-model/midpoint-common-schema/usertype/[user objects]. The admin GUI configuration structure influences how to user interface is displayed.
+Admin GUI configuration is a specialized data structure that is present in xref:/midpoint/reference/concepts/system-configuration-object/[system configuration object],
+in all the role-like objects (roles, orgs, services) and also in the xref:/midpoint/architecture/archive/data-model/midpoint-common-schema/usertype/[user 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.
 
 
@@ -37,15 +39,14 @@ However the compatibility will be maintained and this setting will also remain h
 
 * *`feedbackMessagesHook`*: Script hook configuration which can be used to modify operation results shown in GUI.
 
-
 == How It Works
 
-The same admin GUI configuration structure may be specified in wiki:System+Configuration+Object[system configuration object], in all the role-like objects (roles, orgs, services) and also in the xref:/midpoint/architecture/archive/data-model/midpoint-common-schema/usertype/[user objects] (starting from midPoint v 4.1: in all AssignmentHolderType objects).
+The same admin GUI configuration structure may be specified in xref:/midpoint/reference/concepts/system-configuration-object/[system configuration object], in all the role-like objects (roles, orgs, services) and also in the xref:/midpoint/architecture/archive/data-model/midpoint-common-schema/usertype/[user objects] (starting from midPoint v 4.1: in all AssignmentHolderType objects).
 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 wiki:System+Configuration+Object[system configuration object] is applied first (if present).
+* Admin GUI configuration in the xref:/midpoint/reference/concepts/system-configuration-object/[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.
 
@@ -231,10 +232,8 @@ These are the URIs:
 
 |===
 
-
 == Examples
 
-
 === Show Only Some Default Forms
 
 Suppose you want to show only "Basic" and "Assignment" tabs in the user details page.
@@ -267,7 +266,6 @@ If user has this role the he will see only basic tab and assignments.
 The projections, history and other tabs will be hidden.
 Of course, if the user has more roles that gives access to more tabs that he will see these tabs as well.
 
-
 === New Custom Form in a Role
 
 The following example adds a completely custom user form (Java class).
@@ -296,7 +294,6 @@ There is no `includeDefaultForms` setting.
 Therefore the default forms will not be displayed in this case.
 User that have just this one role will see just this one custom tab.
 
-
 === Hiding User Dashboard Widgets
 
 Following example can be used to customize the look of the user dashboard (home screen).
@@ -406,7 +403,6 @@ Possible widget identifiers on the self dashboard page:
 
 |===
 
-
 === Custom columns configuration
 
 To customize columns in the object list table, please, see use the following example
@@ -487,7 +483,7 @@ If not specified then it defaults to automatic visibility.`
 | `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.
@@ -498,7 +494,6 @@ 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.
@@ -527,7 +522,6 @@ To configure custom actions, please, use the following example
 
 Xml for the task template object you can find by the link:https://github.com/Evolveum/midpoint-samples/blob/master/samples/tasks/templates/task-template-change-description.xml[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.
@@ -574,7 +568,6 @@ This link will be displayed only if the user has authorization that allow the ac
 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.
@@ -619,18 +612,16 @@ To see changes made in this part of configuration, user needs to do logout/login
 </adminGuiConfiguration>
 ----
 
-
 == Security
 
 Some parts of admin GUI configuration may contain xref:/midpoint/reference/expressions/expressions/[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.
 
-
 == See Also
 
-* wiki:System+Configuration+Object[System Configuration Object]
+* xref:/midpoint/reference/concepts/system-configuration-object/[System Configuration Object]
 
 * xref:/midpoint/reference/security/authorization/[Authorization]
 
-* wiki:Show+Only+Active+Users+HOWTO[Show Only Active Users HOWTO]
+* xref:/midpoint/reference/admin-gui/collections-views/show-only-active-users/[Show Only Active Users HOWTO]

docs/admin-gui/admin-gui-config/index.adoc

@@ -9,7 +9,7 @@
 :page-upkeep-status: yellow
 :page-toc: top
 
-Admin GUI configuration is a specialized data structure that is present in wiki:System+Configuration+Object[system configuration object], in all the role-like objects (roles, orgs, services), in the xref:/midpoint/architecture/archive/data-model/midpoint-common-schema/usertype/[user objects] and partially also in archetype objects. The admin GUI configuration structure influences how to user interface is displayed.
+Admin GUI configuration is a specialized data structure that is present in xref:/midpoint/reference/concepts/system-configuration-object/[system configuration object], in all the role-like objects (roles, orgs, services), in the xref:/midpoint/architecture/archive/data-model/midpoint-common-schema/usertype/[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.
 
 
@@ -41,12 +41,12 @@ Since midPoint 4.4, the look and feel of GUI has been significantly changed. The
 
 == How It Works
 
-The same admin GUI configuration structure may be specified in wiki:System+Configuration+Object[system configuration object], in all the role-like objects (roles, orgs, services) and also in the xref:/midpoint/architecture/archive/data-model/midpoint-common-schema/usertype/[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.
+The same admin GUI configuration structure may be specified in xref:/midpoint/reference/concepts/system-configuration-object/[system configuration object], in all the role-like objects (roles, orgs, services) and also in the xref:/midpoint/architecture/archive/data-model/midpoint-common-schema/usertype/[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 wiki:System+Configuration+Object[system configuration object] is applied first (if present).
+* Admin GUI configuration in the xref:/midpoint/reference/concepts/system-configuration-object/[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.
 
@@ -1354,8 +1354,8 @@ Therefore do not allow untrusted users to define sensitive parts of admin GUI co
 
 == See Also
 
-* wiki:System+Configuration+Object[System Configuration Object]
+* xref:/midpoint/reference/concepts/system-configuration-object/[System Configuration Object]
 
 * xref:/midpoint/reference/security/authorization/[Authorization]
 
-* wiki:Show+Only+Active+Users+HOWTO[Show Only Active Users HOWTO]
+* xref:/midpoint/reference/admin-gui/collections-views/show-only-active-users/[Show Only Active Users HOWTO]

docs/admin-gui/area-categories.adoc

@@ -13,7 +13,7 @@
 
 MidPoint user interface is getting more and more complex as midPoint functionality increases.
 MidPoint user interface is also getting more and more customizable. This means that it may be quite confusing if all parts of the user interface dealt with complete set of midPoint functionality.
-For example, there are several types of wiki:Relation[relations] used in midPoint.
+For example, there are several types of xref:/midpoint/reference/concepts/relation/[relations] used in midPoint.
 The relation mechanism is a generic reusable mechanism used by almost all parts of midPoint.
 But we do not want all parts of user interface to deal with all the relation types.
 For example pages and components that are focused on identity governance only care about governance-related relations such as `owner` or `approver`. Organizational structure pages do not really care about these, but `manager` relation is very important for them.

docs/admin-gui/collections-views/configuration/index.adoc

@@ -35,7 +35,7 @@ Something that midPoint policies can rely on.
 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 wiki:Admin+GUI+Configuration[admin GUI configuration].
+E.g. views can adjusted and overridden in xref:/midpoint/reference/admin-gui/admin-gui-config/[admin GUI configuration].
 
 Although collections and view have different purposes and they are based on different mechanisms, they are almost always used together.
 
@@ -113,7 +113,7 @@ All the authorizations, views and dashboards should adapt automatically.
 
 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 wiki:Admin+GUI+Configuration[admin GUI configuration] data structures:
+Views are defined in xref:/midpoint/reference/admin-gui/admin-gui-config/[admin GUI configuration] data structures:
 
 [source,xml]
 ----
@@ -148,7 +148,7 @@ Business people will be interested in just the basic important details about use
 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 wiki:Admin+GUI+Configuration[admin GUI configuration] makes it easy to specify all those details in the appropriate roles.
+Placing definition of view in xref:/midpoint/reference/admin-gui/admin-gui-config/[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.
 
 

docs/admin-gui/collections-views/index.adoc

@@ -37,7 +37,7 @@ Something that midPoint policies can rely on.
 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 wiki:Admin+GUI+Configuration[admin GUI configuration].
+E.g. views can adjusted and overridden in xref:/midpoint/reference/admin-gui/admin-gui-config/[admin GUI configuration].
 
 Although collections and view have different purposes and they are based on different mechanisms, they are almost always used together.
 

docs/admin-gui/role-catalog/configuration.adoc

@@ -11,7 +11,7 @@
 :page-toc: top
 
 
-For an introduction to the role catalog concept please see wiki:Role+Catalog[Role Catalog] page.
+For an introduction to the role catalog concept please see xref:/midpoint/reference/admin-gui/role-catalog/[Role Catalog] page.
 
 
 == Role Catalog Implementation
@@ -23,10 +23,9 @@ Remember: MidPoint can have any number of organizational structures and the role
 There may even be several role catalogs at the same time as any midPoint object can be assigned to any number of orgs.
 However, the current limitation is that only one role catalog will be presented to end users.
 
-
 == Role Catalog Root
 
-The root of this role catalog needs to be configured in the wiki:System+Configuration+Object[system configuration object] like this:
+The root of this role catalog needs to be configured in the xref:/midpoint/reference/concepts/system-configuration-object/[system configuration object] like this:
 
 [source,xml]
 ----
@@ -41,13 +40,12 @@ The root of this role catalog needs to be configured in the wiki:System+Configur
 
 The roleCatalogRef reference above points to the xref:/midpoint/architecture/archive/data-model/midpoint-common-schema/orgtype/[org] which is the root of the role catalog.
 
-
 == See Also
 
-* wiki:Role+Catalog[Role Catalog]
+* xref:/midpoint/reference/admin-gui/role-catalog/[Role Catalog]
 
-* wiki:Role+Request+and+Shopping+Cart+Configuration[Role Request and Shopping Cart Configuration]
+* xref:/midpoint/reference/admin-gui/role-request/configuration/[Role Request and Shopping Cart Configuration]
 
 * xref:/midpoint/reference/roles-policies/rbac/[Advanced Hybrid RBAC]
 
-* xref:/midpoint/reference/org/organizational-structure/[Organizational Structure]
+* xref:/midpoint/reference/org/organizational-structure/[Organizational Structure]

docs/admin-gui/role-catalog/index.adoc

@@ -21,10 +21,10 @@ The role catalog has two purposes and therefore it is also presented in two slig
 
 == Role Catalog for End Users
 
-The first purpose of role catalog is to make wiki:Role+Request+and+Shopping+Cart[role requests]  easy for *end users*. The role catalog is used to present the roles in a similar way as an e-shop presents the products.
+The first purpose of role catalog is to make xref:/midpoint/reference/admin-gui/role-request/[role requests]  easy for *end users*. The role catalog is used to present the roles in a similar way as an e-shop presents the products.
 The roles are sorted into categories and sub-categories.
 The user may browse the role catalog and select the roles.
-Then the user can put the roles in a wiki:Role+Request+and+Shopping+Cart["shopping cart"] and "buy" them.
+Then the user can put the roles in a xref:/midpoint/reference/admin-gui/role-request/["shopping cart"] and "buy" them.
 This catalog and e-shop paradigm is quite natural for most end users and it requires little to no training.
 
 image::role-request.png[]
@@ -45,7 +45,7 @@ image::role-catalog.png[]
 
 == Role Catalog Implementation and Configuration
 
-See wiki:Role+Catalog+Configuration[Role Catalog Configuration] page for description of role catalog implemenation and configuration details.
+See xref:/midpoint/reference/admin-gui/role-catalog/configuration/[Role Catalog Configuration] page for description of role catalog implemenation and configuration details.
 
 
 == See Also
@@ -54,6 +54,6 @@ See wiki:Role+Catalog+Configuration[Role Catalog Configuration] page for descrip
 
 * xref:/midpoint/reference/org/organizational-structure/[Organizational Structure]
 
-* wiki:Role+Catalog+Configuration[Role Catalog Configuration]
+* xref:/midpoint/reference/admin-gui/role-catalog/configuration/[Role Catalog Configuration]
 
-* wiki:Role+Request+and+Shopping+Cart[Role Request and Shopping Cart]
+* xref:/midpoint/reference/admin-gui/role-request/[Role Request and Shopping Cart]

docs/admin-gui/role-request/configuration.adoc

@@ -12,23 +12,21 @@
 
 == Role Catalog Configuration
 
-The prerequisite for a good user experience is usually proper configuration of wiki:Role+Catalog+Configuration[role catalog] and xref:/midpoint/reference/security/authorization/[authorizations]. The end-user role selection page will display only those roles that the currently-logged-in user can assign to himself.
+The prerequisite for a good user experience is usually proper configuration of xref:/midpoint/reference/admin-gui/role-catalog/configuration/[role catalog] and xref:/midpoint/reference/security/authorization/[authorizations]. The end-user role selection page will display only those roles that the currently-logged-in user can assign to himself.
 Therefore especially the proper use of `assign` authorization is crucial for proper functioning of this page.
 
-
 == Role Catalog Collections
 
 ++++
 {% include since.html since="3.6" %}
 ++++
 
-
 The role catalog has several _views_ or _collections_ that control the way what the end-user role catalog page displays the role catalog content.
 The specific view can be selected in the role request page.
 By default all the available views are displayed.
 But this may be too confusing for deployments that do not use all the midPoint capabilities.
 Therefore there is a way how to configure only a subset of the views.
-This can be controlled in the wiki:System+Configuration+Object[system configuration object] like this:
+This can be controlled in the xref:/midpoint/reference/concepts/system-configuration-object/[system configuration object] like this:
 
 [source,xml]
 ----
@@ -87,11 +85,10 @@ The object collections feature is a planned feature that will enable grouping ob
 This features development can be put forward by means of link:https://evolveum.com/services/professional-support/?target=platform-subscription[Platform subscription]. (bug:MID-3517[]). If you are interested in becoming a subscriber, please contact Evolveum.
 ====
 
-
 == Assignment Constraints
 
 Assignment constraints are often used to constraint role assignment multiplicity, e.g. whether it is possible to request the same role several times.
-Default assignment constraints are specified in wiki:System+Configuration+Object[system configuration object]. These constraints are applied globally to the entire system.
+Default assignment constraints are specified in xref:/midpoint/reference/concepts/system-configuration-object/[system configuration object]. These constraints are applied globally to the entire system.
 The constraint is composed from two boolean flags:
 
 * `*allowSameTarget*`: Constraint all assignments that have the same target.
@@ -118,9 +115,8 @@ The constraints can be used to enforce single-assignment role policy like this:
 </systemConfiguration>
 ----
 
-
 == See Also
 
-* wiki:Role+Catalog+Configuration[Role Catalog Configuration]
+* xref:/midpoint/reference/admin-gui/role-catalog/configuration/[Role Catalog Configuration]
 
-* wiki:Role+Request+and+Shopping+Cart[Role Request and Shopping Cart]
+* xref:/midpoint/reference/admin-gui/role-request/[Role Request and Shopping Cart]