Understanding Compartment Security
A compartment is a name associated with a role. You specify that a role is part of a compartment by adding the compartment name to each role in the compartment. When a role is compartmented, the compartment name is used as an additional check when determining a user’s authority to access or create documents in a database. Compartments have no effect on execute privileges. Without compartment security, permissions are checked using OR semantics.
For example, if a document has read permission for role1 and read permission for role2, a user who possesses either role1 or role2 can read that document. If those roles have different compartments associated with them (for example, compartment1 and compartment2, respectively), then the permissions are checked using AND semantics for each compartment, as well as OR semantics for each non-compartmented role. To access the document if role1 and role2 are in different compartments, a user must possess both role1 and role2 to access the document, as well as a non-compartmented role that has a corresponding permission on the document.
If any permission on a document has a compartment, then the user must have that compartment in order to access any of the capabilities, even if the capability is not the one with the compartment.
Access to a document requires a permission in each compartment for which there is a permission on the document, regardless of the capability of the permission. So if there is a read permission for a role in compartment1, there must also be an update permission for some role in compartment1 (but not necessarily the same role). If you try to add read, insert, node-update, or execute permissions that reference a compartmented role to a document for which there is no update permission with the corresponding compartment, the XDMP-MUSTHAVEUPDATE exception is thrown.