format and typo fixes

docs/cases/workflow-3/workflow-notifications.adoc

@@ -26,11 +26,8 @@ Workflow module provides the following notifications:
 
 | Work item creation
 .3+| The work item actor (i.e. assignee) (as of 3.4).
-All assignees (as of 3.6). +
- +
-
-
 
+All assignees (as of 3.6).
 | Work item escalation, delegation, or other event
 
 
@@ -65,14 +62,18 @@ The variable might be null if the object does not exist yet.
 
 | (all)
 | changeType
-| ADD = process instance start or work item creationDELETE = process instance end or work item completion
+| ADD = process instance start or work item creation
+
+DELETE = process instance end or work item completion
 |
 
 
 | (all)
 | status
-| SUCCESS = result is 'approved' (you can use also isApproved() method to determine this) +
-FAILURE = result is 'rejected' (also isRejected() method) +
+| SUCCESS = result is 'approved' (you can use also isApproved() method to determine this)
+
+FAILURE = result is 'rejected' (also isRejected() method)
+
 IN_PROGRESS = result is not yet known (you can also use isResultKnown() to determine this)
 |
 

docs/concepts/clockwork/hooks.adoc

@@ -8,7 +8,7 @@
 :page-wiki-metadata-modify-date: 2016-02-20T15:39:58.533+01:00
 
 Hooks are midPoint mechanism for injecting a code to or intercepting of normal midPoint flows.
-E.g. a hook can be used to inset custom notification after an operation is complete, modify the operation request before it is even processed, redirect processing to a workflow or trouble-ticket system or do any other kind of advanced customization magic.
+E.g. a hook can be used to insert custom notification after an operation is complete, modify the operation request before it is even processed, redirect processing to a workflow or trouble-ticket system or do any other kind of advanced customization magic.
 Hooks are invoked by xref:/midpoint/reference/concepts/clockwork/clockwork-and-projector/[Clockwork] component at appropriate stages of midPoint computation.
 
 Hooks are typically pieces of Java code that has to be compiled and assembled into midPoint.
@@ -19,4 +19,4 @@ However there is also a lightweight way to xref:/midpoint/reference/concepts/clo
 
 * xref:/midpoint/reference/concepts/clockwork/scripting-hooks/[Scripting Hooks]
 
-* xref:/midpoint/reference/concepts/clockwork/clockwork-and-projector/[Clockwork and Projector]
+* xref:/midpoint/reference/concepts/clockwork/clockwork-and-projector/[Clockwork and Projector]

docs/concepts/clockwork/scripting-hooks.adoc

@@ -9,7 +9,7 @@
 == Introduction
 
 xref:hooks.adoc[Hooks] are midPoint mechanism for injecting a code to or intercepting of normal midPoint flows.
-E.g. a hook can be used to inset custom notification after an operation is complete, modify the operation request before it is even processed, redirect processing to a workflow or trouble-ticket system or do any other kind of advanced customization magic.
+E.g. a hook can be used to insert custom notification after an operation is complete, modify the operation request before it is even processed, redirect processing to a workflow or trouble-ticket system or do any other kind of advanced customization magic.
 
 Hooks are typically pieces of Java code that has to be compiled and assembled into midPoint.
 However there is also a lightweight way to create a hook using a scripting code.

docs/interfaces/invoking-midpoint-services/index.adoc

@@ -14,8 +14,10 @@
 == Introduction
 
 MidPoint is a complete identity provisioning system that can be used to build a comprehensive end-to-end provisioning solution.
-But midPoint also exposes all its functionality using xref:/midpoint/reference/interfaces/[midPoint interfaces]. Therefore midPoint can also be used as a back-end provisioning engine, as embedded provisioning solution, as a non-interactive enterprise service (SOA component) and also in a variety of other scenarios.
-The key to midPoint flexibility are the xref:/midpoint/reference/interfaces/[interfaces]. By invoking midPoint services that are exposed in the interfaces the entire midPoint becomes a programmable service.
+But midPoint also exposes all its functionality using xref:/midpoint/reference/interfaces/[midPoint interfaces].
+Therefore midPoint can also be used as a back-end provisioning engine, as embedded provisioning solution, as a non-interactive enterprise service (SOA component) and also in a variety of other scenarios.
+The key to midPoint flexibility are the xref:/midpoint/reference/interfaces/[interfaces].
+By invoking midPoint services that are exposed in the interfaces the entire midPoint becomes a programmable service.
 
 image::midPoint-Interfaces.png[]
 
@@ -33,7 +35,8 @@ This gives good flexibility to the midPoint deployment and to the architecture o
 However there are typical limitations that are inherent to all remote interfaces such as serialization, communication overhead, difficult to use callbacks, etc.
 Therefore remote interfaces are less convenient to use.
 
-Both local and remote interfaces expose roughly the same functionality and the invocation end up in the same midPoint code (in xref:/midpoint/architecture/archive/subsystems/model/[IDM Model Subsystem]). Form this point of view these interfaces are roughly equivalent.
+Both local and remote interfaces expose roughly the same functionality and the invocation end up in the same midPoint code (in xref:/midpoint/architecture/archive/subsystems/model/[IDM Model Subsystem]).
+Form this point of view these interfaces are roughly equivalent.
 However the remote interfaces are typically adapted to the typical way how individual technology is used.
 E.g. REST interface is designed in a very clean RESTful fashion (very web-like "resource-oriented" architecture).
 Therefore the operations are segregated for each object individually.
@@ -46,14 +49,15 @@ It is easy to do basic operation in all the interfaces.
 Advanced operations may be more tricky do to but they are still mostly practically possible to do.
 
 All the versions of midPoint xref:/midpoint/reference/interfaces/model-java/[IDM Model Interface] are object-oriented.
-It means that they work with xref:/midpoint/reference/schema/data-model-essentials/[midPoint objects]. The interfaces are creating, reading (and searching), updating and deleting the objects.
+It means that they work with xref:/midpoint/reference/schema/data-model-essentials/[midPoint objects].
+The interfaces are creating, reading (and searching), updating and deleting the objects.
 This is known as link:http://en.wikipedia.org/wiki/CRUD[CRUD] semantics.
 E.g. resource configuration is changed by modifying corresponding xref:/midpoint/architecture/archive/data-model/midpoint-common-schema/resourcetype/[ResourceType] object, user is created by creating a new xref:/midpoint/architecture/archive/data-model/midpoint-common-schema/usertype/[UserType] object and so on.
 All the interfaces are also using the xref:/midpoint/reference/concepts/relativity/[relative change model] by using xref:/midpoint/devel/prism/concepts/deltas/[deltas] to define change to individual midPoint objects.
 
 Following table provides overview of interface operation groups and their availability in individual interfaces.
 
-
+// TODO web service is irrelevant for MidPoint 4.2 and later
 
 [%autowidth]
 |===
@@ -134,7 +138,6 @@ discoverConnectors
 
 |===
 
-
 == Java Interface
 
 Main article: xref:/midpoint/reference/interfaces/model-java/[IDM Model Interface]
@@ -149,7 +152,7 @@ The objects and deltas are expected to be provided in the form of xref:/midpoint
 This interface is ideal for use from code that is local to the midPoint instance (runs in the same JVM), e.g. parts of midPoint such as GUI, plug-ins and hook implementations, custom compile-time add-ons and customization or scripts running midPoint mappings and expressions.
 
 The unusual approach of this interface is to use a single method (`executeChanges`) for executing changes of all the types (additions, modifications, deletions).
-This approach allows to group related changes together therefore they can be recomputed together and provide more meaningful results.
+This approach allows grouping related changes together therefore they can be recomputed together and provide more meaningful results.
 Java API with sophisticated delta-based data structures allows this form of approach.
 This approach is very useful for sophisticated interface clients (such as midPoint GUI), e.g. there is ability to detect how individual deltas influence each other, detect policy conflicts before even a single delta was executed, provide fine-grained execution results for each individual delta and so on.
 
@@ -159,7 +162,6 @@ There are some information and examples how to use this interface:
 
 * *TODO*: example usage from scripts
 
-
 == Web Service Interface
 
 Main article: xref:/midpoint/reference/legacy/soap/[IDM Model Web Service Interface]
@@ -172,7 +174,8 @@ The objects and deltas are expected to be presented as XML objects.
 Full WSDL and XSD definitions are available.
 The interface was developed in a contract-first fashion therefore the WSDL and XSD are authoritative definitions.
 
-There is also a xref:/midpoint/reference/legacy/soap-client/[Model Web Service Client] library based on Java and pure JAX-WS and JAX-B. It is designed to be used outside midPoint, e.g. in applications that need to invoke midPoint services.
+There is also a xref:/midpoint/reference/legacy/soap-client/[Model Web Service Client] library based on Java and pure JAX-WS and JAX-B.
+It is designed to be used outside midPoint, e.g. in applications that need to invoke midPoint services.
 
 There are few examples of the interface use:
 
@@ -188,7 +191,6 @@ Currently we have no plans to expand this interface in any significant manner.
 However we will still maintain it and it will remain in this form as part of midPoint for any foreseeable future.
 We do not rule out even the extension and update of this interface in case there is a user demand.
 
-
 == REST Interface
 
 Main article: xref:/midpoint/reference/interfaces/rest/[REST API]
@@ -202,9 +204,6 @@ The objects are presented in XML and (in later versions) JSON.
 Formal interface definition is not available as there is no practical way to do this (RESTful interfaces are said to be self-describing).
 However informal documentation is (will be) available and there is also a xref:/midpoint/reference/schema/[schema] that describes the structure of individual objects.
 
-REST interface is *WORK IN PROGRESS*. It will be released in midPoint version 3.0.
-
-
 == See Also
 
 * xref:/midpoint/reference/interfaces/[Interfaces]
@@ -215,4 +214,4 @@ REST interface is *WORK IN PROGRESS*. It will be released in midPoint version 3.
 
 * xref:/midpoint/reference/legacy/soap/[IDM Model Web Service Interface]
 
-* xref:/midpoint/reference/interfaces/rest/[REST API]
+* xref:/midpoint/reference/interfaces/rest/[REST API]

docs/misc/bulk/actions/index.adoc

@@ -70,10 +70,10 @@ one can simply write
 
 Moreover, we can rely on all the auto-completion and schema-checking features of modern IDEs, because the definition of `s:execute` element and its parameters is fully described in relevant XML schema document.
 
-
 == Actions
 
-The actions themselves are the same as they were before midPoint 4.2. In some cases, the action names were clarified.
+The actions themselves are the same as they were before midPoint 4.2.
+In some cases, the action names were clarified.
 In other ones, parameters were reorganized into more logical way.
 But the backward compatibility is fully ensured: the old way of specifying actions is still possible; although it will be probably deprecated (and removed) in the future.
 
@@ -84,67 +84,51 @@ But the backward compatibility is fully ensured: the old way of specifying actio
 | add
 | Adds object(s) to the repository.
 
-
 | modify
 | Modifies object(s).
 
-
 | delete
 | Deletes object(s).
 
-
 | enable, disable
 | Enables or disables object(s).
 
-
 | assign
 | Assigns an abstract role or a resource to object(s).
 
-
 | unassign
 | Removes assignment(s) from object(s).
 
-
 | xref:/midpoint/reference/misc/bulk/actions/recompute/[recompute]
 | Recomputes object(s) (or schedules the recomputation to the future).
 
-
 | execute
 | Executes a script against the input data.
 
-
 | resumeTask
 | Resumes suspended task(s).
 
-
 | resolveReference
 | Resolves reference(s).
 
-
 | applyDefinition
 | Applies definition to shadows or resources.
 
-
 | purgeSchema
 | Removes all schema information from given resource(s).
 
-
 | testResource
 | Tests resource(s).
 
-
 | generateValue
 | Generates value(s) for object(s).
 
-
 | notify
 | Sends a custom notification event for objects.
 
-
 | log
 | Logs the input data.
 
-
 |===
 
 The following actions were not changed and are accessible only in the traditional way:
@@ -156,9 +140,7 @@ The following actions were not changed and are accessible only in the traditiona
 | discover-connectors
 | Discovers all connectors on given connector host(s).
 
-
 | validate
 | Validates resource(s) - i.e. provides a set of issues just like in Resource Wizard (since 3.5)
 
-
-|===
+|===

docs/misc/bulk/index.adoc

@@ -72,7 +72,6 @@ Hoping its time will come it is described xref:/midpoint/devel/design/bulk-actio
 </s:search>
 ----
 
-
 .Example 3: Disabling selected users
 [source,xml]
 ----
@@ -173,10 +172,8 @@ It is possible to specify the target resource by OID (example 4a). In the future
 </s:search>
 ----
 
-
 == The language and its execution model
 
-
 === Scripting expressions
 
 The basic building block of the language is *a scripting expression*. The expression is a piece of code that may have an input, does some processing, and (optionally) produces an output.
@@ -222,7 +219,6 @@ Output of the last expression is considered to be the output of the whole sequen
 
 Other planned expression types: are constant expressions, initialization and use of variables, or filtering input values.
 
-
 === Actions
 
 An action modifies the input data (or acts on it in any other way).
@@ -418,17 +414,14 @@ Some simple examples of scripts in XML form can be found in *resources/scripting
 Since 3.6, `executeScript` action and `notify` action (that contains custom handler) require superuser authorization, because they allow direct execution of user-supplied scripts (groovy, JavaScript, and so on).
 ====
 
-
 == Other features
 
-
 === Embedding in tasks
 
 Scripts can be run within tasks.
 That is extremely useful for long-running scripts.
 More information is on this page.
 
-
 === Data being passed
 
 The common data format to be passed between expressions, accepted as script input, or provided as script output is the list of prism values (corresponding to objects, containers, references, or properties).
@@ -440,7 +433,6 @@ So, for example, after selecting 100 users and attempting to disable them, one c
 Serialization of the data is described here.
 (TODO)
 
-
 === Console output
 
 As in other scripting languages, midPoint scripting also provides an easily-understandable text output of individual commands.
@@ -453,7 +445,6 @@ However, the "console output" feature is meant to be a quick and easy way to con
 In current implementation, each action puts there information on actions taken (users enabled, disabled, deleted, modified, ...), along with warnings and errors.
 For any other information, the operation result should be analyzed and displayed.
 
-
 === Error handling
 
 Currently, the policy is "stop on any exception".
@@ -466,7 +457,6 @@ Note that actions themselves are also a bit picky.
 When they get an object they cannot act upon (e.g. a PrismPropertyValue in situations where they expect PrismObjectValue, or a ResourceType when they expect UserType), they treat this like a fatal error and stop the execution of the whole script.
 Also this behavior could be made configurable in the future.
 
-
 == Tools
 
 TODO (GUI, Eclipse plugin, command-line client)

docs/repository/native-audit.adoc

@@ -458,7 +458,18 @@ MIDPOINT_HOME='/var/new-mp-home' bin/ninja.sh -v importAudit -i audit-export.xml
 
 ==== Iterative audit migration
 
-// TODO
+////
+TODO
+Audit times on percentile boundaries, perhaps id is even better:
+SELECT unnest(percentile_disc(
+        (
+        SELECT array_agg(x)
+        FROM generate_series(0, 1, (1::numeric) / 10) as g(x)
+        )
+    ) WITHIN GROUP (ORDER BY timestamp)
+    ) as l
+FROM ma_audit_event;
+////
 
 == Custom column