Bug for 5.0 +++ This bug was initially created as a clone of Bug #58261 +++ For objects with "+" in the DN (uid=test_user,cn=users,ou=+1,dc=ucs,dc=test) we we save them in the LDAP like "uid=test_user,cn=users,ou=\2B1,dc=ucs,dc=test". When we use the oxDeputyPermissionGivenTo property we save the DN of a user to it. When we use the encoding with "\2B" (as it is in LDAP) it gets automaticylly converted by UDM to "uid=test_user,cn=users,ou=\+1,dc=ucs,dc=test". Later when the ox-connector sets the permissions it uses the DN for a search in the database and can't find the correct entry due to the mismatch "\+" vs "\2B". Most likely this applies to other special character in DNs. This might be connected to display issues in the UMC where the "Stellvertreter" field is visually empty. We debugged it directly in a python shell as follows: >>>from univention.udm import UDM >>>user_mod = UDM.admin().version(2).get("users/user") >>>fupo_user = user_mod.get_by_id("fupo_user_isOxUser_01") >>>fupo_user.props.oxDeputyPermissionGivenTo = [['uid=user_isOxUser_02,cn=users,ou=\\2B1,dc=ucs,dc=test', '02400', '02440', '1']] >>>fupo_user.save() >>>fupo_user = user_mod.get_by_id("fupo_user_isOxUser_01") >>>fupo_user.props.oxDeputyPermissionGivenTo [['uid=user_isOxUser_02,cn=users,ou=\\+1,dc=ucs,dc=test', '02400', '02440', '1']] whereas ldapsearch results in "\2B": # univention-ldapsearch -LLL uid="fupo_user_isOxUser_01" dn oxDeputyPermissionGivenTo dn: uid=fupo_user_isOxUser_01,cn=users,ou=\2B1,dc=ucs,dc=test oxDeputyPermissionGivenTo: uid=user_isOxUser_02,cn=users,ou=\+1,dc=ucs,dc=test |:$:| 02400 |:$:| 02440 |:$:| 1 # univention-ldapsearch -LLL uid="user_isOxUser_02" dn oxDeputyPermissionGivenTo dn: uid=user_isOxUser_02,cn=users,ou=\2B1,dc=ucs,dc=test
univention-directory-manager-modules.yaml 1db5a9cc6fd5 | Bug #58261: Do not normalize DNs in attributes. This led to different string representations between attribute values and the actual DNs of objects, causing problems in UMC not finding the already set items in ComboBoxes and made lookups error prone when using different data structures than LDAP (e.g., database cache). univention-directory-manager-modules (15.0.29-3) 1db5a9cc6fd5 | Bug #58261: Do not normalize DNs in attributes. This led to different string representations between attribute values and the actual DNs of objects, causing problems in UMC not finding the already set items in ComboBoxes and made lookups error prone when using different data structures than LDAP (e.g., database cache). ucs-test (10.0.24-23) 1db5a9cc6fd5 | Bug #58261: Do not normalize DNs in attributes. This led to different string representations between attribute values and the actual DNs of objects, causing problems in UMC not finding the already set items in ComboBoxes and made lookups error prone when using different data structures than LDAP (e.g., database cache). univention-directory-manager-modules.yaml f8a447d56146 | Bug #58312: New package version univention-directory-manager-modules (15.0.29-4) 23b3963f294d | Bug #58312: Fix py2 incompatible code from cherry-pick
Code review: OK YAML: OK Tests: Exist, pass, OK Changes itself: ~OK, strictly speaking this would require a data migration. But it is only necessary in case such objects exist (e.g., an object below a ou=+1) and is referenced with its DN somewhere else. This is most probably not the case, as the problems would have shown up before: * Problems in users (primary group) * Problems in groups (users) * ... (e.g., portal objects like tiles in categories) And even then it may only be a problem if you want to work with these values. Maybe you can even get away with those values being in a slightly misaligned format. So, in conclusion, I do not think we need a data migration for every customer.
<https://errata.software-univention.de/#/?erratum=5.0x1277>