nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Add controls on CIFS/Webdav access

mlagneaux

Hi,

I'm delopping on Alfresco 3.2r Community. I've changed the model so that a document has a property "status" that can take differents values (Draft, Approuved, Obsolete, …).

I've added evaluators on differents actions and now a document can't be modified when its status is Approuved or Obsolete without creating a new version of the document (all the documents are versionable) : those actions (for example update_doc) are hidden.

The problem is that the user can modify the document using CIFS or Webdav access. Is it possible to add controls on actions undertaken from a CIFS or Webdav access ?

For example, I have a document with Approuved status. Actions which can modify my document such as update_doc are hidden thanks to my evaluators. The user can only use edit_doc_offline action that will create a new version of the document. If the user open the document using CIFS access, he can modify it and save the modifications. Considering the status of the document, I don't want that to be possible.

Is it possible :
- to test the status of the document when it is opened under CIFS or Webdav, and open it with a read-only lock if the status is Approuved or Obsolete ?
- to configure CIFS so that documents are opened with read-only access and develop a new "action" (like actions provided by .exe files in CIFS repositories) that make it possible to open a document with a write access.

Thank you for your help.

Find more posts tagged with

Comments

mrogers

What you should probably be doing is changing the document's permissions based upon the value of the status rather than relying on the UI layers to enforce security for you. Then everything will work regardless of how you access content.

mlagneaux

Thank you for your answer. However, it raises other questions.

Is it possible to restrict the permissions granted to the owner of a document and to admin users ? For example, a document with Approuved or Obsolete status should not be modified by its owner or an admin.

When you're talking about "changing the document's permissions", do you think about the roles affected to users and groups for this document or is it possible to work at a lower level ?

mlagneaux

To solve my problem, I'm looking on DynamicAuthority.

First, I've made the following test
- I commented out permissionGroup WriteContent in permissionGroup Write. As a matter of fact, collaborators can't modify the content of a node by default ;

      <permissionGroup name="Write" expose="true" allowFullControl="false">
           <includePermissionGroup type="sys:base" permissionGroup="WriteProperties"/>
           <!– 
           <includePermissionGroup type="sys:base" permissionGroup="WriteContent"/>
            –>
      </permissionGroup>  
‍‍‍‍‍‍‍‍

- I've created a new dynamicAuthority which gives authority ROLE_WRITER_ACCORDING_STATUS according to the status of the document. This authority granted permissionGroup WriteContent.

<globalPermission permission="WriteContent" authority="ROLE_WRITER_ACCORDING_STATUS" />‍

Here is hasAuthority method of my class :

   public boolean hasAuthority(final NodeRef nodeRef, String userName) {
      System.out.println("WriterAccordingStatusDynamicAuthority#hasAuthority("+nodeRef+", "+userName+")");
        return AuthenticationUtil.runAs(new RunAsWork<Boolean>(){

            public Boolean doWork() throws Exception
            {
                boolean hasAuthority = true;
               
               // find its type so we can see if it's a node we are interested in
                QName type = nodeService.getType(nodeRef);
                
              // make sure the type is defined in the data dictionary
              TypeDefinition typeDef = dictionaryService.getType(type);

              if (typeDef != null)
              {
                 // Look for Content node
                 if (dictionaryService.isSubClass(type, ContentModel.TYPE_CONTENT)){
                    String name = (String)nodeService.getProperty(nodeRef, ContentModel.PROP_NAME);
                    System.out.println("WriterAccordingStatusDynamicAuthority#hasAuthority => Type CONTENT : "+name);
                    // Get the status of the node
                    String status = (String)nodeService.getProperty(nodeRef, CeaModel.PROP_STATUS);
                    
                    // If the status is different from draft or approval in progress, the authority is denied
                    if(!CeaModel.STATUS_DRAFT.equals(status) && !CeaModel.STATUS_APPROVAL_IN_PROGRESS.equals(status)){
                       hasAuthority = false;
                    }
                 }
              }
              System.out.println("WriterAccordingStatusDynamicAuthority#hasAuthority => "+hasAuthority);
              return hasAuthority;
                
            }}, AuthenticationUtil.getSystemUserName());
   }
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

It works as expected. It enables me to give WriteContent permission only if the status of the node makes it possible.

The problem is that this solution gives also WriteContent permission to Consumers.

I've tried to solve this problem like this :
- I've put back permissionGroup WriteContent in permissionGroup Write.
- I've created a new permission and the related permissionGroup :

      <permissionGroup name="WriteAccordingStatus" expose="false" allowFullControl="false" />

      <permission name="_WriteAccordingStatus" expose="false">
         <grantedToGroup permissionGroup="WriteAccordingStatus" />
      </permission>
‍‍‍‍‍‍‍

- I've modified permission _WriteContent. I've added a requiredPermission tag :

      <permission name="_WriteContent" expose="false">
         <grantedToGroup permissionGroup="WriteContent" />
         <!– Commented out parent permission check …
         <requiredPermission on="parent" name="_ReadChildren" implies="false"/>
         –>
         <requiredPermission on="node" name="_WriteAccordingStatus" implies="false"/>
      </permission>
‍‍‍‍‍‍‍‍‍

- I've commented out my globalPermission on authority ROLE_WRITER_ACCORDING_STATUS.

With this config, my permission _WriteAccordingStatus is never granted, so I thought that my users will not have WriteContent permission (thanks to requiredPermission tag). But, that's not the case.
I think I've missed something about permissions configuration.

How can I give WriteContent permission only to collaborators having a permissionGroup granted thanks to my dynamicAuthority ?

Moreover, I'm asking a question about admin users, coordinators and owner of a node. All of them have permission FullControl. In my final solution, I want to delete WriteContent permission for this user. My first solution is to define a new permissionGroup FullControlWithoutWriteContent which includes Collaborator permissionGroup (modified to solve my first problem) and to add remaining permissions.
Do you think about an easiest way ?

Thanks for your help.

mlagneaux

First, when using CIFS, a user open a document in write mode if he has Write permission (and not only WriteContent).

I've solved my problem doing this:
- I've modified my custom dynamicAuthority:
In hasAuthority method, I continue to check the status of the document and I also check that the user is Collaborator, Coordinator or Owner of the node.
Here is an example that I used :
http://forums.alfresco.com/en/viewtopic.php?f=47&t=17436&p=60903&hilit=dynamicAuthority#p60903

- In permissionsDefinition :
My dynamicAuthority grants Write permission.
Write permission only include WriteContent permission.
Collaborator don't include Write permission but directly WriteProperties permission.
I've defined a new permission CustomFullControl which includes Collaborator and all remaining permissions (except Write).
Coordinator permission now includes CustomFullControl permission and allowFullControl is set to false.
Last, in global permissions, ROLE_OWNER now grants CustomFullControl permission (instead of FullControl).

- In some JSP and some actions definitions, I've replaced permissionEvaluator on Write by permissionEvaluator on WriteProperties.

I've made some tests and it seems to work correctly.

Thank you for your help.