-
Notifications
You must be signed in to change notification settings - Fork 19
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
Labels
Comments
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
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.
The text was updated successfully, but these errors were encountered: