Accessing Granular Permission Rights within Alfresco Share
People are sometimes surprised to find that although the Alfresco repository is architected to have very granular permissions, permissions assignments via the Share UI are based on Site roles.
Share Site Roles
The Share roles are as follows:
Interestingly, Alfresco did not include a Site Editor role for the Share UI, despite the fact that the Editor is a standard role used within the repository and is accessible in the Alfresco Explorer client. [Note the editor can change existing document but doesn't have the Upload/Create capability.]
Within the Alfresco Share client, assignment of permissions at the object level is possible using the Manage Permissions action dialog: Here we can see that permissions are assigned to the standard Share site groups. There is no way using this dialog to specify permissions for an individual.
The mix of using the same name, like 'Site Consumer' when referring to groups, privilege sets and roles also makes for some confusion on this dialog.
Role Assignments via the Share Repository Button
If permissions on objects can be enforced only by role, how can one restrict the viewing of some of the documents in the repository to only one or a few individuals? It can be done from the Explorer client. And, interestingly, it can also be accessed in Alfresco Share when browsing the Alfresco Repository, a feature which has been made available in Share.
When browsing the repository, a different page is displayed for setting permissions than the dialog we saw above which is used when browsing within a site Document Library. I'm not sure why Alfresco developers decided on this particular discrepancy in the design.
So setting permissions at a much more granular level is available within Share out of the box, but its location is a bit problematic because it isn't obvious that it is available.
Changing the Manage Permissions Action
To change the behavior of the Manage Permissions action to be the same as that available from the Share Repository button is not hard. To do that we need to modify three files. First we make folders in the tomcat/shared folder to hold the Share files that we will change.
In these files, we then edit the following line:
This line is changed to the following:
This same line needs to change once in each of
document-actions.get.config.xml and folder-actions.get.config.xml files,
and twice in the file documentlist.get.config.xml.
After adding these files, we stop and start the server.
Testing out the Manage Permissions Changes
Consider the case of a manager who has uploaded a new document, a document that he wants only Susan, a user with role Site Consumer, to be able to see it. (Although note that site managers will always be able to see all site document regardless of permission settings.)
After creating the document, click on the document action Manage Permissions. We'll see a screen that looks like the following:
Because, via inheritance of permissions in Share, all members of the Share site currently have access to see this document. Let's change the access permissions by doing the following:
Login as Mary
Now we can log out as the site manager and log in as as Mary, a Site Collaborator. Mary should have no permission to see this document.
Mary can navigate into the document library for the site and she does not see the document restricted to Susan.
One glitch does show up here. In the "Site Activities" Dashlet of the site, the document still shows up. See the top document in this list, BGESWFViewer.png below:
And when Mary clicks on the link to the document that she sees in this dashlet, she finds that she is restricted from accessing it:
Login as Susan, Site Consumer
When logging in as Susan, in the Dashboard for the site, we see references to the document in both the "Recently Modified Document" dashlet and also the "Site Activities" dashlet. But this is as it should be since Susan has rights to see this document.
On navigation into the Document Library, Susan is able to successfully open the document. She can open the document details page. If you notice when we assigned permissions to Susan above, we gave her permission as "Site Collaborator". In that case, Susan is able to edit the metadata for it.
People are sometimes surprised to find that although the Alfresco repository is architected to have very granular permissions, permissions assignments via the Share UI are based on Site roles.
Share Site Roles
The Share roles are as follows:
| Site Consumer | Read | |
| Site Contributor | Read, Upload | |
| Site Collaborator | Read, Upload, Checkout, Edit | |
| Site Manager | Full Control |
Interestingly, Alfresco did not include a Site Editor role for the Share UI, despite the fact that the Editor is a standard role used within the repository and is accessible in the Alfresco Explorer client. [Note the editor can change existing document but doesn't have the Upload/Create capability.]
Within the Alfresco Share client, assignment of permissions at the object level is possible using the Manage Permissions action dialog: Here we can see that permissions are assigned to the standard Share site groups. There is no way using this dialog to specify permissions for an individual.
The mix of using the same name, like 'Site Consumer' when referring to groups, privilege sets and roles also makes for some confusion on this dialog.
Role Assignments via the Share Repository Button
If permissions on objects can be enforced only by role, how can one restrict the viewing of some of the documents in the repository to only one or a few individuals? It can be done from the Explorer client. And, interestingly, it can also be accessed in Alfresco Share when browsing the Alfresco Repository, a feature which has been made available in Share.
When browsing the repository, a different page is displayed for setting permissions than the dialog we saw above which is used when browsing within a site Document Library. I'm not sure why Alfresco developers decided on this particular discrepancy in the design.
So setting permissions at a much more granular level is available within Share out of the box, but its location is a bit problematic because it isn't obvious that it is available.
Changing the Manage Permissions Action
To change the behavior of the Manage Permissions action to be the same as that available from the Share Repository button is not hard. To do that we need to modify three files. First we make folders in the tomcat/shared folder to hold the Share files that we will change.
In the document-details folder, we copy over the file document-actions.get.config.xml.
In the documentlibrary folder, we copy over the file documentlist.get.config.xml.
In the folder-details folder, we copy over the file folder-actions.get.config.xml.
In these files, we then edit the following line:
<action id="onActionManagePermissions" label="actions.document.manage-permissions" permission="permissions" type="action-link"></action>>
This line is changed to the following:
<action type="simple-link" id="onActionManagePermissions" permission="permissions" href="{managePermissionsUrl}" label="actions.folder.manage-permissions" />
This same line needs to change once in each of
document-actions.get.config.xml and folder-actions.get.config.xml files,
and twice in the file documentlist.get.config.xml.
After adding these files, we stop and start the server.
Testing out the Manage Permissions Changes
Consider the case of a manager who has uploaded a new document, a document that he wants only Susan, a user with role Site Consumer, to be able to see it. (Although note that site managers will always be able to see all site document regardless of permission settings.)
After creating the document, click on the document action Manage Permissions. We'll see a screen that looks like the following:
- click on Inherit Permissions to turn off that inheritance, and then
- click on Add User/Group and selecting Susan as the only user with permissions to see this document
- click on the save button to save the new permission settings
Now we can log out as the site manager and log in as as Mary, a Site Collaborator. Mary should have no permission to see this document.
Mary can navigate into the document library for the site and she does not see the document restricted to Susan.
One glitch does show up here. In the "Site Activities" Dashlet of the site, the document still shows up. See the top document in this list, BGESWFViewer.png below:
This seems to be a bug with this Alfresco dashlet to have allowed a restricted document's name to be seen by someone without permission. But, other than that, this seems to work pretty well.
And when Mary clicks on the link to the document that she sees in this dashlet, she finds that she is restricted from accessing it:
Login as Susan, Site Consumer
When logging in as Susan, in the Dashboard for the site, we see references to the document in both the "Recently Modified Document" dashlet and also the "Site Activities" dashlet. But this is as it should be since Susan has rights to see this document.
On navigation into the Document Library, Susan is able to successfully open the document. She can open the document details page. If you notice when we assigned permissions to Susan above, we gave her permission as "Site Collaborator". In that case, Susan is able to edit the metadata for it.
Thank you for publishing this.
ReplyDeleteTo achieve the same thing in Alfresco 4.x is a lot simpler. Do not edit the files mentioned in this article. The *.get.config.xml files don't exist anymore. All of the Share actions are now defined in tomcat/webapps/share/web-inf/classes/alfresco/share-documentlibrary-config.xml in the Document Library Actions config section. Search for document-manage-site-permissions action id. This is the action you'll want to modify, BUT NOT IN THIS FILE. You'll want to override the action definition.
To override, I cut the entire DocLibActions config element and pasted it into tomcat/shared/classes/alfresco/web-extension/share-config-custom.xml. (It seems like a sledgehammer move copying all of the actions, but I did it that way based upon my interpretation of http://wiki.alfresco.com/wiki/Web_Client_Configuration_Guide . There may be a better alternative.)
IMPORTANT: Add 'replace' attribute to the config element in the custom file so that it looks like below. This will ensure an override.
<config evaluator="string-compare" condition="DocLibActions" replace="true">
Now locate the document-manage-site-permissions action again in your custom file, and modify it as shown below.
<action id="document-manage-site-permissions" type="pagelink" icon="document-manage-permissions" label="actions.document.manage-permissions">
<param name="page">manage-permissions?nodeRef={node.nodeRef}</param>
<permissions>
<permission allow="true">ChangePermissions</permission>
</permissions>
<evaluator>evaluator.doclib.action.siteBased</evaluator>
</action>
That's it. Now restart alfresco, log in as Mary and test.