DQL to API

Sometimes, all you have, is access to DA no other tool, and want to run some queries it can be very painful.
There is no way to execute multiple DQLs through DA unlike API commands.

Were you ever stuck in such a situation, well, don't waste your time trying. Just frame your DQLs to do the job, convert your DQL to API commands.


Step1: Frame the DQL:
Let me give two examples as the APIs for them will correspondingly change.

1. CREATE dm_group object SET group_name = 'abc'
2. UPDATE dm_group object SET description = 'abc group' WHERE group_name = 'abc'


If we had to run the above two queries on DA, we would have to run each one at a time. By converting these DQLs into APIs, it is possible to run them in one go. here is what we do:

Step2: Convert DQL to API
Just prefix the DQLs with the following API commands accordingly:
execquery,c,0 [or] execquery,c,F
execquery,c,1 [or] execquery,c,T

Hence our DQLs will look like this:
1. execquery,c,1,CREATE dm_group object SET group_name = 'abc'
2. execquery,c,0,UPDATE dm_group object SET description = 'abc group' WHERE group_name = 'abc'

NOTE: The parameter "1" or "T" in the API command signifies that the action being performed will create a new instance of an object in the repository, so all CREATE DQLs when converted to APIs. For all other Select or UPDATE operations the Parameter value "0" or "F" should be used.

Once the APIs are ready, you can run them in the API editor by choosing the "Script (multi-line) Entry" in the editor which allows execution of multiple API commands.

User Privileges & Client Capability

Managing User’s Client Capability, Privileges and Extended Privileges has always been a confusing task,and Documentum does not make life easy for the developers and the admins, specially when one has to do the mappings in the back-end through DQLs or APIs.
The numbers and business terms do not quite correlate and it can be very confusing and annoying to remember.

Another issue I would like to address here is the confusion between Client Capability and Privileges. As a simple rule of thumb, I always remember it this way,
   1. Privileges determines your control over the documentum objects.
   2. Client Capability determines you control over the instance of the documentum objects.
Simple enough I guess!!!

I would advice you be very careful with the Privileges and Capabilities you grant, as when you come up with your set of permissions and mappings, the repercussion are going to be dramatic.
So, here are the attributes, their numerical values and what they stand for. Once you know what these numbers and attributes stand for you can build your DQLs accordingly.

Client Capability:

Attribute	Client Capability	Numeric Value
client_capability	Consumer	1
	Contributor	2
	Consumer and Contributor	3
	Coordinator	4
	Coordinator and Consumer	5
	Coordinator and Contributor	6
	Consumer, Contributor and Coordinator	7
	System Administrator	8
	System Administrator and Consumer	9
	System Administrator and contributor	10
	System Administrator, contributor and Consumer	11
	System Administrator and Coordinator	12
	System Administrator, Coordinator and Consumer	13
	Contributor, Coordinator and Administrator	14
	All Capabilities	15

  Privileges:

Attribute	Client Capability	Numeric Value
user_privileges	None	0
	Create Type	1
	Create Cabinet	2
	Create Group	4
	Create Group and Type	5
	Create Group and Cabinet	6
	Create Group, Cabinet and Type	7
	SYSADMIN	8
	SUPERUSER	16

Extended privileges:

Attribute	Extended Privilege	Numeric Value
user_xprivileges	None	0
	Config Audit	8
	Purge Audit	16
	Config and Purge Audit	24
	View Audit	32
	Config and View Audit	40
	View and Purge Audit	48
	Config, View and Purge Audit	56

aa