18 Replies Latest reply on Jun 25, 2010 5:08 AM by Ryan Rutan

    Feature Request - Collaborative Document Locking

    Ryan Rutan

      This feature is pretty straight forward; however, can be implemented a million ways under the sun.  Here is an implementation that might stir some thoughts and be feasible for next SBS release?


      • Currently, under Manage Collaboration, a user can assign other users as collaborators
        • However, if the owner changes this option, to just themselves, all other collaborators are lost.
      • In addition, I'm not 100% sure as I'm going from memory, but I think the collaboration options are only available to the creator of the document, and not all collaborators.


      Ideally, a solution to implement simple, yet effective Document locking:

      1. Manage Collaboration available on Binary documents and Collaborative Documents to all Collaborators specified on the document
      2. At any time, any collaborator should be able to come in and "lock" other collaborators from updating the document
        1. For Open Documents, this should be anyone in the Container with Write permissions
        2. For Collaboration limited documents, any of the defined users should be able to do this
          1. When this happens, the list of original collaborators should be maintained (perhaps an extended property on the document , or a full blown tracking table ), See 3.3
        3. This use-case is not applicable when the creator is the only collaborator
      3. Once a document has been locked
          1. Previous Open documents, anyone should be able via the Manage Collaborations action and see who has the lock (IM,PrivateMessage access to Lock User)
            1. if the community wants to squelch the lock, perhaps a certain threshold of abuse-like reportings on the lock itself can auto Unlock it without admin intervention
              1. If implemented, threshold should be configurable via container meta-data and not a system setting
                1. For Communities, this could be set via Admin Console, for Social Groups it should be configured somewhere in the "Social Group Details" and/or a new section that controls the various content behaviors in the container.  Projects should inherit from their direct parent.
            2. An appropriate Space/Container Admin should be able to remove the lock and return the document to the Previous state
                1. Since admins may not have inherent knowledge, this may be a driver for making a new state in the Collaboration Options and/or separate field that can be toggled on and off as needed to represent the locked state.
          2. Previous Collaboration limited documents, any of the specified collaborators should be able to see who has the lock (IM,PrivateMessage access to Lock User)
            1. Similarly, if all of the collaborators petition the lock on a document, or the "abuse-like" threshold (which ever is smallest), they can auto-Unlock it without Admin intervention
            2. Similarly, use-case 3.1.2, a respective Space Admin should be able to return the document to it's pre-locked state.
          3. This use-case is not applicable when the creator is the only collaborator


        In short, there are some opportunities here for a clean solution ... I'll let you guys respond with your thoughts on direction.  Please file this as a feature request, and we'll dig up more information/details as necessary.


        I'd be very interested to hear what the community has to say about this feature?  While I am an avid believer in Revision Management and Version Diffing, there are some people who are more comfortable with the Document Lock version of content contribution.  If there was an easy way to undo the "just you" setting in Manage Collaboration after a save...and allowing other users to access the controls as well, I think that would be "good enough".

          • Re: Feature Request - Collaborative Document Locking



            I am not familiar with this concept of document locking.  Are you saying that instead of standard versioning, you would want a user to be able to lock/own a section of the document and that section would have its own versions?  I think the new MS Office connector may accomplish much of what you are looking for.  This installs a plugin into Microsoft Office applications.  When you save the document, it will automatically updload your changes.  If there are multiple people editing this document simultaneously, it will see who changed what while the updates are happening and combine those changes.  For example, if you are working on Slide 2 of a PPT and your coworker saves a change made to slide 10, your version of the document will automatically update Slide 10 while allowing you to continue to work on Slide 2.  If this is not what you are looking for, please explain this a little further.


            For step 1, this seems straight forward.  Are you asking for a feature to allow any of the collaborators to be able to modify the list of collaborators.




              • Re: Feature Request - Collaborative Document Locking
                Ryan Rutan

                Document locking is more of a paradigm that exists in tools like Sharepoint called "Check-In/Check-Out".  For example, a Binary document is uploaded, and people are able to collaborate.  Our users have expressed the desire to be able to "temporarily" lock the document from being updated by anyone except them.  This more or less becomes a bottleneck for the collaborators to not contribute more content until that person has removed the lock.  When locked the document's most recent version is still visible to other users (and event changes by the lock-owner user?); however, they are not able to amend the document until the lock-owner removes the lock.


                I agree that the use-case is most likely available in the MS Office Connector; however, in the UI on the web is the desired location.  The simultaneous edits are nice (and even relevant); however, not what our users are looking for.  All they want to do is put the document in a state such that the other collaborators are aware that this document is being updated by someone (not Wiki), it indicates the Locked status in the UI...and the lock owner can "Check In" the changes when they are done.  By checking in the document, the collaboration status returns to its previous setting...where all collaborators selected can edit the document....at which point any of the specified collaborators can do the same thing as the other user.


                If this was configurable via a container property, that would be ideal, because I dont see this being something every container would want.  Hope this helps clarify the feature-request, comparable "Check-In"/"Check-Out" functionality in Sharepoint for the Web.  If you have another way of achieving this feature, please let me know.  I'm open to suggestions.

              • Re: Feature Request - Collaborative Document Locking

                Thanks Ryan for the great detail on this and everyone for your votes!


                Though I think I get where you're coming from, on the surface this sort of action seems a bit counterintuitive in a collaborative environment, at least during the content development stage when this action could be a bottleneck to the productivity of others. Can you share some more examples of when and why someone would want (and should be allowed) to lock the document for extended periods when they are not editing it?


                And, a few more specific questions to add to this:

                • When does this happen in the lifecycle of that document (for example, is this only once it is considered "completed")?
                • What is going on in the business that requires that it not be changed for a period of time?
                • Do the other collaborators know that the document should be considered locked but change it anyway (with the goal here to absolutely prevent that), or are they changing it because they don't know it shouldn't be edited?
                  • Re: Feature Request - Collaborative Document Locking
                    Ryan Rutan



                    Sadly, I am in agreeance with you.  I think in a collaborative environment that this should not be the case; however, the use-cases I am up against are two fold.

                    1. Dropping this platform into an environment, where there is an existing structure and processes.  The locking for this feature comes at the early stages of the document life-cycle (primarily).
                      1. It is meant to be a bottle-neck to force others to wait on that person and/or not continue work until complete.  I do not agree with it, but for some people the sense to pre-emptively lock vs. reactively merge is a big deal
                      2. This would also apply for binary documents where merging is not an option
                      3. The concept of a Check-In / Check-Out function seems to resonate with many folks of traditional means
                      4. This is why I wanted to configurable on a container-basis.  I dont think the masses should suffer this choice if it is desired by a few groups; however, the reverse is also the same.  Why should the few not be able to participate along-side the many?
                    2. The secondary use-case, which could be nice...is the option to say..."Done, no more editing on this document".  If people are collaborating together to come up with a specification document....they might want fast/fluid; however, when done they dont want people coming along and changing it along the way.  Perhaps this could be a way for them to say....Document is locked?
                      1. Personally, I think that when you get to the final version, you change the collaboration options to have a series of approvers at that point to approve the changes being made.


                    I'm not saying i dont like this feature, I'm just saying that in the heterogeneous environments that we all work....there is the need for flexibility.  If the concept of a "Check-In/Check-Out" will help bring us all together onto a single platform, then that would be ideal.


                    In response to the business question, I would say that in a global environment, it would be a way to make sure that all working on a specific document....all converge and understand that they should stop/regroup.  Perhaps the lock is like an away message, or an "announcement on the document"? (maybe it has an expire date?)  i.e. Ryan Rutan says...."Needing to re-evaluate components...could impact entire design...check back in 2 days, or watch document for updates" above the document in an info box or something. This (may) keep people from churning on a topic that could end-up invalidating their work over the next 2 days.   Maybe the feature is called "Document On-Hold"?


                    All the talk about this feature I've heard is to absolutely block editing of the document until the Document is released from the lock/hold.


                    Hope this helps stir up more discussion....interesting to see how we can bridge the gap between the two paradigms. =)

                    • Re: Feature Request - Collaborative Document Locking

                      Hi Olivia,

                      I was just browsing through and stumbled upon this thread.


                      In both our DAM and project collaboration systems -- not yet Jive -- we have files that are typically check-in/out functions wherein the files are locked from other's ability to download/edit.  This is a timed event that allows a 24hr window for a user to provide an edit.  Usually the files are:


                      • Already formed in that they are not being actively reformatted
                      • Contain production content that would be problematic if multiple versions were updated in a parallel track
                      • Do not require an approval process
                      • Are usually in a maintenance/update cycle

                      Some of our documents are locked multiple times per day by various users who are collaborating on them.  It's not so much about the losing collaborative abilities but politely restricting change of content in a short period.


                      In all cases each user is informed via the UI that the file is locked, checked out by such-n-such user, etc.

                      • Re: Feature Request - Collaborative Document Locking

                        Hi Olivia, I'm not sure if I understand your first question correctly, but for us this is of course only relevant once the document has been created.

                        An example that might answer your other two questions: User A downloads an excel file, opens it from his desktop and works on it in Excel for several hours. Meanwhile, user B starts the same process without being notified that the file is already being edited by user A.

                      • Re: Feature Request - Collaborative Document Locking
                        Ryan Rutan

                        Anyone who is interested in this thread, should vote on the Idea here:

                        Feature Request - Collaborative Document Locking (a.k.a. Document Check-Out)


                        The general premise that has evolved in this feature:

                        • Explicit Lock (with Message option) for Uploaded AND Collaborative by a User
                          • This prevents any further edits until lock is released
                          • Container Admin can remove lock
                          • Configurable Lock Timeout (24hr, 48hr, ...)
                            • Container Specific setting would be great
                        • Lock automatically goes away on Saving a New Version
                          • Explicit option to "cancel" lock (probably visible in the Lock Message if you are the Lock Owner)