When good intentions go awry

So I was reading the Using Registered Tables vs Object Types design patterns discussion a few months back on EMC Developer Network.

I’m a Documentum old timer, so I was more comfortable using registered tables. Those of you who have used registered tables as lookups knows that its pretty straight forward. Create a table and then REGISTER it so that you can query against it using DQL. The hitch is that if you dont have privileges on the database (or the database is managed by a different group), you are highly dependent on them getting the table schema created with the appropriate permissions. Also, you are dependent on them to move the table and its values from one environment to the next OR you have to have strict version management of table population scripts. Anyways, I have followed this tedious process for many, many years.

After reading the design patterns discussion, I decided for my new project, I would try using object types for lookups. I was not too concerned about security on the objects given that the users were using Taskspace and would not have the ability to delete/manipulate the lookup objects.  I created custom type will null supertype, since I wasnt planning to have any content associated with them.  See Laurence Hart’s posting on using Contentless Objects as Lookups.

So I created quite a few custom types and created several hundred object instances of my custom lookup types.  It was very easy to change the value of the lookups and create new ones using DA or any other Documentum application.  Not only did I not have to worry about managing table population scripts, but I did not have to get DBA team involved, since creation of custom object types can be done using DA or DAB.  Everything work as expected.

Fast forward a couple of months and now we are ready to deploy our Taskspace application from DEV environment to testing environment.  Taskspace was designed to use the docapp archive feature of DAB to move form templates (components), processes, tabs, roles, and presets from one environment to the next.

Lo and behold, DAB does not support the archiving of contentless objects with null supertype.  There is no way to include object instances of this kind in docapp archive.  This makes sense at object type definition level; if custom type is not derived from dm_sysobject, then it doesnt have i_folder_id attribute, which means the object lives in what I like to call “La La Land”.   Application Builder supports the inserting of objects, but it assumes that the object resides in some folder.  Unfortunately, there is no “Insert Persistent Objects.”

I havent tried Composer to see if this is supported, but it really was a surprise to me that this feature was not in DAB.  In the end I had to remap the custom lookup types to be derived from dm_sysobject.  I hope my experience with this will prevent someone from going down the wrong path.

Controlling Application – Dirty Little Secrets

This might not be dirty little secrets, but I was recently stumped for a while trying to debug a problem in a custom application built by someone else. Let me describe the symptoms first:

1. ACL assigned to object gave me (group) DELETE permissions on the object
2. The attributes for the object were displayed as read-only
3. When viewing the permissions on the object, Webtop said that I only had READ permissions
4. When the extended privilege was set to superuser, I was able to edit the attributes – therefore, the data dictionary was set to read-only

After some investigation, I noticed that the a_controlling_app attribute was set to some custom value. I have seen this value being set before for Webpublisher and DCM application. I remember that this attribute allowed you to map control of an object with a specific application. In other words, you cant modify an object instance unless you are using the application that is specified in the a_controlling_app attribute. That makes sense, but where is the mapping defined?

Well, I had to go back to Content Server Fundamentals to find the answer:

“To identify to the system which objects it can modify, an application sets the application_code attribute in either the apiconfig or sessionconfig object when the application is started. (Setting the attribute in the apiconfig, rather than the session config, provides performance benefits.) The application_code attribute is a repeating attribute. On start-up, an application can set application_code to multiple application codes if users are allowed to modify objects controlled by multiple applications through that particular application.”

The issue here was that the client was using Records Management Administrator (RMA) to try to update the content (not the application defined by the a_controlling_app attribute). But why the READ permissions?

Again going back to Fundamentals, the content server will perform the following checks to grant the user his/her proper privilege:

1. The content server checks the a_controlling_app attribute of the SysObject.
2. If the attribute is blank, the user will be granted access based on the ACL; given that Docbase security is turned on.
3. If the attribute contains a value, it will be compared with the values in the application_code attribute of apiconfig or sessionconfig objects.
4. If there is a match, the ACL on the object will control the access.
5. If no matching code is found, the user will be granted access as defined in the default_app_permit attribute of the docbase_config. The default value of this attribute is READ. So, if the user uses a different application to access the SysObject, he will get READ access. Please, note that the user will get the most restrictive access to the object whichever is more: default_app_permit or ACL

Ah hah, now the secret is known. To solve this problem, I can either

1) set the a_controlling_app attribute to null (or dmc_rm) or

2) set default_app_permit to something higher – DELETE.

I recommend Option 1.  Option 2 sort of defeats the idea of having a controlling application.