Documentum Content Server version 6.6 introduced a new feature, “Owner Minimum Permissions”, which allows the minimum permissions for owners to be set across the repository. These permissions would override any ACL based calculations – no ACL could reduce the effective owner permissions to be more restrictive than the ones set up in this configuration. Note that version 5.3 also has a similar behavior except that the owner minimum permissions are fixed (not configurable) – READ and all extended permissions other than EXTENDED DELETE.
It has been confirmed that this feature does not work as expected in version 6.6. At least for one operating system and database combination, these settings have no effect and the behavior is identical to 5.3. It is quite likely that this problem is not restricted to this one environment configuration.
Recently, I got curious about the mapping for Documentum project artifacts to repository objects. While this post shed some light on the subject, I wanted to see it for myself. Another driver was that I had not done a DAR install, rather I had installed the project from Composer. Here is what I found.
There is a dmc_dar object, named the same as the Composer project. It is versioned with each repeated install of the same project to the repository. The content type of the object shows up as jar but in reality it is an XML file. When I tried to open it as an archive it indicated that the file was corrupt. I was able to view the XML by opening it in an editor. It showed the resolution map for artifacts to object IDs.
One thing I suspect based on the referenced post above is that if I installed a DAR then the DAR file will show up as the jar content (correctly). I will have to explicitly get to page 1 of the content to view the XML.
I discovered another erroneous statement in Documentum Content Server 6.5 Fundamentals. This one relates to changing permissions on an object and occurs on Page 189. The statement in question is highlighted below.
It states that at least WRITE permission is required to replace the ACL assigned to an object.
The fact is that the ACL cannot be replaced without Change Permission extended permission. Further, BROWSE is sufficient among basic permissions and WRITE is not needed for this purpose. We cannot do much to an object without BROWSE permission so that’s the minimum needed. Of course, basic permissions higher than BROWSE (i.e. READ, RELATE, VERSION, WRITE, DELETE) will also work because they imply BROWSE permission.
It is pretty easy to verify with Webtop. Make sure that the effective permissions – labeled as Your Permissions, on the Permissions properties tab indicate BROWSE and Change Permission and you will be able to select a different ACL and save the object.
Therefore the correct statement should be: Replacing the ACL assigned to an object requires BROWSE permission and Change Permissionextended permission on the object.
EMC Documentum Content Server Version 6.5 Fundamentals has a big error about ACLs on page 134.
As highlighted in the figure above, it claims that ACLs assigned to folders are not used to define access to the folder. This is an incorrect statement. All you need to do to test this statement is to create a folder, alter permissions on it so that you have an effective permission of less than DELETE and then try to delete the folder. You will see that the deletion fails. Similarly, BROWSE permission is needed to look at a folder’s attributes and to retrieve it in query results.
Apparently, the intent is to explain the special usage of ACLs assigned to folders as mentioned in the last statement in the screenshot. However, that is in addition to and not instead of the regular effects of ACLs. In addition to controlling access to the folder object, the ACL assigned to it is used for enforcing folder security (if enabled), which restricts operations on objects linked to the folder. Further, when the default ACL mode for a Content Server instance is Folder, new objects created by that instance in the folder are assigned the same ACL as the one on the folder, by default. This is also loosely referred to as inheriting ACL from folder.
Once upon a time there were ACLs (Access Control Lists) in Documentum. All the internal artifacts used the term. Then they were renamed to permission sets, though internal references continued to use ACL as expected. So both the terms were prevalent.
In version 6.5 the Content Server Fundamentals guide doesn’t even mention the term permission set. It seems to be all ACL again. But wait, Composer uses permission sets liberally.
Does it really matter? Probably not. Then why mess with the terminology repeatedly? I am sure that there are better ways to improve the platform.
Webtop 6.5 SP2 User Guide describes versions as shown in the attached screenshot of page 34 below. In an apparent attempt to simplify the concepts it errs on the side of inaccuracy. The concerns are described and corrected below the image.
The version labels for Documentum objects are strings and not decimal numbers. They are strings even for the implicit version labels (automatically assigned by Content Server using a number-based format), some of which may be considered to be decimal numbers (1.2, 3.4, etc.). But the comparison ends right there. For example, 220.127.116.11 is not a decimal number but a valid version number. Decimal numbers don’t have multiple decimal points. “Increasing version number by a tenth” is also inaccurate because increasing the decimal number 1.9 by a tenth should give you 2.0 but a minor increment of the version number 1.9 gives you 1.10 as the new version. Further, 1.1 and 1.10 would be identical as decimal numbers but duplicate version numbers are not allowed in a version tree. Particularly, these last two points make the decimal analogy egregious.
This version label should be 18.104.22.168 since a branch is created by appending .1.0 to the parent version. There are always odd number of dots or points (not decimal points) in an implicit version label, so 5.0.1 is not even a valid implicit version number.