Task #586
closedUnique identifier provisioning replaced by synchronization and again, and again
100%
Description
The situation is as follows: I have a system with mapped attribute A. The attribute A is set as identifier during provisioning and also during synchronization. The system uses as its identifier a different attribute (lets call it B). When we are synchronizing from the system and create an entity, the entity's AccAccount identifier will be set to the attribute B (even when we set the A should be the identifier).
Please check this scenario and if it's true, correct the bug.
Updated by Jan Helbich almost 7 years ago
I have the same problem. In my opinion, the AccAccount#uid shall be filled according to identifier attribute of synchronization mapping, just as Ondra describes. Otherwise the identifier attribute does not even make any sense, since IC framework enforces returning \__UID__ and \__NAME__ attributes on GET / SEARCH operations -> SysSystemEntity and AccAccount would always get the identifier from the connector.
For synchronization, I'd expect following behavior:- SysSystemEntity#uid gets the value of \__UID__ obtained from connector
- AccAccount gets the value of the identifier attribute in synchronization attribute mapping, which must be present in the attribute result set returned by the connector
- if the identifier is not returned, throw an exception
- transformation FROM system must be applied to the attribute value, of course
Updated by Vít Švanda almost 7 years ago
- Status changed from New to In Progress
- Target version set to Citrine (7.3.0)
- % Done changed from 0 to 40
Updated by Vít Švanda almost 7 years ago
- % Done changed from 40 to 80
Modified:
- AccAccount.UID is now (during sync) filled by transformed value from UID attribute.
- UID attribute must exist in sync mapping now (for create link / entity situation)!
- UID attribute (transformation from system ) must return not null String value!
TODO: describe use case to wiki
Updated by Vít Švanda almost 7 years ago
Update AccAccount.UID in linked situation implemented.
Updated by Vít Švanda almost 7 years ago
- Status changed from In Progress to Needs feedback
- Assignee changed from Vít Švanda to Ondřej Kopr
- % Done changed from 80 to 90
Description added to wiki: https://wiki.czechidm.com/7.3/dev/account-management#name_of_account_in_idm
Ondra could you please make a review and test?
Updated by Ondřej Kopr almost 7 years ago
- Status changed from Needs feedback to Resolved
- Assignee changed from Ondřej Kopr to Vít Švanda
- % Done changed from 90 to 100
I did review, i simulated very similar behavior as in project. Now is problem with uid attribute ok. Thanks for fixing this discrepancy. Thanks.