Merge remote-tracking branch 'origin/master' into feature/merge

config/initial-objects/role/040-role-enduser.xml

@@ -243,6 +243,9 @@
         </object>
     </authorization>
     <adminGuiConfiguration>
+        <feedbackMessagesHook>
+            <stackTraceVisibility>hidden</stackTraceVisibility>
+        </feedbackMessagesHook>
         <homePage id="34">
             <type>UserType</type>
             <widget id="35">

config/initial-objects/role/042-role-reviewer.xml

@@ -95,4 +95,16 @@
         <item>riskLevel</item>
         <item>serviceType</item>
     </authorization>
+    <authorization>
+        <name>certification-campaign-read</name>
+        <description>
+            Allow to read stageNumber property of certification campaign.
+        </description>
+        <action>http://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#read</action>
+        <object>
+            <type>AccessCertificationCampaignType</type>
+        </object>
+        <item>name</item>
+        <item>stageNumber</item>
+    </authorization>
 </role>

config/initial-objects/user/050-user-administrator.xml

@@ -25,11 +25,4 @@
     <activation>
         <administrativeStatus>enabled</administrativeStatus>
     </activation>
-    <credentials xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3">
-        <password>
-            <value>
-                 <t:clearValue>5ecr3t</t:clearValue>
-             </value>
-        </password>
-    </credentials>
 </user>

config/initial-objects/value-policy/010-value-policy.xml

@@ -9,37 +9,62 @@
         xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
         xmlns:t="http://prism.evolveum.com/xml/ns/public/types-3"
         version="0">
-    <name>
-        <t:orig>Default Password Policy</t:orig>
-        <t:norm>default password policy</t:norm>
-    </name>
+    <name>Default Password Policy</name>
     <description>Default password policy</description>
     <stringPolicy>
         <description>Testing string policy</description>
         <limitations>
-            <minLength>5</minLength>
-            <!--             <maxLength>8</maxLength> -->
+            <minLength>8</minLength>
+            <maxLength>14</maxLength>
             <minUniqueChars>3</minUniqueChars>
             <checkAgainstDictionary>true</checkAgainstDictionary>
-            <checkPattern />
-            <!--             <limit> -->
-            <!--                 <description>Alphas</description> -->
-            <!--                 <minOccurs>1</minOccurs> -->
-            <!--                 <maxOccurs>5</maxOccurs> -->
-            <!--                 <mustBeFirst>false</mustBeFirst> -->
-            <!--                 <characterClass> -->
-            <!--                     <value>abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ</value> -->
-            <!--                 </characterClass> -->
-            <!--             </limit> -->
-            <!--             <limit> -->
-            <!--                 <description>Numbers</description> -->
-            <!--                 <minOccurs>1</minOccurs> -->
-            <!--                 <maxOccurs>5</maxOccurs> -->
-            <!--                 <mustBeFirst>false</mustBeFirst> -->
-            <!--                 <characterClass> -->
-            <!--                     <value>1234567890</value> -->
-            <!--                 </characterClass> -->
-            <!--             </limit> -->
+            <checkPattern/>
+            <checkExpression>
+                <expression>
+                    <script>
+                        <code>
+                            if (object instanceof com.evolveum.midpoint.xml.ns._public.common.common_3.UserType) {
+                            return !basic.containsIgnoreCase(input, object.getName()) &amp;&amp; !basic.containsIgnoreCase(input, object.getFamilyName()) &amp;&amp; !basic.containsIgnoreCase(input, object.getGivenName()) &amp;&amp; !basic.containsIgnoreCase(input, object.getAdditionalName())
+                            } else {
+                            return true
+                            }
+                        </code>
+                    </script>
+                </expression>
+                <failureMessage>must not contain username, family name and given name and additional names</failureMessage>
+            </checkExpression>
+            <limit>
+                <description>Lowercase characters</description>
+                <minOccurs>1</minOccurs>
+                <mustBeFirst>false</mustBeFirst>
+                <characterClass>
+                    <value>abcdefghijklmnopqrstuvwxyz</value>
+                </characterClass>
+            </limit>
+            <limit>
+                <description>Uppercase characters</description>
+                <minOccurs>1</minOccurs>
+                <mustBeFirst>false</mustBeFirst>
+                <characterClass>
+                    <value>ABCDEFGHIJKLMNOPQRSTUVWXYZ</value>
+                </characterClass>
+            </limit>
+            <limit>
+                <description>Numeric characters</description>
+                <minOccurs>1</minOccurs>
+                <mustBeFirst>false</mustBeFirst>
+                <characterClass>
+                    <value>1234567890</value>
+                </characterClass>
+            </limit>
+            <limit>
+                <description>Special characters</description>
+                <minOccurs>0</minOccurs>
+                <mustBeFirst>false</mustBeFirst>
+                <characterClass>
+                    <value> !"#$%&amp;'()*+,-.:;&lt;&gt;?@[]^_`{|}~</value>
+                </characterClass>
+            </limit>
         </limitations>
     </stringPolicy>
 </valuePolicy>

docs/deployment/ninja/command/export-audit.adoc

@@ -1,6 +1,6 @@
 = Export audit
 
-#TODO split into export and import#
+//TODO split into export and import
 
 [NOTE]
 Audit export/import uses the same format as objects, even utilizing `<objects>` element,
@@ -10,15 +10,15 @@ These files are only useful for Ninja import/export, do not try to use them in S
 .Example: audit export to a zipped file, overwriting any existing file, using an Axiom filter
 [source,bash]
 ----
-ninja.sh exportAudit -o audit-export.xml.zip -z -O -f '%timestamp < "2021-12-01"'
+./bin/ninja.sh exportAudit -o audit-export.xml.zip -z -O -f '%timestamp < "2021-12-01"'
 ----
 
 Now you can move the exported file to a new environment and run the import:
 
 .Example: audit import
 [source,bash]
 ----
-ninja.sh importAudit -i audit-export.xml.zip -z
+./bin/ninja.sh importAudit -i audit-export.xml.zip -z
 ----
 
 Check also the xref:/midpoint/reference/repository/native-audit/#audit-migration-from-other-database[migration guide for the Native audit].

docs/deployment/ninja/command/import-audit.adoc

@@ -1,3 +1,3 @@
 = Import audit
 
-#TODO#
+//TODO

docs/deployment/ninja/command/initial-objects.adoc

@@ -38,7 +38,7 @@ There are two main scenarios that can be followed:
 * <<No changes in initial objects>>
 * <<Custom changes in initial objects>>
 
-==== No changes in initial objects
+== No changes in initial objects
 
 This one is the simplest case.
 If there are no custom changes in initial objects made by users, then ninja can update initial objects automatically.
@@ -50,7 +50,7 @@ Following command can be used (please use `--dry-run` if you want to see what wi
 ./bin/ninja.sh initial-objects --no-merge
 ----
 
-==== Custom changes in initial objects
+== Custom changes in initial objects
 
 If there are custom changes in initial objects made by users, then ninja can help you merge them.
 First, dry run is recommended to see what needs to be done, optionally with report of changes:
@@ -68,7 +68,7 @@ If there are objects (filtered by types or oids) that can be handled without mer
 ./bin/ninja.sh initial-objects --no-merge [--type securityPolicy,valuePolicy,...] [--oid 93ae3cd3-b34d-4093-ad49-adba573a95ba]
 ----
 
-==== Important updates
+== Important updates
 
 There is at least one object - securityPolicy that needs to be updated when upgrading LTS from 4.4 to 4.8.
 If there are no custom changes in securityPolicy, following command can be used:

docs/deployment/ninja/command/upgrade-distribution.adoc

@@ -1,3 +1,26 @@
 = Upgrade distribution
 
-#TODO#
+Upgrade distribution command a composite command that will do multiple steps at once:
+
+* xref:./pre-upgrade-check.adoc[Pre-upgrade check
+* xref:./verify.adoc[Verification]
+* xref:./download-distribution.adoc[Download distribution]
+* Upgrade DB schema
+* xref:./upgrade-installation.adoc[Upgrade installation]
+
+MidPoint has to be down before this command is executed.
+
+Pre-upgrade check can be skipped if necessary using `--skip-pre-check` option.
+This might be useful for custom builds with DB schema version that doesn't match proper version of relevant midPoint release.
+
+Verification in step two will check for items with _critical_ priority and stops upgrade if there are any.
+Although not recommended, verification step can be skipped by using `--skip-verification` option.
+
+Download distribution step can be customized with option `--distribution-version` to download specific version of midPoint.
+To skip download altogether, ninja can be pointed to already downloaded archive using `--distribution-archive` option.
+
+Upgrade DB schema will use xref:../command/run-sql.adoc[run-sql] command to upgrade DB schema using SQL scripts downloaded in previous steps.
+
+Final step is upgrade installation that will update midPoint installation directory with new distribution.
+Backup of files can be created using `--backup-midpoint-directory` option.
+`midpoint.home` directory is not changed during this step.

docs/deployment/ninja/command/upgrade-objects.adoc

@@ -1,13 +1,25 @@
 = Upgrade objects
 
-Command `upgrade-objects` can be used to _upgrade_ objects to get rid deprecated or obsolete items and configuration.
-This operation can use CSV output file of `verify` command.
+Command `upgrade-objects` can be used to _upgrade_ objects to get rid of deprecated or obsolete data and configuration.
+This operation should be used with CSV output file from `verify` command.
+For more information about verification, see xref:./verify.adoc[].
+
+Verification report should be reviewed before running upgrade command.
+It is important to understand what will be changed and how can it affect the system.
+
+Only verification items with _type = seamless_ will be updated.
+Scope of upgrade-objects command can be set in several ways:
+
+* by oid (`--oid`)
+* by type (`-t, --type`) and filter (`-f, --filter`)
+
+This way it is possible to upgrade only specific objects.
+Verification items can be skipped also using last column in CSV file.
+Any of `true`, `t`, `yes`, `y` will tell ninja to skip the item.
 
 .Example of command that upgrades objects, also with
 [source,bash]
 ----
 ./bin/ninja.sh upgrade-objects \
   --verification-file verify-output.csv
 ----
-
-#TODO#

docs/deployment/ninja/command/verify.adoc

@@ -1,19 +1,53 @@
 = Verify
 
-Command that verifies objects in midPoint repository.
-It displays warnings about objects to `SYSOUT` or file.
-Similarly to export, one can define oid, multiple types or filter to filter verified objects.
-Simple usage to verify all objects in the repository for all warnings:
+Verification is a process that reads objects from midPoint repository and checks whether they are compatible with new version of midPoint.
+Verification checks for deprecated, removed elements or other issues that can cause problems during or after upgrade.
 
-.Example which verifies all objects in repository, checks all warnings
-[source,bash]
-----
-./bin/ninja.sh verify
-----
+Different categories for verification can be set turned on via switch `--verification-category [DEPRECATED|REMOVED|PLANNED_REMOVAL|INCORRECT_OIDS]`.
+By default, all categories are checked.
+
+By default, ninja displays warnings about objects to `SYSOUT`.
+Output can be redirected to file using `-o`, `--output`.
+
+Verification can run while midPoint is running.
+The whole verification can be split into multiple parts, each part verifying a subset of similar objects using `-f, --filter` and `-t, --type` options.
+This way verification reports can be simpler to read and easier to understand, since they should contain smaller set of issues.
+
+Verification results can be reported in two styles plain and CSV.
+The switch for report style is `--report-style [plain|csv]`.
+Plain style is set as default option, while CSV is better for further processing and review.
+CSV report style creates two files - CSV and XML.
+XML will contain list of deltas for each object, describing what ninja wants to change on object to _upgrade_ it.
+
+The CSV report contain three sets of columns:
+
+* Object identification (oid, name, type)
+* Verification item information (status, path, message)
+* Upgrade information (multiple columns see <<Upgrade information>>)
+
+== Upgrade information
+
+Upgrade information consists of following columns:
+
+* *Identifier* - unique identifier of verification/upgrade item which can be used to group similar items together when processing reports.
+* *Phase* - upgrade phase in which item should be updated (before or after midPoint is upgraded).
+* *Priority*
+** *Critical* - midPoint may fail to start or work properly if such verification item is not fixed (updated).
+Critical item would also halt upgrade procedure in next phase, unless this check is explicitly skipped using `--skip-verification` option.
+** *Necessary* - verification item should be fixed, midPoint should not fail to start, but some features might not work properly.
+** *Optional* - this item doesn't have to be necessarily fixed, but it's recommended to do so.
+E.g. deprecated configuration which might be removed in version after next one.
+* *Type*
+** *Seamless* - such item can be handled by ninja automatically without any user interaction.
+E.g. there's clear migration path without any change in functionality.
+** *Preview* - ninja can provide new configuration for such item, but it's recommended to review it before applying.
+** *Manual* - ninja can't provide any configuration for such item, user has to fix it manually.
+Reason can be that there's currently no migration path (removed feature) or there are multiple possible solutions that doesn't map configuration 1:1.
+* *Description* - contains more information, mainly on how to upgrade/update such item.
+* *Skip* - last column in CSV report, can be used to mark items that should be skipped during object upgrade.
 
-There is a `-w` switch that can be used to select specific warnings to display.
-Currently, it only supports values deprecated and plannedRemoval.
-Following command will show warnings about planned removal of items used by all objects in the repository:
+Such CSV report has to be used as input for upgrade objects command with option `--verification-file`.
+See xref:./upgrade-objects.adoc[] for more information.
 
 .Example which verifies all objects in repository, checks only planned removal of items
 [source,bash]