Hi Edward, I've finally been able to take a look at the provided information.
You can find my replies below. Regards. Edward Siewick wrote >>> The only guaranteed unique field from the (OrangeHRM) MySQL resource >>> is the key field, emp_number (an int data type). Within Syncope's >>> Resources / Schema Mappings for the resource, the key field isn't >>> provided as an option in the pulldown for External Attributes. It >>> does get set to Username, however. Ok, now I see: in the mapping, when you flag a row as 'AccountId' it gets linked to the key of the underlying resource; for SQL tables, this turns to be the primary key. >From your mapping, then, I see that you are associating Syncope's username with the primary key of the hs_hr_employee table, e.g. 8 / 9 / 11 / 14 / 15 / 16. Edward Siewick wrote >>> Now, the openLDAP wants a uid as a guaranteed unique value. (More >>> precisely, it wants a DN that happens to include the uid.) >>> The derived attribute (uid => username) in Schema was still not >>> working out for me. So I decided to poke at this by adding to the >>> MySQL resource's schema mapping uid => emp_firstname (Internal >>> Attributes => External Attributes) which I'd expected would produce a >>> string value in the uid fields. And, surprise! The derived attribute >>> (uid => username) instantly popped to life. The next run of the sync >>> task with the MySQL resource produced a complete set of (numeric) uids. >>> >>> To test this again, I added uidNumber => username as another derived >>> attribute. Again, it wouldn't populate automatically. I added >>> uidNumber => emp_smoker (a smallint in the MySQL schema.) The column >>> populated at the next sync with the MySQL resource. >From the LDAP mapping you have provided, I can see several anomalies: 1. the external attribute 'uid', usually defined by default as the key (see above) for LDAP resources, is mapped to the internal derived attribute 'uid' 2. the row flagged as 'AccountId' is actually mapped to external attribute 'uid' - this makes double mapping for the same external attribute and leads to inconsistencies 3. the internal attribute 'uid' is mapped to three distinct external attributes: this is problematic for synchronization I'd suggest you to make this LDAP mapping much simpler by removing all mappings involving any (internal / external) uid. Finally, please change the AccountLink to 'uid=' + username + ',ou=people,dc=digipro,dc=com' That should work. -- View this message in context: http://syncope-user.1051894.n5.nabble.com/An-odd-work-around-for-stubborn-derived-attributes-tp5706896p5706899.html Sent from the syncope-user mailing list archive at Nabble.com.
