Documentum dm_user.client_capability
client_capability is the ceiling a client application (DA, Webtop, D2, CARA, and the rest) is willing to expose for that user. It is not r_accessor_permit (object ACL 1–7) and it is not user_privileges (the create_type / sysadmin / superuser bitmask). Three separate controls.
Values
| Int | Name | What the client allows |
|---|---|---|
| 0 or 1 | Consumer | Search, view, copy. Forward a workflow task. |
| 2 | Contributor | Consumer, plus create and delete documents and folders, modify virtual documents, checkout and checkin, start a workflow, and perform workflow tasks. |
| 3 | Coordinator | Contributor, plus view hidden documents; create and modify virtual documents. |
| 4 | System Administrator | Coordinator, plus manage Content Server, the repository, and users/groups — as the client presents those admin surfaces. Still distinct from user_privileges superuser. |
0 versus 1
A stored 0 is not “blank” or “no capability.” In the repository, 0 behaves as Consumer. Treat 0 and 1 as the same role when you dump or audit users.
This is not the ACL
The integer does not replace object security. A Consumer who has Delete on a SysObject still only gets whatever that client’s Consumer UI offers; the extra ACL does not unlock Contributor menus. Conversely, a Coordinator still needs the object permit (and folder security) for each action the UI does show. See ACL permits 1–7.
DQL
Current session user:
select user_name, client_capability
from dm_user
where user_name = USER
Everyone at Contributor or above, with the privilege bitmask next to it so you do not confuse the two:
select user_name, client_capability, user_privileges
from dm_user
where client_capability >= 2