chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jay brown (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CMIS-365) Workbench tool 'cancel checkout' will delete the entire version series (data loss)
Date Thu, 05 May 2011 16:37:03 GMT

    [ 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

Mime
View raw message