Avoiding overwriting other members' files

[Gil Heiman]

Currently, the system works that the last user to make changes to a file (or other objects) overwrites the previous versions. This will be resolved once we release the Versioning feature along with a Check In and Out mechanism. Prior to that we will introduce very soon our Conflict Bin which will store all previous versions so that you don’t lose them altogether.

There are several ways for now to work around this issue. You can have an assigned owner to a file by assigning a Task to him/her so that he/she knows they own it and only they can make changes. If another user wants to make some changes they can use the Discussion object to communicate to the owner that they want to have temporary ownership to it.

Otherwise, you can always rename the file and add it to the space under the different name. Regardless, when a team member is offline, they should keep in mind that other members, who are currently online, can be making changes simultaneously to the file. With this in mind, renaming the file would be a safe way to avoid overwriting other files once they get back online.

[Ket]

Avoiding overwriting is OK, but we face just the opposite problem - a file is being edited by owner and 2 more users at different moments. What is needed is that all three changes are saved. However, the changes of users 2 and 3 were reflected only in Collanos workspace while the original file remained unchanged on the owner's PC. What to do in the case when the changes need to be reflected in the original file? Example: we made changes in the workplace to a document to be e-mailed and finally attached the unchanged document!

[Gil Heiman]

All team member computers are mirror images of the workspace. Each member should have the exact updates as the others.
Remember that for now all replications (synchornizations) are from the originator of the content to other members. Member A needs to be online with members B and C in order for them both to get the latest Member A updates.

Member B cannot relay to Member C content that was received from Member A.
It must be directly from member A to every member.

This will change once we launch our new sync architecture that will allow relaying content from one member to another.

[Ket]

10x