Content management security (not reviewed)

In content management security must be more flexible than in more static applications. I am going to start the example of an online newspaper because I think relating discussion to something that you can relate to is a good idea. In this case, the will be multiple newspapers hosted and maintained by the same company and workers (not talking about editors and reporters, but system admins).

The system admins could have scope over all the newspapers or they could be assigned to just one paper. In the case that they have global permissions, those sysadmins could be made part of the ALLNEWSADMIN group and in SecurityGroupPermission, ALLNEWSADMIN group would be given CONTENT_ADMIN permission.

There ought to be a place for CONTENT_ROLE_ADMIN permission to handle selective admin privileges. I think this would be tied to the ownerContentId field of the Content entity. This would point to a Content record that topified the OSS News Journal paper. To that record, an entry in the ContentRole table could be made that tied it to the CONTENT_ROLE_ADMIN roleTypeId and the OSSADMIN group. I am not sure about the OSSADMIN groupId going in the partyId field of ContentRole. Upon looking at OFBizSecurity.hasRolePermission, there is a "hasEntityPermission" check that adds _ROLE to the action (BTW, this is inverted from the way that SecurityPermissions are defined and probably would not work), but I don't see how that would tie a role permission to a selected set of content. The rest of the hasRolePermission seems to use the partyId from a userLogin and I don't see how that would tie _ROLE type to a SecurityGroup.

I will investigate if no one removes the confusion for me.

Quick Public Mode

For Content Managment, there is another mode for giving public access (or role controlled) to content.

ContentPurpose table identifies content in more context oriented ways than the ContentType. ContentType has values like "ADVERTISEMENT", "MESSAGE", etc - not very specific. ContentPurpose (also has ADVERTISEMENT and ARTICLE, but it will get more specific) will have entries that are more specific, such as "FEEDBACK", "TO_BE_FIXED", etc.

ContentOperation identifies the operations that can be performed on a piece of content. Note that with Content, it is not just a matter of create, update and delete. A lot of CM permission control is about what content can be attached (via ContentAssoc) to other content, so someone may be able to add a note to content, but they could not change it. Perhaps only the author can change it or no one can because a change history is required. The ability to actually perform an operation is granted within service event code.

ContentPurposeOperation ties Operations to Purposes. There is an extra field, roleTypeId, which I asked for, but now I am not quite sure how it is applied. If roleTypeId equals "NA", then the operation is public for any Content that has the associated Purpose type attached to it. But if there is a roleTypeId such as "CONTENT_PROOF_EDITOR" in the record, then only someone who has that roleTypeId associated with their partyId in PartyRole could perform that operation on the content. How does that sound?

Content Specific Permissions

Perhaps the best test case for permission control is that case where a reporter wants no one but him or herself to an article while s/he is working on it, wants only his managing editor to see it when he is done, want the proofers to see when it is approved and then anyone can see it when it is published.

It seems that the Content.statusId field would be important in this case. If it were set to "DRAFT", then the control code would not let anyone but the person identified in the createdByUserLogin field to see it.

If the reporter wanted a colleague to see it while it was still in draft mode, then he could attach a ContentRole entity to it that has "CONTENT_FEEDBACK" roleTypeId and the colleague's partyId. Then that reviewer could attach Content with the PurposeType "COMMENT" to the document, but he could not change it.

The ownerContentId of this record would point to a Content record with contentTypeId="OWNER". There the reporter could grant permenant permission to this reviewer by attaching the same ContentRole record.

In the OWNER Content.ownerContentId field, another id could point to an owner with higher authority. If that owner gave "CONTENT_FEEDBACK" permsission to himself or someone else, then any reporter whose OWNER record pointed back to that supervisor would have that person as a reviewer and they would have no ability to revoke that privilege. This, of course, is just how I am saying the newspaper should be set up. There is nothing in the base CM code that implements this.

This is all I feel like doing right now. Anyone feel free to pickup where I left off or to change things. I will come back soon, I think --Al Byers