folder with non-accessible parent (AtomPub)

[Florent Guillaume <fg...@nuxeo.com>]

Hi,

In some of our applications a given folder (a user's workspace) has
internally a parent that exists but is not accessible to the
particular user. Therefore we return no parent for it.

However Chemistry assumes that only the root can have no parent:
org.apache.chemistry.opencmis.client.runtime.FolderImpl.getParents
checks if it's not the root, and if not calls
org.apache.chemistry.opencmis.client.bindings.spi.atompub.NavigationServiceImpl.getFolderParent
which fails as there's not rel="up" link.

What do you think? Is what we do illegal according to the spec, or is
it just Chemistry that has to be patched?

Florent

-- 
Florent Guillaume, Director of R&D, Nuxeo
Open Source Content Management Platform for Business Apps
http://www.nuxeo.com   http://community.nuxeo.com

Re: folder with non-accessible parent (AtomPub)

["Huebel, Jens" <j....@sap.com>]

IMHO The spec is pretty clear on this (section 2.1.5.2):

"Every folder object, except for one which is called the root folder, MUST
have one and only one parent
folder. The root folder does not have a parent.²



The question for me is also what you gain by hiding the id of the parent
folder. The client knows that there must be a parent folder. You expose
the path anyway and provide the client in this way a mechanism to retrieve
the object using getObjectByPath(). I assume this results in a permission
denied exception. What additional information is in the id that is worth
to be hidden? And doesn¹t a file system behave also in a way that you see
the parent but don¹t have access?

Jens


On 13/03/14 09:03, "Florian Müller" <fm...@apache.org> wrote:

> Hi Florent,
>
> The spec doesn't really clarify this case.
>
> Here is my personal gut feeling:
> I think there should be an "up" link because every folder in CMIS must
> have a parent folder. So a client could expect an "up" link.
> Accessing the parent should throw a permissionDenied exception in your
> case, though. I guess that would also match the behavior of the other
> two bindings.
>
>
> - Florian
>
>
>
>> Hi,
>>
>> In some of our applications a given folder (a user's workspace) has
>> internally a parent that exists but is not accessible to the
>> particular user. Therefore we return no parent for it.
>>
>> However Chemistry assumes that only the root can have no parent:
>> org.apache.chemistry.opencmis.client.runtime.FolderImpl.getParents
>> checks if it's not the root, and if not calls
>> 
>> 
>>org.apache.chemistry.opencmis.client.bindings.spi.atompub.NavigationServi
>>ceImpl.getFolderParent
>> which fails as there's not rel="up" link.
>>
>> What do you think? Is what we do illegal according to the spec, or is
>> it just Chemistry that has to be patched?
>>
>> Florent
>

Re: folder with non-accessible parent (AtomPub)

[Florian Müller <fm...@apache.org>]

 Hi Florent,

 The spec doesn't really clarify this case.

 Here is my personal gut feeling:
 I think there should be an "up" link because every folder in CMIS must 
 have a parent folder. So a client could expect an "up" link.
 Accessing the parent should throw a permissionDenied exception in your 
 case, though. I guess that would also match the behavior of the other 
 two bindings.


 - Florian



> Hi,
>
> In some of our applications a given folder (a user's workspace) has
> internally a parent that exists but is not accessible to the
> particular user. Therefore we return no parent for it.
>
> However Chemistry assumes that only the root can have no parent:
> org.apache.chemistry.opencmis.client.runtime.FolderImpl.getParents
> checks if it's not the root, and if not calls
> 
> org.apache.chemistry.opencmis.client.bindings.spi.atompub.NavigationServiceImpl.getFolderParent
> which fails as there's not rel="up" link.
>
> What do you think? Is what we do illegal according to the spec, or is
> it just Chemistry that has to be patched?
>
> Florent