Merge remote-tracking branch 'origin/master' into feature/mini-full-o…

…bjects

docs/admin-gui/look-feel-customization.adoc

@@ -32,7 +32,7 @@ Simple style and javascript changes can be done via maven overlay by adding cont
 
 These files are empty by default and are linked last on midPoint web pages.
 
-For more details see xref:../../devel/gui/gui-development-guide.adoc#styles-and-javascript[GUI development guide].
+For more details see xref:/midpoint/devel/gui/gui-development-guide.adoc#styles-and-javascript[GUI development guide].
 
 == Quick customization
 
@@ -105,4 +105,4 @@ AdminLTE supports few theme colors:
     <headerColor>#444</headerColor>
     <skin>secondary</skin>
 </deploymentInformation>
-----
+----

docs/cases/approval/index.adoc

@@ -10,7 +10,7 @@
 :page-upkeep-status: red
 :page-upkeep-note: Old approvals vs new approvals
 
-Approval is perhaps the most frequently used type of xref:/midpoint/reference/cases/workflow-3/[workflow] in the IDM solutions.
+Approval is perhaps the most frequently used type of workflow in the IDM solutions.
 It is used so often that the approval process has a special place in midPoint.
 The approval mechanisms are pre-defined and pre-configured in such a way that it is easy to implement majority of approval scenarios by simply using declarative approach.
 Workflow process modeling is almost never needed.
@@ -96,12 +96,10 @@ Although it was - in some form - present also in midPoint 3.4.1 and earlier (usi
 
 == See Also
 
-* xref:/midpoint/reference/cases/workflow-3/[Workflows (midPoint 3.x)]
-
 * xref:/midpoint/reference/roles-policies/assignment/[Assignment]
 
 * xref:/midpoint/reference/roles-policies/policy-rules/[Policy Rules]
 
 * xref:/midpoint/reference/roles-policies/role-lifecycle/[Role Lifecycle]
 
-* xref:/midpoint/reference/misc/deputy/[Deputy]
+* xref:/midpoint/reference/misc/deputy/[Deputy]

docs/cases/approval/policy-based-approvals.adoc

@@ -13,10 +13,9 @@ MidPoint is identity management and governance system, therefore it is quite nat
 
 However, the mechanism that midPoint employs to drive the approvals is quite unique.
 Almost all other IDM systems used workflow engine to drive the approvals.
-And midPoint did the same thing in the past.
-But it was not a good approach.
-It was difficult to set up and and maintain.
-Therefore midPoint slowly drifted away from the use of workflow engine until the workflow engine was completely replaced in midPoint 4.0.
+MidPoint did the same thing in the past, but it was not a good approach.
+It was difficult to set up and maintain the processes.
+Therefore, midPoint slowly drifted away from the use of workflow engine until it was replaced by declarative policy in midPoint 4.0.
 
 Current mechanism to drive approvals is based on policies rather than processes.
 There are xref:/midpoint/reference/roles-policies/policy-rules/[policy rules] that specify individual aspects of an approvals.
@@ -58,76 +57,6 @@ Change the policies and midPoint will automatically adapt.
 No need to re-draw BPMN diagrams.
 MidPoint does all of that under the hood.
 
-
-== History of workflow engine in midPoint
-
-Similarly to almost any other IDM system, midPoint has started with integrated _workflow engine_. When midPoint was young this was quite an obvious thing to do.
-Something needs to drive the approval processes, right? And we want to make those customizable.
-And maybe, the workflow can be used to customize all the processes, eventually.
-And all the major competing products had workflow engine.
-Therefore, we havent really doubted whether workflow is needed or not.
-We just did it.
-
-MidPoint had integrated fully-featured workflow engine almost since the beginning.
-But all that this engine was ever used for was to drive approval processes.
-There is actually no need for the workflow to do anything else.
-In fact, workflow engines in other IDM systems are often (ab)used to implement features that such IDM systems do not have.
-And this is often the only way how to implement something in closed-source systems.
-But midPoint is different.
-The midPoint way is to implement the feature in midPoint core  and then reuse it many times.
-We even have a special xref:/support/subscription-sponsoring/["platform subscription"] model to support this approach from a business side.
-In addition to that midPoint already has plenty of better mechanisms for customization: mappings, expressions, hooks and so on.
-The result is, that no midPoint subscriber had no need to abuse the workflow engine.
-
-Up until midPoint 4.0 the workflow engine was used to drive approvals.
-But in fact it did not do it incredibly well.
-Workflow engine is in fact just a simple automaton.
-It does not know who should approve the request.
-It does not know how to divide the request to atomic parts.
-It does not know how many levels (stages) and approval strategies are needed.
-In fact, it does not know anything about roles.
-It even does not know that the process is an approval process.
-All of that needs to be computed in midPoint.
-All that the workflow engine does is to interact with the user in a series of steps.
-And even that interaction is mediated by midPoint user interface.
-The value that a workflow engine adds to midPoint is very close to zero.
-But as workflow engines are quite a substantial pieces of software, the maintenance overhead related to keeping the workflow engine integrated is quite high.
-
-However, there is one crucial reason why midPoint does not really need workflow engine.
-Many IDM systems are proud to claim that they are _process-oriented_. This makes perfect sense at a first sight.
-Business processes are inherently process-oriented, arent they? Therefore, it would be natural if IDM system also followed the process-oriented approach.
-But this thinking is misleading.
-It is much better to think about business rules instead of processes.
-Processes are often the same in their essence.
-There are just many process variations based on various circumstances.
-And those can be defined by the rules.
-MidPoint can use the rules to dynamically compute specific process for specific circumstances.
-
-Lets use approval process as an example.
-There are roles that do not need any approval.
-There are roles that has to be approved by managers.
-There are roles that need to approved by their owners.
-And sensitive roles may need even more approval levels.
-It is quite difficult to design an approval process that can handle all such situations - and all their combinations.
-User may request a set of roles that has few roles from each category.
-The process need to split that to subprocesses, otherwise the slowest path will slow down the fast paths.
-Each subprocess will need to analyze the roles, handle the stages, approval delegations, escalation and so on.
-And it needs to be done for each and every deployment.
-This is a nightmare.
-But it all gets much simpler when we think in rules instead of processes.
-Lets just set up rules that specify which roles needs pass through which approval stages and who is supposed to be an approver for each stage.
-Then midPoint can compute the sequence of approval steps that need to be taken for each particular request.
-This algorithm needs to be implemented only once.
-And in fact, we have already implemented it and it is part of midPoint core.
-No need to reinvent the wheel for each deployment.
-
-The bottom line is that midPoint does not really need a workflow engine.
-The workflow engine does not add any significant value  and it has become a maintenance burden.
-Therefore we took a bold step and removed the workflow engine in midPoint 4.0. The workflow engine was replaced with native midPoint functionality that was silently brewing inside midPoint for several years.
-Now it is clear that use of integrated workflow engine in IDM systems was a bad idea.
-Removing that engine was a right step to take.
-
-
 == See Also
 
-* xref:/midpoint/reference/roles-policies/policy-rules/[Policy Rules]
+* xref:/midpoint/reference/roles-policies/policy-rules/[Policy Rules]

docs/cases/notifications.adoc

@@ -76,4 +76,3 @@ This documentation is not complete yet.
 
 For more information about notifications in general, please see xref:/midpoint/reference/misc/notifications/configuration.adoc[].
 
-For more information about approval notifications - that may or may not be applicable in the current version of midPoint - please see (now obsolete) xref:workflow-3/workflow-notifications.adoc[].