Chemistry
  1. Chemistry
  2. CMIS-365

Workbench tool 'cancel checkout' will delete the entire version series (data loss)

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Not a Problem
    • Affects Version/s: OpenCMIS 0.4.0
    • Fix Version/s: OpenCMIS 0.4.0
    • Component/s: opencmis-workbench
    • Labels:
      None
    • Environment:

      IBM P8 CMIS server implementation and latest OpenCMIS workbench.

      Description

      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.

        Activity

        Hide
        jay brown added a comment -

        This is great. Just verified this works locally. So we can checkin and cancel checkout correctly against the IBM repos now. Thanks again Florian.

        Show
        jay brown added a comment - This is great. Just verified this works locally. So we can checkin and cancel checkout correctly against the IBM repos now. Thanks again Florian.
        Hide
        Florian Müller added a comment -

        The Workbench now provides a link to the PWC which allows check-in and cancel-check-out even if the PWC is unfiled.
        Additionally, the TCK now checks the allowable actions of checked out documents and PWCs.

        Show
        Florian Müller added a comment - The Workbench now provides a link to the PWC which allows check-in and cancel-check-out even if the PWC is unfiled. Additionally, the TCK now checks the allowable actions of checked out documents and PWCs.
        Hide
        Florian Müller added a comment -

        I will improve the Workbench UI and close the issue afterward.

        Show
        Florian Müller added a comment - I will improve the Workbench UI and close the issue afterward.
        Hide
        Florian Müller added a comment -

        I will improve the Workbench UI and close the issue afterward.

        Show
        Florian Müller added a comment - I will improve the Workbench UI and close the issue afterward.
        Hide
        jay brown added a comment -

        How would you like to mark this record then? I don't expect workbench necessarily to make the changes needed to fix this. I am ok with marking it resolved in this case unless you intend some fix on the client side.

        Show
        jay brown added a comment - How would you like to mark this record then? I don't expect workbench necessarily to make the changes needed to fix this. I am ok with marking it resolved in this case unless you intend some fix on the client side.
        Hide
        Florian Müller added a comment -

        You are right that the PWC need not be filed and that's actually not the problematic part.
        The "issue" is that the Workbench doesn't let you access any non-filed objects. So, in your case, the PWC is not visible through the Workbench and therefore you neither can check it in nor cancel the check out.

        I don't think the original document should accept check-in and chancel-check-out requests. The latter cannot be distinguished from a delete request...

        Show
        Florian Müller added a comment - You are right that the PWC need not be filed and that's actually not the problematic part. The "issue" is that the Workbench doesn't let you access any non-filed objects. So, in your case, the PWC is not visible through the Workbench and therefore you neither can check it in nor cancel the check out. I don't think the original document should accept check-in and chancel-check-out requests. The latter cannot be distinguished from a delete request...
        Hide
        jay brown added a comment -

        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?

        Show
        jay brown added a comment - 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?
        Hide
        Florian Müller added a comment -

        The CMIS Workbench hides and displays buttons based on the allowable actions. It doesn't check if the document is actually a PWC when the user hits the cancel-check-out button. It trusts the repository to provide valid allowable actions.
        The allowable actions in IBM P8 seem to be a bit mixed up. For example, after I create a document the allowable actions allow me to check it in and check it out at the same time - which is logically impossible.

        So my guess is that getChildren() returned the document and not the PWC after the check out. The document allowed an (impossible) cancel-check-out and the CMIS Workbench displayed the button. The AtomPub binding maps cancel check out and delete to the same resource and that's why it deleted the whole version series.

        I think the CMIS Workbench works correctly, but we could improve the UI in this area.

        Show
        Florian Müller added a comment - The CMIS Workbench hides and displays buttons based on the allowable actions. It doesn't check if the document is actually a PWC when the user hits the cancel-check-out button. It trusts the repository to provide valid allowable actions. The allowable actions in IBM P8 seem to be a bit mixed up. For example, after I create a document the allowable actions allow me to check it in and check it out at the same time - which is logically impossible. So my guess is that getChildren() returned the document and not the PWC after the check out. The document allowed an (impossible) cancel-check-out and the CMIS Workbench displayed the button. The AtomPub binding maps cancel check out and delete to the same resource and that's why it deleted the whole version series. I think the CMIS Workbench works correctly, but we could improve the UI in this area.

          People

          • Assignee:
            Florian Müller
            Reporter:
            jay brown
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development