Affects Version/s: 3.6 (Comenius)
Fix Version/s: 3.6.1
After executing approved changes a data corruption may occur.
The reason is that when storing computation state (model context) into task(s) for later execution i.e. after approvals/rejections, we store secondary (computed) deltas along with primary ones.
These secondary deltas contain e.g. assignments that are to be deleted because of 1-of-N exclusion; or roleMembershipRef attribute computed when evaluating the original request.
Possible outcomes, demonstrated by tests:
- resulting roleMembershipRef contains references to roles that are not yet approved, or that were rejected
- some (random) assignments could get deleted because of wrongly applied 1-of-N result (even the audit log is misleading in this case, because of assignment id vs content mismatch)
- "1-of-N" is applied even if the original ("radio") assignment is not approved
Note that roleMembershipRef is corrected by any operation executed on the particular user. But until then, the data is wrong. Fortunately, on user log-in, the authorizations are derived from actual assignments, not from roleMembershipRef. Also projections (accounts, entitlements) are computed from assignments, not from this field. But there are some occasions when we search for members of a role based on roleMembershipRef, e.g. when determining approvers, owners (for approvals or certification), etc.
See also TestSecondaryChanges.