If you are the guy/girl responsible for implementing permissions model for your business case you might find yourself in trouble. Let us imagine a scenario where business case states that certain users should be able to create new content but not be able to delete anything. That’s the easy one, you’ll likely say, and assign Contributor role to those users.
Lets check Contributor role definition from the Alfresco wiki:
Includes the Consumer permission group and adds AddChildren and CheckOut.
They will, by default own anything they create and have the ROLE_OWNER authority.
Hm, ROLE_OWNER looks suspicious:
“FullControl” granted to “ROLE_OWNER”
The owner (as defined by the ownable aspect, or, if the aspect is not present the node creator) is allowed all rights. This interacts with contributor for cm:content. They only need the right to create content in the default set up; all other rights come from the fact that they own the nodes they create.
To sum up the above, users that are just contributors can delete everything they create and you likely don’t want that.
So what can we do to fix this. There are two options and both have certain drawbacks.
Method 1: Edit permissionDefinitions.xml
Add somewhere near the top of the model/permissionDefinitions.xml file new permissionGroup definition and assign permissions by your needs:
<permissionGroup name=”FullWithoutDelete” allowFullControl=”false” expose=”false”>
<includePermissionGroup type=”sys:base” permissionGroup=”Read”/>
<includePermissionGroup type=”sys:base” permissionGroup=”Write”/>
<includePermissionGroup type=”sys:base” permissionGroup=”AddChildren”/>
<includePermissionGroup type=”sys:base” permissionGroup=”Execute”/>
<globalPermission permission=”FullControl” authority=”ROLE_OWNER”/>
and change it to:
<globalPermission permission=”FullWithoutDelete” authority=”ROLE_OWNER”/>
Notice that this will take away delete permissions from owners on ALL content in repository unless he is assigned proper permissions on space. Drawback: you mess with the core Alfresco configuration which may have unexpected consequences although I haven’t seen any with the above in a production setup at one of the clients.
Method 2: Ownable aspect
There is one other option the I think is better than messing with core alfresco configs. You can create a rule on top space that adds cm:ownable aspect to whatever you want. By default if ownable aspect i.e. cm:owner property is not present (which is the case when adding new content on clean config) then cm:creator property is used as owner.
So when you add content and rule gets triggered document receives ownable aspect with cm:owner property empty. This in effect removes delete permissions from cm:creator as he is no longer the owner and cm:owner is empty!
Note that adding aspects is exposed in rules wizard though you might need to modify web-client-config-custom.xml to expose cm:ownable aspect in it.
Drawback: it is inconvenient if you already have a huge repository – you likely won’t be able to apply this action to entire repository. However, I recommend it if you start with clean repository and you did proper planning.