Description Felix Botner 2019-01-09 11:22:01 CET

The handling of moves in samaccountname_dn_mapping and sync_from_ucs is working right now (except for computer/windowsdc's) but the code is absolutely obscure and hard to change.

Situation:

samaccountname_dn_mapping for ucsObjects always returns S4 DN's, except for a move in UDM, then a kind of frankenstein DN is return, with the S4 RID (cn=..) but the UDM ldap base.

Later in sync_from_ucs (if old_dn is set, so for moves) we check for a position_mapping on the mapping object and if found replace the UDM ldap base (which is returned from samaccountname_dn_mapping) with the S4 ldap base. But every mapping object has position_mapping attribute (we initialize these objects with an empty position_mapping attribute). 

Also the actual replace of the position_mapping seems to be wrong. It replaces the S4 part with the UDM part (it should be the other way around at this point because we search for the old object in samba, a UDM DN is not helpful here).

This makes it all very confusing, every change here is incredible difficult

What we should do:

Based on Arvid's patch from Bug #48362, we should always return a S4 DN for UCSObjects or UCS DN's for Non-UCSObjects in samaccountname_dn_mapping:

We should not implicit replace the ldap base in sync_from_ucs for moves if hasattr(self.property[property_type], 'position_mapping').

Position mapping for moves needs to be fixed too, but we don't have an idea for that yet.