[OPENIDM-5914] Role is still showing as assigned in effectiveRoles attribute on query-all output if role is unassigned via the admin UI Created: 01/Jun/16 Updated: 12/Feb/18 Resolved: 07/Feb/18
|Component/s:||Module - Roles|
|Affects Version/s:||OpenIDM 4.0.0, OpenIDM 4.5.0, OpenIDM 5.0.0|
|Fix Version/s:||OpenIDM 6.0.0|
|Reporter:||Andy Itter||Assignee:||Alin Brici|
|Labels:||LEWIS, regroom, release-notes|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Support Ticket IDs:|
If a role is assigned to a user using the openidm/managed/user endpoint and then subsequently deleted via the OpenIDM Admin UI then the role is present in the effectiveRoles attribute when using managed/user?_queryId=query-all but not when getting the user individually using managed/user/a8...5c
0). Add a role to a user:
1). Use the OpenIDM 4 Admin UI and remove the role assignment from the user.
2). Get the individual user:
Note the role is not present as expected.
3). Get all user objects:
Note the role is still present in effectiveRoles.
The content of effectiveRoles when getting the user individually or when using query-all should be consistent.
|Comment by Andy Itter [ 01/Jun/16 ]|
Additionally, note that if the role is unassigned from the user using the following rather than the Admin UI:
...then the effectiveRoles output is as expected for the two scenarios.
Note that the observed behaviour mentioned in the initial description is the same on the snapshot build.
|Comment by Laurent Bristiel [ 08/Jun/16 ]|
I could reproduce this bug in 4.0.0 (strange bug!) but not in 4.5 and 5.0, so it was fixed somehow in the meantime.
|Comment by Andy Itter [ 28/Jun/16 ]|
Tested this again myself just now. This issue is still present in the current 4.5 RC2 build:
|Comment by Dirk Hogan [ 28/Jun/16 ]|
When a provisioning role is removed from a user, a DELETE is performed upon either:
Keep in mind that #1 does not cause the behavior documented in this defect, and #2 does.
Both of these requests are fielded by RelationshipProvider#deleteInstance. In both cases, RelationshipProvider#deleteInstance will:
Note that effectiveAssignments are persisted in managed user so that sync diff logic can handle various delete scenarios, especially when target systems are offline, or implicit sync disabled, at the time where the delete takes place. This is crucial, and explains why this defect only occurs when the role grant is deleted from roles in the Admin UI: in this case, only the role is persisted, and the managed user is synced. This means that the effectiveRoles array in the managed user is never updated to reflect the role grant deletion. In this case, the managed user's effectiveRoles array will contain the role reference (reflecting the previous grant), but the relationship table will have no record of this role grant. A GET on managed/user with _queryId=query-all simply returns the state in the managed user table, which returns the outdated effectiveRoles state. However, when the role grant is updated via the user in the Admin UI, the user is persisted in the repo, and the effectiveRoles array updated/persisted accordingly, which is reflected in the correct query response.
I don't think that this defect can be addressed without a significant relationship refactor, but there is a work-around. If executeOnRetrieve=true is appended to the query, the correct state is returned:
|Comment by Dirk Hogan [ 09/Sep/16 ]|
Re-evaluating this issue in the 5.0.0 time-frame, I can corroborate my analysis above. The only correction I would make is I'm not sure we persist effectiveRoles in order to help with the sync diff logic - I'm not sure why this state is persisted. Also any GET automatically executes the onRetrieve script, whereas a query will only execute the onRetrieve script if executeOnRetrieve is set to true. See https://bugster.forgerock.org/jira/browse/OPENIDM-1732 for more context.
I had hoped that relationships would be refactored in the 5.0.0 time-frame, but we will have to wait until 5.5 or 6.0. The fundamental issue is that in persisting effectiveRoles, we essentially persist some of the relationship graph in a graph vertex, state which is not updated when the relationship graph is mutated. That being said, it appears that the effectiveRoles array was intended to be a calculated field, and it is an established idiom to pass the executeOnRetrieve to query requests to obtain the updated state of calculated fields. Which begs the question why effectiveRoles are ever persisted in the first place - a question I cannot answer.
|Comment by andi [ 09/Sep/16 ]|
Virtual fields by default are persistet to
I'm not sure if b) is currently used, and a) may only currently be in use for assignment detection, it's very well possible that our default scripts don't need to do role assignment delete detection.
|Comment by Dirk Hogan [ 12/Sep/16 ]|
Thanks for the info andi.
For a bit more context regarding the storage of effectiveAssignments, here's an excerpt from an email from Jake Feasel, from a while back:
For example, imagine an assignment was configured to provide two entries within ldapGroups using the "merge with target" assignment operation: "cn=Group1" and "cn=Group2". All users with that assignment will have those two groups (among others, possibly). Also, all users with that assignment will have a copy of the assignment persisted in their record, as a result of the virtual property storage.
Then, if the assignment definition is changed so that it only provides "cn=Group1" (omitting "cn=Group2"), the desired behavior is that all users which had been granted the assignment in its earlier state would be have "cn=Group2" removed from their ldapGroups property. This gets us to the sole reason (as far as I know) that we persist the effectiveAssignments value in the managed/user record - so that we can compare the last version that was saved for the user with the version that now exists, and apply the difference.
Because the relationship refactor is not making it into the 5.0 release, I will change the target version to 5.5.
|Comment by Alin Brici [ 07/Feb/18 ]|
Has been fixed during our recent refactor of relationships.
|Comment by Laurent Bristiel [ 12/Feb/18 ]|
checked OK in OpenIDM version "6.0.0-SNAPSHOT" (revision: d5c6fa2)