...

In midPoint there are many kinds of links among objects. They are differentiated by relation attribute of the particular object reference. Relations can be standard or custom. (More information on this topic can be found e.g. on Relation and Relation Configuration pages.)

These are typical linkssituations when two objects are linked:

...

...

When executing an operation on a link participant (focus object), one often needs to obtain a piece of data from the other link participant. Typical Basic cases are:

Derived (more complex) cases are:

...

Therefore, in order to navigate from assigned to assignee (i.e. finding assignee when recomputing assigned in scenarios 2/2a) we need to provide midpoint.findAssignee and midpoint.findAssignees methods. It is questionable if we also need a method to find assigned from assignee - normally this can be determined from assignmentPath.

Cascading the changes

Requirements

We need a mechanism that will propagate changes from one side of the link to the other one: either from assignee to assigned object, or from assigned object to the assignee.

In situations #1 and #2 1/1a we need to recompute users that hold a given role if:

• relevant parts of the role

...

• (i.e. cost center for scenario 1 or locality for scenario 1a) changes,
• or if the user-role link existence status changes - this is usually driven by changes on the user side (assignment existence, assignment activation) but the role can influence this as well (role deletion, role deactivation - either explicit or implicit, e.g. because of time validity).

In situations 2/2a we need to recompute services (badge, token) that are held by given user when if:

• relevant parts of the user changes

...

• (user's photo, user's name),
• or if the

...

• user-service link existence status changes - this is usually driven by changes on the user side (assignment existence, assignment activation) but the service can influence this as well.

Note that #11/#2 1a are exactly what the original "recompute affected" option did. However, the option has to be set manually. Today, we have much better options.

Solution

For the first draft, see https://github.com/Evolveum/midpoint/blob/fa13ce0dd8b460fb98b049ac6b405cbe7e39957c/model/model-intest/src/test/resources/linked/archetype-token.xml#L72-L152.

TODO update this The most natural way how to cascade the changes is to use policy rules.

Each rule has two main parts: condition and action:

1. The condition specifies when the rule will be applied. In our case, this means "something of interest has changed". So, for example, in situation #1 the condition covers modification of costCenter property. (The role deactivation/deletion will be treated later.) In situation #4 the condition covers modification of user's name. (Again, user creation/deletion, and token assignment/unassignment is treated later.)
2. The action specifies what to do when the rule is applied. In situation #1 the action is "recompute assignees". In situation #4 the action is "recompute (relevant) assigned objects".

Issues

TODO update this

Situation #1:

1. What if role is deleted? We can create a policy rule that will trigger on role deletion. But in the moment of executing the scripting action the role object is already gone. (See Projector and clockwork internals.) So the solution should be to delete roles gracefully: for example by changing their lifecycle state to retired. (A similar situation is in the Grouper asynchronous integration scenario, see here.) A special care should be taken to searching for members of retired roles; they do not have role reference in their roleMembershipRef item. Fortunately, when such reference is missing it means that the inactivation of role's cost center already took place.
2. What if role is added? Actually, nothing wrong normally occurs. If a new role is being added, it should have no assignees (except for the case of role deletion and re-creation but this can be ignored).

Situation #4:

1. When invoking policy action after token unassignment or user deletion, the token information can be already gone. Fortunately, if the token was assigned directly, we can find its traces in evaluatedAssignmentTriple. But it should be elaborated and tested well.
2. User creation and deletion, and token assignment and unassignment should be treated as separate policy conditions in addition to user name change. When specifying "token assignment/unassignment" condition, one should specify what "token" is. And the same specification must be part of the "recompute assigned objects" policy action. So we need some reusable/connected specification; at least in the future.

...

Miscellaneous

Enabling/disabling the change propagation

...