[ 
https://issues.apache.org/jira/browse/CMIS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029423#comment-13029423
 ] 

jay brown commented on CMIS-365:
--------------------------------

Thanks for the quick response Florian.   That helped me narrow this down 
further and we appear to have a bug on our side but that is not the whole story 
unfortunately. 

The allowable actions on our (non PWC)  versions show canCheckOut=true AND 
canCheckIn=true (so we will fix this - agreed) 

However for a PWC in our P8 system the allowable actions look like this:

<cmis:allowableActions>
...
<cmis:canCheckOut>false</cmis:canCheckOut>
<cmis:canCancelCheckOut>true</cmis:canCancelCheckOut>
<cmis:canCheckIn>true</cmis:canCheckIn>
...
</cmis:allowableActions>

So this is correct.

The thing that you mentioned about the getChildren not returning the PWC 
concerns me though because it seems we may have interpreted the spec 
differently.  
Our underlying repository does not file PWCs in folders, only real versions 
(the latest version).    We figured this was OK since the spec says that PWCs 
are not to be treated as real versions.  Thus we figured that only having real 
versions (the most current real version) show up in folder children feeds was 
ok.  Especially since you can tell from looking at the object's 
cmis:versionSeriesCheckedOutId   cmis:versionSeriesCheckedOutId that you are 
looking at the 'real version' and not the pwc. 

The spec says of getChildren 
If the Repository supports the optional “VersionSpecificFiling” capability, 
then the repository MUST return the document versions filed in the specified 
folder.
Otherwise, the latest version of the documents MUST be returned.

In section 2.1.9.4.1 it says of checkout
A new Document object, referred to herein as the Private Working Copy (PWC), is 
created.
o    The PWC NEED NOT be visible to users who have permissions to view other 
Document objects in the Version Series.  
o    Until it is checked in (using the checkIn service), the PWC MUST NOT be 
considered the LatestMajorVersion in the Version Series. 


Based on these two items it seems like the PWCs should not appear in the folder 
children feeds, since the latestVersion should appear and we are strictly 
directed that we must not treat PWCs as the latest version. 

What are your thoughts?

> Workbench tool 'cancel checkout' will delete the entire version series (data 
> loss)
> ----------------------------------------------------------------------------------
>
>                 Key: CMIS-365
>                 URL: https://issues.apache.org/jira/browse/CMIS-365
>             Project: Chemistry
>          Issue Type: Bug
>          Components: opencmis-workbench
>    Affects Versions: OpenCMIS 0.4.0
>         Environment: IBM P8 CMIS server implementation and latest OpenCMIS 
> workbench. 
>            Reporter: jay brown
>            Assignee: Florian Müller
>             Fix For: OpenCMIS 0.4.0
>
>
> While using OpenCMIS workbench:
> (Version: 0.4.0-SNAPSHOT / Build: 20110426-2129)
> Using the workbench to perform a 'cancel checkout' will delete the entire 
> version series in the following scenario (and perhaps others)
> (all steps performed with the workbench version above)
> (all steps include a refresh step in between to verify that object is current)
> -Create a doc. (as major) (refer to this as V1)
> -Checkout the doc.  
> -Checkin the doc.  (refer to this as V1)
> (you can now verify that there are two versions)
> -Checkout the doc. (refer to the working copy as 'pwc')
> -Cancel checkout on the doc. 
>   Performing a trace on this step shows that the workbench requests a delete 
> on the id for doc V2 instead of the id for the PWC.   This correctly results 
> in deleting the entire version series since there were no additional/optional 
> parameters specified, resulting in data loss that user would not expect.
> In our CMIS implementation (where this occurs) our PWC objects have a 
> separate/unique id than the version that preceded them.  Not sure if this is 
> related but it is certainly spec compliant. 
> If you would like to get access to the IBM server used in this scenario 
> please let me know.  It is the same one that we have used in the past for 
> interop work.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to