Re: Services without a clearly defined Permission Mapping filter

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

 Hi Jaime Porras,

 The Permission Mapping is a hint for sophisticated clients and not 
 necessarily the whole truth. A repository can have individual rules for 
 each object that overrule the Permission Mapping.
 A best practice for clients is to check the Allowable Actions of an 
 object and if they allow the action, just try it and catch a potential 
 exception.
 Sophisticated clients that want, for example, disable buttons in a user 
 interface could combine the Allowable Actions and the Permission 
 Mapping.

 Since the specification does not cover the cases you have mentioned, I 
 can only provide my personal view.

 Re 1.1)
 If the Allowable Action "canGetChildren" is set, the user can call 
 getCheckedOutDocs for this folder.

 Re 2.1)
 createDocument and createDocumentFromSource follow the same rules. To 
 create a document from another document the user must additionally have 
 read permissions (Allowable Actions "canGetProperties" and 
 "canGetContentStream") on the source document.

 Re 2.2)
 The spec doesn't provide any help for clients. They have to try it and 
 catch a potential exception.

 Re 2.3)
 If an object is visible to a user (Allowable Actions 
 "canGetProperties"), the user can also get the Allowable Actions.

 Re 2.4)
 If and which renditions are visible to a user is repository specific. 
 There could be complex permission and rule sets, that are invisible 
 through CMIS.
 If the repository doesn't want to expose renditions to a specific user, 
 it should return an empty list.

 Re 3)
 A query should return all objects that a user could also retrieve via 
 getObject().
 In short:
 If getObject("id123") returns a document object, then "SELECT * FROM 
 cmis:document WHERE cmis:objectId='id123'" should return the same 
 document object.

 Re 4.1 an 4.2)
 The latest object of a version series is just another object and 
 covered by "canGetProperties".


 - Florian



> Hello,
>
> Following are listed some services without a clearly defined 
> Permission
> Mapping filter, based on CMIS 1.0 (
> 
> http://docs.oasis-open.org/cmis/CMIS/v1.0/errata-01/os/cmis-spec-v1.0-errata-01-os-complete.doc)
> and CMIS 1.1 (
> http://docs.oasis-open.org/cmis/CMIS/v1.1/cos01/CMIS-v1.1-cos01.pdf )
>
> 1) Navigation Services
>
>     1.1) getCheckedOutDocs
>         Description: Gets the list of documents that are checked out 
> that
> the user has access to.
>
>         I see two options:
>         1.1.1) Granted to any authenticated user. (The result will be
> already filtered by the user permissions related with the objects)
>         1.1.2) If a folder is specified then apply the Permission 
> Mapping
> canGetDescendants.Folder
>         My guess is to go for the option 1.1.2.
>
> 2) Object Services
>
>     2.1) createDocumentFromSource
>         Description: Creates a document object as a copy of the given
> source document in the (optionally) specified location.
>         My guess is that the Permission Mappings to apply would be:
>         2.1.1) Always canGetProperties.Object
>         2.1.2) If the object has a content stream, also apply
> canViewContent.Object
>         2.1.3) If the optional folder is specified, also apply
> canCreateDocument.Folder
>
>     2.2) createPolicy
>         Description: Creates a policy object of the specified type
>         2.2.1) CMIS 1.0
>             There is no Permission Mapping defined for this operation 
> in
> CMIS 1.0.
>             My guess is to apply the nearest permission mapping:
> canCreateDocument.Folder
>         2.2.2) CMIS 1.1
>             The permission mapping defined is canCreatePolicy.Folder.
>             NOTE: In openCMIS 0.9.0-beta-1 this permission mapping is 
> not
> included neither in 
> org.apache.chemistry.opencmis.commons.enums.Action or
> in org.apache.chemistry.opencmis.commons.data.PermissionMapping
>             See JIRA: https://issues.apache.org/jira/browse/CMIS-662
>
>     2.3) getAllowableActions
>         Description: Gets the list of allowable actions for an Object
>         My guess is that this should be granted to any authenticated 
> user.
>
>     2.4) getRenditions
>         Description: Gets the list of associated Renditions for the
> specified object. Only rendition attributes are returned, not 
> rendition
> stream.
>         The related Permission Mapping was removed in the errata 
> version of
> CMIS 1.0.
>         My guess is to apply canGetProperties.
>         NOTE: In openCMIS 0.8.x and 0.9.0-beta-1 this permission 
> mapping is
> included in org.apache.chemistry.opencmis.commons.enums.Action but 
> not in
> org.apache.chemistry.opencmis.commons.data.PermissionMapping
>         See same JIRA as in 2.2.2.
>
> 3) Discovery Services
>
>     3.1) query
>         Description: Executes a CMIS query statement against the 
> contents
> of the Repository.
>         Based on the definition, all authenticated user is granted to 
> query
> all query-able.
>         In our implementation, we will restrict the output to all
> query-able objects whose ACL has at least one ACE for the current 
> user. In
> this way, we can be sure the user can use all the returned objects in 
> some
> way.
>
> 4) Versioning Services
>
>     4.1) getObjectOfLatestVersion
>         Description: Get a the latest Document object in the Version 
> Series.
>         My guess is to apply canGetProperties.Object
>
>     4.2) getPropertiesOfLatestVersion
>         Description: Get a subset of the properties for the latest 
> Document
> Object in the Version Series.
>         My guess is to apply canGetProperties.Object
>
> Would you mind to clarify if my guessings are correct?
>
> Thank you very much in advance.
>
> Regards,
>
> Jaime Porras.