Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sync logic does not allow proper handling of object relocation (re-link) #11

Open
pavelhoral opened this issue Aug 7, 2017 · 0 comments

Comments

@pavelhoral
Copy link
Member

When a linked object is moved in some systems, it's UID can change. This leads to MISSING situation, even if a new copy of the object can be located via correlation logic.

I am not sure if it is possible to implement RE-LINK and UPDATE operation with the current IdM synchronization logic, but would be nice if something like that achievable.

GuyPaddock pushed a commit to GuyPaddock/wrenidm that referenced this issue Mar 18, 2018
The documentation for the ICF Update SPI very clearly states that the UID of an object can change, which is why that operation returns the updated UID. Unfortunately, though the ICF provisioner in IDM goes to great pains to ensure this updated UID gets returned to the sync operation, it appears that it gets ignored by the operation and the link object does not get updated. This issue is present in IDM 4.x and IDM 5.x (including the current release version of IDM 5.5).

This is just a band-aid patch for specifically this issue. However, the entire SyncOperation class badly needs re-factoring. The `performAction()` method alone is 175 lines and contains a nasty, double-nested switch statement with intentional fall-throughs.

Closes WrenSecurity#11.
GuyPaddock pushed a commit to GuyPaddock/wrenidm that referenced this issue Mar 18, 2018
The documentation for the ICF Update SPI very clearly states that the UID of an object can change, which is why that operation returns the updated UID. Unfortunately, though the ICF provisioner in IDM goes to great pains to ensure this updated UID gets returned to the sync operation, it appears that it gets ignored by the operation and the link object does not get updated. This issue is present in IDM 4.x and IDM 5.x (including the current release version of IDM 5.5).

This is just a band-aid patch for specifically this issue. However, the entire SyncOperation class badly needs re-factoring. The `performAction()` method alone is 175 lines and contains a nasty, double-nested switch statement with intentional fall-throughs.

Closes WrenSecurity#11.
krystofNovotny pushed a commit to krystofNovotny/wrenidm that referenced this issue May 14, 2021
The documentation for the ICF Update SPI very clearly states that the UID of an object can change, which is why that operation returns the updated UID. Unfortunately, though the ICF provisioner in IDM goes to great pains to ensure this updated UID gets returned to the sync operation, it appears that it gets ignored by the operation and the link object does not get updated. This issue is present in IDM 4.x and IDM 5.x (including the current release version of IDM 5.5).

This is just a band-aid patch for specifically this issue. However, the entire SyncOperation class badly needs re-factoring. The `performAction()` method alone is 175 lines and contains a nasty, double-nested switch statement with intentional fall-throughs.

Closes WrenSecurity#11.
krystofNovotny pushed a commit to krystofNovotny/wrenidm that referenced this issue May 14, 2021
The documentation for the ICF Update SPI very clearly states that the UID of an object can change, which is why that operation returns the updated UID. Unfortunately, though the ICF provisioner in IDM goes to great pains to ensure this updated UID gets returned to the sync operation, it appears that it gets ignored by the operation and the link object does not get updated. This issue is present in IDM 4.x and IDM 5.x (including the current release version of IDM 5.5).

This is just a band-aid patch for specifically this issue. However, the entire SyncOperation class badly needs re-factoring. The `performAction()` method alone is 175 lines and contains a nasty, double-nested switch statement with intentional fall-throughs.

Closes WrenSecurity#11.
krystofNovotny pushed a commit to krystofNovotny/wrenidm that referenced this issue May 27, 2021
The documentation for the ICF Update SPI very clearly states that the UID of an object can change, which is why that operation returns the updated UID. Unfortunately, though the ICF provisioner in IDM goes to great pains to ensure this updated UID gets returned to the sync operation, it appears that it gets ignored by the operation and the link object does not get updated. This issue is present in IDM 4.x and IDM 5.x (including the current release version of IDM 5.5).

This is just a band-aid patch for specifically this issue. However, the entire SyncOperation class badly needs re-factoring. The `performAction()` method alone is 175 lines and contains a nasty, double-nested switch statement with intentional fall-throughs.

Closes WrenSecurity#11.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant