Mailing-List: contact dev-help@chemistry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@chemistry.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
To: <Jorge.MARTIN-CUERVO@ext.ec.europa.eu>
Subject: Re: ACL question: isDirect attribute ignored
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 28 Mar 2014 18:11:34 +0100
From: =?UTF-8?Q?Florian_M=C3=BCller?= <fmui@apache.org>
Cc: <dev@chemistry.apache.org>
In-Reply-To: 
 <155713D1CB3F8C40B8D6425134607378807F3255@S-DC-ESTD03-B.net1.cec.eu.int>
References: 
 <155713D1CB3F8C40B8D6425134607378807F3255@S-DC-ESTD03-B.net1.cec.eu.int>
Message-ID: 
 <35bc2d81e0ded1205b2e57f9b613d47b-EhVcXl9JQQFXRwQFDQkEXR0wfgZLV15fQUBFBEFYXS9ZUF0WWlloB11LX15YLkQBVlxZQl5TUQw=-webmailer2@server04.webmailer.hosteurope.de>
User-Agent: Host Europe Webmailer/2.0

 Hi Jorge,

 Non-direct ACEs are usually managed somewhere else and cannot be 
 removed from the object itself. For example, if a ACE of a document is 
 (dynamically) inherited from a parent folder, all sibling documents must 
 have the same ACE. Removing such an inherited ACE only from one object 
 would require a negative ACE, which CMIS doesn't support.
 The intention of applyACL was to manage direct ACEs. Therefore, the 
 direct flag isn't needed. The Web Services and AtomPub data structures 
 can actually transport the direct flag, but only because the same data 
 structures are used for the other direction - from the repository to the 
 client. The Browser binding doesn't even provide the means to send the 
 direct flag from the client to server.

 Having said that, the repository can, of course, manipulate ACEs of 
 another objects when applyACL is called and if the repository's 
 permission model requires it. The repository is free to do whatever it 
 needs to do when the client tries to remove a non-direct ACE. You should 
 be able to detect that even without the direct flag by comparing the 
 current ACL with the list of remove ACEs sent by the client.


 - Florian


> Hello all,
>
> we have implementations of server and client CMIS applications.
>
> We consider the possibility to modify the inherited ACEs of the
> object, so the client applications are executing the applyACL to
> remove an ACE inherited (isDirect = false).
>
> The server side is reacting well but with the following code in the
> client side the flag isDirect is ignored:
>
> session.applyAcl(…);
>
> because in the class
> 
> org.apache.chemistry.opencmis.client.runtime.repository.ObjectFactoryImpl
>
>
> […]
>
>  PUBLIC Acl convertAces(List aces) {
>
>  IF (aces == NULL) {
>
>  RETURN NULL;
>
>  }
>
>  BindingsObjectFactory bof = getBindingsObjectFactory();
>
>  List bindingAces = NEW ArrayList();
>
>  FOR (Ace ace : aces) {
>
>  bindingAces.add(BOF.CREATEACCESSCONTROLENTRY(ACE.GETPRINCIPALID(),
> ACE.GETPERMISSIONS()));
>
>  }
>
>  RETURN bof.createAccessControlList(bindingAces);
>
>  }
>
> […]
>
> On the contrary If we use this other code it's working well.
>
> session.getBinding().getAclService().applyAcl(…)
>
> My question is if this is a mistake or was made on purpose?
>
> I was trying to find a some references in the CMIS specs 1.0 and 1.1
> about that subject but I couldn't.
>
> Many thanks.
>
> JORGE MARTIN CUERVO
>
>  EUROPEAN COMMISSION
>  DG TRADE
>  Unit A4
>
> CHAR 02/077
>  B-1049 Brussels/Belgium
>  +32 2 298 86 27
>  jorge.martin-cuervo@ext.ec.europa.eu [1]
>
>
>
> Links:
> ------
> [1] mailto:jorge.martin-cuervo@ext.ec.europa.eu