Content Permission Scheme

.2.4.3 Content Permission Scheme

.2.4.3.1 General
The OFBiz CMS permission scheme is built around the ContentPurposeOperation table. It should be noted that the more general OFBiz Security permission utilities for CONTENTMGR override the Content permission scheme. If a user has _CREATE permission with CONTENTMGR, that will override the lack of CMS permissions. The key factor in determining whether or not a user has permission to perform a function is whether or not they possess the correct role and whether it is attached to the right Content entity.

.2.4.3.2 ContentPurposeOperation.roleTypeId
The roleTypeId field of the ContentPurposeOperation contains the RoleType value to be used in determining if a row of the ContentPurposeOperation passes the permission test. The roleTypeId must match the same field in a ContentRole entity that is also attached to the current Content (or an 'owner' - see below for more) and the current party. Or, like other fields, the value of roleTypeId could be _NA_, but it is rare that the roleTypeId field would have that value.

.2.4.3.3 ContentPurposeOperation.contentOperationId
The contentOperationId identifies the operation to be performed. Typically, it is a CRUD (CREATE, RETRIEVE, UPDATE or DELETE) variation. It is passed in by the requesting operation; it is not attached to anything like the roleTypeId.

.2.4.3.4 ContentPurposeOperation.contentPurposeId
The contentPurposeId optionally qualifies the condition under which a row in ContentPurposeOperation will pass the permission test. It contains a value from ContentPurposeType and the Content entity under test must have a related ContentPurpose record containing the contentPurposeId. Sometimes permission will be granted to a user if they possess a certain role, but only if the Content is being used for a certain purpose. For example, a clerk may have DELETE authority on Content entities whose purposes are something like GENERAL_INFO, but not for those which have a purpose of EVIDENCE or no qualifying purpose. The _NA_ value can be used for contentPurposeId.

.2.4.3.5 statusId and privilegeEnumId
statusId and privilegeEnumId are two ContentPurposeOperation fields that allow extra fine-tuning of the permission granting process. The statusId field is a foreign key into the StatusType table and privilegeEnumId into the Enumeration table. Usually, these are null or have values of _NA_. The statusId field is designed to allow permissions when a document is in one state (eg. DRAFT), but not other (eg. PUBLISHED). The privilegeEnumId allows permissions to be granted based on a user's authority 'level'. Unlike other fields in ContentPurposeOperation, privilegeEnumId matching is not done with an 'equals' test, but rather the privilegeEnumId value is tested to see if it is lower than the user's privilege. If it is, then it passes. This feature is useful in implementing subscription service with varying levels of service.

.2.4.3.6 Permission testing process
The process of permission testing is handled by the org.ofbiz.content.content.ContentPermissionServices.checkContentPermission service, which calls the checkPermission method. The general theme is that the quickest and easiest tests are run first.
A test is first made to see if a simple possession of a role is called for and if the user has that role.

The permission checker is going through some refactoring and this section of its documentation will be completed when that is done.