Merge branch 'master' of https://github.com/Evolveum/docs

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

@@ -1128,7 +1128,15 @@ WARNING: This panels are available since midPoint 4.7
 
 | Outbound mappings basic information
 | `arw-construction-mapping`
-| Basic information about outbound mapping created in panel `Outbound mappings`
+| Basic information about outbound mapping created in panel `Outbound mappings`. Panel was removed from 4.8.
+
+| Main configuration of outbound mapping
+| `arw-construction-mapping-main`
+| Available from 4.8. Definition of the resource attribute from which the data wil be provisioned, and midPoint attribute which they will be provisioned to. Contains attributes name, source, target, ref (resource attribute), strength, expression and condition
+
+| Optional configuration of outbound mapping
+| `arw-construction-mapping-optional`
+| Available from 4.8. Definition of the resource attributes description, exclusive, authoritative, channel and except channel
 |===
 
 

docs/admin-gui/resource-wizard/index.adoc

@@ -2,22 +2,27 @@
 :page-toc: top
 :page-since: "4.6"
 
-Resource wizard was complete rewrite and redesign in midPoint version 4.6.
+Resource wizard was complete rewrite and redesign in midPoint version 4.6. Screenshots below corresponding with midPoint version 4.8.
 
 Some wizard panels are configurable, for more information see xref:/midpoint/reference/admin-gui/admin-gui-config/#wizard-panels[Wizard panels].
 
 New UI takes form of some panels with choice for specific parts of resource configuration. Specific part of configuration is represented by a wizard with steps.
 
 == Basic configuration
 
-.Resource catalog
-image::step-1-resource-catalog.png[Resource catalog,100%]
+[%autowidth, cols="1a,1a", frame=none, grid=none, role=center]
+|===
+| image::step-1-basic-conf.png[link=step-1-type-of-resource.png, 100%, title=Select type of resource]
+| image::step-1-resource-catalog.png[link=step-1-connector-conf-discovery.png,100%, title=Resource catalog]
+
+|===
 
 First panel of resource wizard allows user to choose connector or template for future resource.
-There are two possibilities:
+There are three possibilities:
 
-* From template - selecting from the resource template that needs to be preconfigured.
+* Inherit template - selecting from the resource template that needs to be preconfigured.
 * From scratch - selecting from the available connectors.
+* Copy From template - selecting from the resource template, but we only copy values from template to new resource.
 
 When we choose the source, we proceed to a couple of steps for the basic configuration of the resource and the connector.
 
@@ -46,7 +51,7 @@ image::choice-part-resource.png[Parts of resource configuration,100%]
 image::data-preview-resource.png[Data preview,100%]
 
 * Second tile leads to the object type configuration.
-* After clicking on last tile you will be redirect to resource details page.
+* After clicking on last tile you will be redirected to resource details page.
 
 == Object type configuration
 
@@ -63,11 +68,11 @@ Detail for configuration of object type:
 | image::step-2-object-type-basic-config.png[link=step-2-object-type-basic-config.png, 100%, title=Basic configuration of object type]
 | image::step-2-object-type-resource-data.png[link=step-2-object-type-resource-data.png, 100%,title=Resource data]
 
-| image::step-2-object-type-midpoint-data.png[link=step-2-object-type-resource-data.png, 100%, title=Midpoint data]
+| image::step-2-object-type-midpoint-data.png[link=step-2-object-type-midpoint-data.png, 100%, title=Midpoint data]
 |
 |===
 
-After we configure object type, we can see the tiles for previewing the data and configuring the containers of the selected object type.
+After we configure object type, we can see the button for previewing the data and titles for configuring of the containers for the selected object type.
 
 .Parts of object type configuration
 image::choice-part-object-type.png[Parts of object type configuration,100%]
@@ -81,16 +86,19 @@ image::data-preview-object-type.png[Data preview of object type,100%]
 Inbound mapping:
 [%autowidth, cols="a,a", frame=none, grid=none, role=center]
 |===
-| image::step-3-mappings-inbound.png[link=step-3-mappings-inbound.png, 100%, title=Table of inbound mappings]
-| image::step-3-mappings-inbound-detail.png[link=step-3-mappings-inbound-detail.png, 100%, title=Detail configuration of inbound mapping]
+2+| image::step-3-mappings-inbound.png[link=step-3-mappings-inbound.png, 100%, title=Table of inbound mappings]
+| image::step-3-mappings-inbound-detail-main.png[link=step-3-mappings-inbound-detail-main.png, 100%, title=Main detail configuration of inbound mapping]
+
+| image::step-3-mappings-inbound-detail-optional.png[link=step-3-mappings-inbound-detail-optional.png, 100%, title=Optional detail configuration of inbound mapping]
 |===
 
 {empty} +
 Outbound mapping:
 [%autowidth, cols="a,a", frame=none, grid=none, role=center]
 |===
-| image::step-3-mappings-outbound.png[link=step-3-mappings-outbound.png, 100%, title=Table of outbound mappings]
-| image::step-3-mappings-outbound-detail.png[link=step-3-mappings-outbound-detail.png, 100%, title=Detail configuration of outbound mapping]
+2+| image::step-3-mappings-outbound.png[link=step-3-mappings-outbound.png, 100%, title=Table of outbound mappings]
+| image::step-3-mappings-outbound-detail-main.png[link=step-3-mappings-outbound-detail-main.png, 100%, title=Main detail configuration of outbound mapping]
+| image::step-3-mappings-outbound-detail-optional.png[link=step-3-mappings-outbound-detail-optional.png, 100%, title=Optional detail configuration of inbound mapping]
 |===
 
 {empty} +
@@ -138,29 +146,39 @@ image::step-6-capabilities.png[Capabilities configuration,100%]
 
 === Activation
 
-[NOTE]
-====
-The object type activation configuration will be improved in the next version of midPoint.
-====
+From version 4.8, midPoint contains GUI support for activation mapping. We can add predefined mappings configuration or use typically mappings. For more information see xref:/midpoint/reference/resources/resource-configuration/schema-handling/activation/#wizard-panels[Resource Schema Handling: Activation].
+
+Details configuration for typically mapping are same as for attribute mappings, so contain main and optional details panel.
+
+==== Inbound
 
 [%autowidth, cols="a,a", frame=none, grid=none, role=center]
 |===
-| image::step-7-activation-admin-status.png[link=step-7-activation-admin-status.png, 100%, title=Configuration of administrative status]
-| image::step-7-activation-existence.png[link=step-7-activation-existence.png, 100%, title=Configuration of existence]
+| image::step-7-activation-inbounds.png[link=step-7-activation-inbounds.png, 100%, title=Empty inbound table for activation]
+| image::step-7-activation-inbound-add.png[link=step-7-activation-inbound-add.png, 100%, title=Popup for adding of new inbound activation mapping]
 
-| image::step-7-activation-valid-from.png[link=step-7-activation-valid-from.png, 100%, title=Configuration of valid from]
-| image::step-7-activation-valid-to.png[link=step-7-activation-valid-to.png, 100%, title=Configuration of valid to]
+2+| image::step-7-activation-inbound-full.png[link=step-7-activation-inbound-full.png, 100%, title=Activation table with inbound mapping for administrative status]
 
-| image::step-7-activation-lockout-status.png[link=step-7-activation-lockout-status.png, 100%, title=Configuration of lockout status]
-|
 |===
 
+==== Outbound
+
+[%autowidth, cols="a,a", frame=none, grid=none, role=center]
+|===
+| image::step-7-activation-outbounds.png[link=step-7-activation-outbounds.png, 100%, title=Empty outbound table for activation]
+| image::step-7-activation-outbound-add.png[link=step-7-activation-outbound-add.png, 100%, title=Popup for adding of new outbound activation mapping]
+
+2+| image::step-7-activation-outbound-full.png[link=step-7-activation-outbound-full.png, 100%, title=Activation table with outbound mapping for administrative status and predefined mappings for 'Disable instead of delete' and 'Delayed delete' configuration]
+|===
+
+Predefined mapping configurations contains only one configuration step.
+
+.Predefined details configuration for 'Delayed delete'
+image::step-7-predefined-details.png[Predefined details configuration for 'Delayed delete',100%]
+
 === Credentials
 
-[NOTE]
-====
-The object type credentials configuration will be improved in the next version of midPoint.
-====
+Configuration for credentials contains similar panels as for activation, but contains only one kind of mapping and doesn't contain any predefined mappings.
 
 .Configuration of credentials
 image::step-8-credentials.png[Configuration of credentials, 100%]
@@ -175,7 +193,7 @@ image::step-9-association-detail.png[Detail configuration for association, 100%]
 
 == Wizard for existing resource
 
-We can use wizard panels to edit existing resource. It's enough if we open the panel for displaying resource objects (accounts/entitlements/generics), select specific object type by intent, and then the buttons for opening the wizard for a specific part of the object type configuration are displayed.
+We can use wizard panels to edit existing resource. It's enough if we open the panel for displaying resource objects (accounts/entitlements/generics), select specific object type by intent, click on button 'Configure', and then the buttons for opening the wizard for a specific part of the object type configuration are displayed.
 
 .Resource detail
 image::resource-details.png[Resource detail, 100%]

docs/concepts/query/axiom-query-language/expressions.adoc

@@ -1,5 +1,5 @@
-= Using Axiom in expressions
-:page-nav-title: Axiom in expressions
+= Using expressions in Query Language
+:page-nav-title: Expressions
 :page-display-order: 200
 :page-since: "4.5"
 :page-toc: top
@@ -9,7 +9,7 @@
 Axiom query language provides special syntax support for most common
 expression types.
 
-NOTE: Expressions are not executed / supported for user entered queries in
+IMPORTANT: Expressions are not executed / supported for user entered queries in
 search box in midPoint GUI, since that would allow users to execute code and
 may pose additional security risks.
 

docs/concepts/query/axiom-query-language/query-language-in-groovy.adoc

@@ -1,5 +1,5 @@
-= Using Axiom in Groovy
-:page-nav-title: Axiom in Groovy
+= Using Query Langauge in Groovy
+:page-nav-title: Use in Groovy
 :page-display-order: 300
 
 You can use Axiom query language in Groovy expressions using `midpoint.queryFor` and `midpoint.preparedQueryFor` functions.

docs/deployment/ninja/index.adoc

@@ -10,6 +10,16 @@
 :page-alias: { "parent" : "/midpoint/tools/" }
 :page-toc: top
 
+[NOTE]
+====
+Since midPoint 4.8. Also in 4.4.6, 4.7.2 and later.
+
+* Commands and options names realigned:
+** All command and option names are kebab cased
+** File output is now `-o, --output`
+** `-O, --overwrite` for all commands
+====
+
 Ninja is a command line tool bundled with midPoint.
 Implemented features are based on "repo-ninja", but code was rewritten from the ground up.
 This tool comes in handy when one needs to export or import objects from/to midPoint.
@@ -68,28 +78,30 @@ If the bundled scripts are used, you can specify the path to the driver with `-j
 <midpoint>/bin/ninja.sh -j <JDBC_DRIVER_JAR> [general options] [command] [command options]
 ----
 
-=== REST connection
-
-[NOTE]
-====
-Not yet implemented.
-====
-
 // TODO: mention python CLI
 
 == Supported operations
 
 Ninja currently supports these operations:
 
-* import
-* export
-* verify (midPoint 3.9 or later)
-* keys
 * count
 * delete
-* importAudit (midPoint 4.4.1 or later)
-* exportAudit (midPoint 4.4.1 or later)
-* miningExport (midPoint 4.4.4 or later)
+* download-distribution (midPoint 4.4.6, 4.7.2, 4.8 or later)
+* export
+* export-audit (midPoint 4.4.1 or later)
+* export-mining (midPoint 4.4.4 or later)
+* help (midPoint 4.8 or later)
+* import
+* import-audit (midPoint 4.4.1 or later)
+* info
+* keys
+* pre-upgrade-check (midPoint 4.4.6, 4.7.2, 4.8 or later)
+* run-sql (midPoint 4.4.6, 4.7.2, 4.8 or later)
+* trace (midPoint 4.4.6, 4.7.2, 4.8 or later)
+* upgrade-distribution (midPoint 4.4.6, 4.7.2, 4.8 or later)
+* upgrade-installation (midPoint 4.4.6, 4.7.2, 4.8 or later)
+* upgrade-objects (midPoint 4.4.6, 4.7.2, 4.8 or later)
+* verify (midPoint 3.9 or later)
 
 === Import
 
@@ -215,13 +227,13 @@ ninja.sh export-mining -o role-mining-export.xml -fr '% name != "Superuser"'
 .Example: role mining export using `ORIGINAL` name mode, identifiers Application and Business role `prefixes/suffixes` and specific `archetypes oids`.
 [source,bash]
 ----
-ninja.sh export-mining -o role-mining-export.xml  -nm ORIGINAL -arp "APP_ROLE_, AR-" -ars "_Apr" -brp "BUS_ROLE_" -brs "_BR" --businessRoleArchetypeOid "e9c4654e-c146-4b5f-8336-2065c65060df" --applicationRoleArchetypeOid "52b8361a-c955-4132-97a4-77ff3820beeb"
+ninja.sh export-mining -o role-mining-export.xml  -nm ORIGINAL -arp "APP_ROLE_, AR-" -ars "_Apr" -brp "BUS_ROLE_" -brs "_BR" --business-role-archetype-oid "e9c4654e-c146-4b5f-8336-2065c65060df" --application-role-archetype-oid "52b8361a-c955-4132-97a4-77ff3820beeb"
 ----
 
 .Example: role mining export with `disable organization` structure export.
 [source,bash]
 ----
-ninja.sh export-mining -o role-mining-export.xml --disableOrg
+ninja.sh export-mining -o role-mining-export.xml --disable-org
 ----
 
 .Example: role mining import.

docs/resources/resource-configuration/schema-handling/activation.adoc

@@ -246,15 +246,20 @@ Set to `true` if the resource object is linked to an existing focal object.
 
 TODO
 
-== Predefined activation mapping
+== Predefined activation mappings
 
-NOTE: Available from 4.8.
+NOTE: Since 4.8.
 
-Predefined activation mapping are available from midpoint 4.8. We can use simple configuration for predefined mappings without long and complicated configuration for existence and administrative mappings.
+Predefined activation mappings are available since midpoint 4.8.
+We can use simple configuration for predefined mappings without long and complicated configuration for existence and administrative mappings.
 
-If an account is unassigned and there is no other existing assignment for an account midPoint will de-provisioning that account. Which means that the account will be deleted. This is the default behavior. But it can be changed by predefined mappings configuration.
+If an account is unassigned and there is no other existing assignment for an account, midPoint will de-provisioning that account.
+Which means that the account will be deleted.
+This is the default behavior.
+But it can be changed by predefined mappings configuration.
 
-All predefined mapping work only for one purpose. When we want mapping for administrative status, then we need add inbound or outbound mapping configuration.
+All predefined mapping work only for one purpose.
+When we want mapping for administrative status, then we need to add inbound or outbound mapping configuration.
 
 [source,xml]
 ----
@@ -281,7 +286,7 @@ All predefined mapping work only for one purpose. When we want mapping for admin
 Now we can use three predefined configurations.
 
 === Disable instead of delete
-This configuration change default behavior and account will be disabled instead of delete.
+This configuration changes default behavior and account will be disabled instead of being deleted.
 
 [source,xml]
 ----
@@ -300,9 +305,11 @@ This configuration change default behavior and account will be disabled instead
 ----
 
 === Delayed delete
-This configuration change default behavior and account will delete with delay and meanwhile account will be disabled.
+This configuration changes default behavior and account will be deleted with the delay.
+Until the account is deleted, it is disabled.
 
-We use activation/disableTimestamp from shadow object as reference attribute for time when was account disabled. As disable reason we use de-provision, so it mean that focus lost assignment for resource.
+We use `activation/disableTimestamp` from shadow object as reference attribute for time when the account was disabled.
+As a disable reason we use de-provision, which means that the assignment for resource was removed from the focus (e.g. user).
 
 [source,xml]
 ----
@@ -321,7 +328,7 @@ We use activation/disableTimestamp from shadow object as reference attribute for
 	</schemaHandling>
 </resource>
 ----
-We need set only one attribute _deleteAfter_, that define time after which the account will be deleted.
+We need to set only one attribute `deleteAfter`, that defines time after which the account will be deleted.
 
 === Pre provision
 This configuration will pre-provision a disabled account defined by time before focus’s activation/validFrom date.
@@ -344,7 +351,7 @@ This configuration will pre-provision a disabled account defined by time before
 </resource>
 ----
 
-We need set only one attribute _createBefore_, that define time determines how long before date, from activation/validFrom attribute, disabled account will be created.
+We need to set only one attribute `createBefore`, that defines time determines how long before date, from activation/validFrom attribute, disabled account will be created.
 
 
 == Examples

docs/synchronization/consistency/index.adoc

@@ -98,6 +98,22 @@ If a configuration is needed, it can be specified like this:
 </resource>
 ----
 
+[NOTE]
+====
+Since midPoint 4.8
+
+Shadow `metadata/createTimestamp` and `metadata/modifyTimestamp` is now being added for all shadow objects at all times.
+This changes behaviour for resources which have non-zero `deadShadowRetentionPeriod` in consistency defined.
+Previously shadows without such timestamps were removed right away if there were no pending operations, since midPoint couldn't compute _last activity timestamp_.
+Last shadow activity taken into account:
+
+* `pendingOperation/requestTimestamp`
+* `pendingOperation/lastAttemptTimestamp`
+* `pendingOperation/completionTimestamp`
+* `metadata/createTimestamp`
+* `metadata/modifyTimestamp`
+====
+
 Following table is summarizing configuration properties that are applicable to the consistency mechanism:
 
 [%autowidth]
@@ -127,27 +143,10 @@ If set to 0 then operation re-tries are disabled.
 
 | `deadShadowRetentionPeriod`
 | 7 days
-a| Duration for which the system will keep dead shadows.
+| Duration for which the system will keep dead shadows.
 After this interval has passed the dead shadows are deleted.
 Note: this may also be influenced by `pendingOperationGracePeriod`.
 Dead shadow may be kept for longer than the interval specified in `deadShadowRetentionPeriod` if that is needed to for evaluation of grace period.
-
-[NOTE]
-====
-Since midPoint 4.8
-
-Shadow `metadata/createTimestamp` and `metadata/modifyTimestamp` is now being added for all shadow objects at all times.
-This changes behaviour for resources which have non-zero `deadShadowRetentionPeriod` in consistency defined.
-Previously shadows without such timestamps were removed right away if there were no pending operations, since midPoint couldn't compute _last activity timestamp_.
-Last shadow activity taken into account:
-
-* `pendingOperation/requestTimestamp`
-* `pendingOperation/lastAttemptTimestamp`
-* `pendingOperation/completionTimestamp`
-* `metadata/createTimestamp`
-* `metadata/modifyTimestamp`
-====
-
 | `reshreshOnRead`
 | false
 | If set to true then midPoint will always refresh shadow when it is retrieved.