Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Some examples

TODO

Some ideas

...

presentation element on policy constraints

ItemMeaningExample
messageMessage to be conveyed to the user. It is a LocalizableMessage (or equivalent), having key, parameters, and fallbackMessage.todo
shortMessageVery short message describing the situation. Could be used for e.g. notification messages subject, approval process or work item names. TODO. Again, a LocalizableMessage.todo
longMessage(TODO better name) - long, documentation-like explanation of the rule 
importanceHow important is this particular information. E.g. major, normal, minor, none (or should we use numbers to provide more flexibility?). By default, only the highest-level messages are shown. If requested, user could view also lower-level messages.todo

Alternative 1: Persistence

Triggers and situations take storage place and processing time when maintaining. So they are made configurable with regards to their storage using the following two parameters of policy constraints:

ItemMeaningValues
situationPersistenceShould the situation stemming from this constraint be persistently stored?full, none
triggerPersistenceShould the trigger stemming from this constraint be persistently stored?full, user-information, user-information-highest, none

Alternative 2: Expected use

Value of expectedUse propertyMeaning 
certificationSituation and triggers will be stored. 
brief-reportSituation will be stored but no triggers. 
full-reportSituation and triggers will be stored. 

Storage conservation (if triggers are to be stored)

Value of storageCompaction propertyMeaning
fullOnly message and short message will be stored.
normalWhole triggers will be stored. (But only those that are directly marked with expectedUse property.)
noneWhole triggers will be stored, including subtriggers.

 

An example

Code Block
languagexml
titleExample of user information
<policyRule>
    <!-- here we simply state that it's not possible to have active role with no description or no owner or no approver -->
    <name>disallow-incomplete-role-activation</name>
    <policyConstraints>
        <userInformation><presentation>
            <message>
                <key>AttemptToActivateIncompleteRole</key>
            </message>
            <importance>major</importance>		<!-- this is a major cause; after 'clicking-through' the user could see details: that the role is incomplete, and the reason: no owner/approver or no description -->
        </userInformation>presentation>
        <objectState>
            <name>active lifecycleState</name>
            <filter>
                <q:equal>
                    <q:path>lifecycleState</q:path>
                    <q:value>active</q:value>
                </q:equal>
            </filter>
        </objectState>
        <or>
            <name>incomplete-role</name>
            <policySituation>...#incompleteRole</policySituation>       <!-- we should provide policySituation specification also at the level of constraint -->
            <!-- alternative 1 -->
            <situationPersistence>full</situationPersistence>		    <!-- although there could be no incomplete active roles, we might want to report on e.g. incomplete roles in draft state -->
            <triggerPersistence>user-information</triggerPersistence>	<!-- we want to store user information only to conserve space -->
            <userInformation><!-- alternative 2 -->
            <expectedUse>full-report</expectedUse>
            <storageCompaction>full</storageCompaction>
            <presentation>
                <message>
                    <key>RoleIncomplete</key>
                </message>
            </userInformation>presentation>
            <minAssignees>
                <!-- default importance is normal; and the constraint is self-explanatory, so no need to provide user information here -->
                <multiplicity>1</multiplicity>
                <relation>owner</relation>
                <relation>approver</relation>
            </minAssignees>
            <objectState>
                <name>no-description</name>		<!-- we could also use some default mechanism to derive message keys, like policyConstraint.no-description -->
                <filter>
                    <q:equal>
                        <q:path>description</q:path>
                    </q:equal>
                </filter>
            </objectState>
        </or>
    </policyConstraints>
    <policyActions>
        <enforcement/>
    </policyActions>
    <evaluationTarget>focus</evaluationTarget>
</policyRule>

...

Code Block
languagexml
titleRole could not be assigned to users from specified cost centers
<policyRule>
    <name>approval-for-cc-19xx</name>
    <description>Assignment of this role to users from cost centers 1900-1999</description>
    <policyConstraints>
        <objectState>
            <name>cc-19xx</name>
            <userInformation><presentation>
                <message>
                    <key>AssignmentToUserFromWrongCostCenter</key>  <!-- e.g. attempt to assign role {0} to a user from cost center {1} (in the range of 1900-1999) -->
                    <param>
                        <index>0</index>
                        <source>
                            <path>$target/name</path>
                        </source>
                    </param>
                    <param>
                        <index>1</index>
                        <source>
                            <path>$focus/costCenter</path>
                        </source>
                    </param>
                </message>
                <importance>major</importance>
            </userInformation>presentation>
            <filter>
                <q:and>
                    <q:greaterThan>
                        <q:path>costCenter</q:path>
                        <q:value>1900</q:value>
                    </q:greaterThan>
                    <q:lessThan>
                        <q:path>costCenter</q:path>
                        <q:value>1999</q:value>
                    </q:lessThan>
                </q:and>
            </filter>
        </objectState>
   </policyConstraints>
   <policyActions>
       <approval>
           <!-- ... -->
       </approval>
   </policyActions>
</policyRule>