Uploaded image for project: 'Service Packs and Hot Fixes'
  1. Service Packs and Hot Fixes
  2. MNT-13006

Working Copy of a checked out document is editable by anyone

    Details

    • Type: Improvement
    • Status: Need Info (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 4.2.3
    • Fix Version/s: None
    • Component/s: Repository
    • Labels:
    • Environment:
      v4.2.3.13, RHEL, Oracle, Webdav
    • ACT Numbers:

      00269269

      Description

      Request is for change to functionality in v4.2.3 and newer.

      When a document is checked out by a user, the 'Working Copy' can be edited by anyone with permissions to document via webdav, which would appear to defeat the purpose.

      Consider the following situation:

      A space is in Alfresco, which has collaborator permission for everyone. User Alice creates a document, then checks it out for editing, creating the working copy in the same space.

      User bob looks in the space, and sees that the original document is locked, and that they don't have permission to edit it. However, they do have permission to edit the working copy, so can edit that inline, making changes to that which conflict with changes Alice is making.

      Isn't this the sort of thing that checking out a document is meant to prevent? The only way this seems to work as expected, is if the working copy is checked out to another space (possibly the user's home space). I assume that the Working Copy is just inheriting the permissions of the space, when it should really be settings its own permissions so that only the owner can edit it.

      The document was not under version control (I haven't tested to see if making it versionable changes things), and all tests were performed in the Web UI.

        Attachments

          Issue Links

            Activity

            Hide
            jpfi Jan Pfitzner added a comment -
            Show
            jpfi Jan Pfitzner added a comment - I think version 2.2 is meant: http://forums.alfresco.com/en/viewtopic.php?f=3&t=13548&p=44538#p44530
            Hide
            samuel.penn Samuel Penn (Inactive) added a comment -

            Yes it is, but I can't raise bugs against 2.2, so I have to point out that I'm using 2.2 and hope someone at Alfresco notices it and makes the required change (at least, that's what I've been told to do by Alfresco).

            Show
            samuel.penn Samuel Penn (Inactive) added a comment - Yes it is, but I can't raise bugs against 2.2, so I have to point out that I'm using 2.2 and hope someone at Alfresco notices it and makes the required change (at least, that's what I've been told to do by Alfresco).
            Hide
            pholmeshiggin Paul Holmes-Higgin [X] (Inactive) added a comment -

            This is behaving as designed, to allow on-blocking, collaborative working. Working copies can also be versionable, so the ful history of the working copy can be managed. A user can check out a document to a different location (space) where only they have edit permission if they want to stop anyone else having access.

            Show
            pholmeshiggin Paul Holmes-Higgin [X] (Inactive) added a comment - This is behaving as designed, to allow on-blocking, collaborative working. Working copies can also be versionable, so the ful history of the working copy can be managed. A user can check out a document to a different location (space) where only they have edit permission if they want to stop anyone else having access.
            Hide
            pholmeshiggin Paul Holmes-Higgin [X] (Inactive) added a comment -

            This issue either needs closing, or converting to an enhancement request (but with detail of the business use case that is being requested).

            Show
            pholmeshiggin Paul Holmes-Higgin [X] (Inactive) added a comment - This issue either needs closing, or converting to an enhancement request (but with detail of the business use case that is being requested).
            Hide
            samuel.penn Samuel Penn (Inactive) added a comment -

            It would appear that we have a disagreement on how it should work. The user expectation (in our experience) is that the working copy should not be editable by anyone else. If the system behaves differently to expectations, then users get confused.

            Checking it out to a home folder is possible (and accepted as a workaround in the workshops where this was raised), though there is an issue of not being able to easily track where the working copy is from the original (in case an admin user needs to check it back in, because the lock owner has gone on holiday), and also in not being able to see who has it checked out from the original (the owner of the lock happens to be set as the modifier, which is unexpected and though it gives the necessary information, it's not obvious to the user that this is where to look for it).

            So, we don't have a specific business use case other than it reduces user confusion in general (admittedly, users seemed to be confused about the entire concept of having a distinct working copy anyway, which was compounded by the fact that the copy wasn't private, but that's a different issue).

            Show
            samuel.penn Samuel Penn (Inactive) added a comment - It would appear that we have a disagreement on how it should work. The user expectation (in our experience) is that the working copy should not be editable by anyone else. If the system behaves differently to expectations, then users get confused. Checking it out to a home folder is possible (and accepted as a workaround in the workshops where this was raised), though there is an issue of not being able to easily track where the working copy is from the original (in case an admin user needs to check it back in, because the lock owner has gone on holiday), and also in not being able to see who has it checked out from the original (the owner of the lock happens to be set as the modifier, which is unexpected and though it gives the necessary information, it's not obvious to the user that this is where to look for it). So, we don't have a specific business use case other than it reduces user confusion in general (admittedly, users seemed to be confused about the entire concept of having a distinct working copy anyway, which was compounded by the fact that the copy wasn't private, but that's a different issue).
            Hide
            hdann Helen Dann (Inactive) added a comment -

            Moving this to an enhancement. Customers would like to have configurable behaviour since for at least two, the current behaviour is counterintuative to their users.

            Show
            hdann Helen Dann (Inactive) added a comment - Moving this to an enhancement. Customers would like to have configurable behaviour since for at least two, the current behaviour is counterintuative to their users.
            Hide
            jsoria Jennie Soria added a comment -

            Based on testing in Share UI, WebDav Alfresco Enterprise v4.2.3(.13 r91949-b103) schema 6061

            If both users A and B are members of site

            • User A checks out a document via Alfresco Explorer which creates a working copy
            • Alfresco Explorer shows user A as owner of the lock
            • User B cannot edit/save the working copy via Share UI
            • User B maps Alfresco with WebDAV
            • If user B opens the original/master document via WebDAV he is not allowed to edit/save it
            • If user B opens the working copy via WebDAV he can edit/save the working copy

            Actual behavior:

            • If the non-owner has permissions to the original file, then yes, the working copy can be updated by the non-owner via webdav, but not via Share.
            • User B can edit/save the working copy via WebDav

            Requested behavior:

            • User B should not be able to edit/save the working copy via WebDAV
            • Possible user actions on working copies should be aligned across all Alfresco Explorer interfaces (Share, Alfresco Explorer, WebDAV)
            Show
            jsoria Jennie Soria added a comment - Based on testing in Share UI, WebDav Alfresco Enterprise v4.2.3(.13 r91949 -b103) schema 6061 If both users A and B are members of site User A checks out a document via Alfresco Explorer which creates a working copy Alfresco Explorer shows user A as owner of the lock User B cannot edit/save the working copy via Share UI User B maps Alfresco with WebDAV If user B opens the original/master document via WebDAV he is not allowed to edit/save it If user B opens the working copy via WebDAV he can edit/save the working copy Actual behavior: If the non-owner has permissions to the original file, then yes, the working copy can be updated by the non-owner via webdav, but not via Share. User B can edit/save the working copy via WebDav Requested behavior: User B should not be able to edit/save the working copy via WebDAV Possible user actions on working copies should be aligned across all Alfresco Explorer interfaces (Share, Alfresco Explorer, WebDAV)

              People

              • Assignee:
                repositoryteam Repository Team
                Reporter:
                samuel.penn Samuel Penn (Inactive)
                My watchers:
                Andrew Hunt, Florence Pagani, Jan Pfitzner, Jan Vonka, Jennie Soria, Samuel Penn (Inactive), Seng Liaw
              • Votes:
                7 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated: