Quite a bit if you are a Documentum user.
Documentum uses the user_name attribute of dm_user for uniquely identifying a user. This means that permissions and object ownership are also assigned to a user using user_name. Rajendra discusses various drawbacks of this design choice. One of the comments also indicates the reason why r_object_id wasn’t used as the key – the LDAP Sync job would sometimes delete and recreate the user object and creating a new object id in the process.
I have also been asked why wouldn’t one use the login ID as the key. I don’t have an authoritative answer but I have some thoughts around the difficulty of doing that in Documentum. First note that there is a user_os_name attribute as well as a user_login_name attribute. These are expected to be unique only in combination with user_os_domain and user_login_domain respectively. The attribute user_ldap_dn is relevant only when an LDAP server is being used. The population of these attributes is tied to the authentication mechanism in use, which could even be a custom plugin.
That leaves us with really one good option for the key – r_object_id, provided the object id wouldn’t change for a user. However, that’s not the case currently.
So why should you care? Check Rajendra’s post if you didn’t earlier when it was mentioned above. My experience has been more around presence of commas in the user name. It is not handled robustly across the platform. Even though problems are fixed in various service packs, they seem to be scattered across architecture layers. I shared an issue with the queue() call in another post.
More recently, I encountered another issue. In 5.3 SP5, if you enable dmcl trace in a WDK app (using wdk/dmclTrace.jsp) the log file name is generated using the name of the logged in user as a prefix. If the user name contains a comma, the portion of the name is stripped up to the comma. The resulting log file name is not accepted by some other piece of code, which apprently expects the log file name to begin with the user name. Yes, you can specify an explicit log file name but it tries to generate the log file mentioned above anyway.
The takeaway is to treat the user_name attribute like a key – use simple characters and if you have a choice maybe store the login id from your authentication source into the user name attribute. More likely you already have a deployment – in that case, arm yourself with the knowledge of these issues so that you can tackle them successfully.
Tech Fix 