AnsweredAssumed Answered

permissions incorrectly checked

Question asked by darioruizlopez on Aug 26, 2009

I have created a new role, "wfActor". Details on the definition are provided below. I have created folders with permissions granted to several groups. In concrete, the group "EFR Manager" has the role "wfActor" assigned, and the group "EFRspecialist" has NOT this role assigned. I have checked this fact both with the Alfresco client option "manage space users", and navigating through the node browser to the node corresponding to the folder. In both places I can see that the folders have the "wfActor" permission granted only to the group "EFR Manager"

But, if I execute this template this template

<#if document.hasPermission("WfActor")>
   This node has wfActor permissions
   This node has NOT wfActor permissions

on a document inside the folder with a user which belongs to the "EFRspecialist" group but does NOT belong to the "EFR Manager" group (that is, the user is supposed NOT to be granted the "wfActor" role on the document), I get the result :"This node has wfActor permissions". That is, the function hasPermission is answering that the user do have the "wfActor" role.
I have checked that the document inherits their permission from the folder and both in the "manage content users" and in the alfresco node browser. I have also checked that only "EFR Manager" users have this role assigned in the two ways, too.

In fact, these documents have a workflow which moves the document from this folder to another. For this reason, in order to execute the workflow, it is necessary that the executing user has delete permissions on the document, and add permissions on the destiny folder. Both "EFR Manager" and "EFRspecialist" groups have add permissions in the destiny folder, but only "EFR Manager" is supposed to have the delete permissions to do this. Precisely the "wfActor" is created for this, to grant the unavoidable permissions to perform the task. But the problem is that the "EFRspecialist" users are able to execute completely the workflow and move the files accordingly, while they should be denied the permission to do that, because they are not supposed to have the "wfActor" role.

But it looks like if precisely because the system is incorrectly assuming that they have this role assigned, the user finally gets to remove the file and execute the workflow.

Here is the definition of the "wfActor" permissions:
<permissionGroup name="WfActor" allowFullControl="false" expose="true" >
           <includePermissionGroup type="sys:base" permissionGroup="WriteProperties"/>
           <includePermissionGroup type="sys:base" permissionGroup="WriteContent"/>
           <includePermissionGroup type="sys:base" permissionGroup="DeleteNode"/>
           <includePermissionGroup type="sys:base" permissionGroup="ExecuteContent"/>

   <permissionSet type="cm:content" expose="selected">
      <!– More already existing groups.                                                       –>
     <permissionGroup name="WfActor" extends="true" expose="true"/>

<permissionSet type="cm:folder" expose="selected">
      <!– More already existing groups.                                                       –>
     <permissionGroup name="WfActor" extends="true" expose="true"/>

And here is an excerpt of the node browser corresponding to the document upon the template and the workflow is executed:

Assigned Permission   To Authority   Access
Contributor   GROUP_EFR process 20090813 EFR Manager   ALLOWED
Consumer   GROUP_EFR process 20090813 EFRSpecialist   ALLOWED
WfActor   GROUP_EFR process 20090813 EFR Manager   ALLOWED

Note: Here you can see that the actual name of the groups is preceded by the suffix "EFR process 20090813 ", but I have preferred to use the other name for the sake of clarity of the explanation.

In resume, it looks as if Alfresco permissions engine would be failing on this user defining role.

Has anybody look something like that?