Sharing edits among users and sandboxes

[jack_jin]

I'd like to thank you for reading my long post ahead of time.  Hopefully it'll help the community solve the issue of file sharing across sandboxes.  Any suggestions is highly welcome and I'll try to answer any questions to the best of my ability.

What we have -
We've built a custom in-context editing platform on top of Alfresco's AVM repository for a few clients.  We're using a library of alfresco webscripts to interact with Alfresco, and we've chosen use the AVM platform to store content.
We're current using Alfresco 3.0C

Business case -
We want users to be able to share their edits without putting the file in a workflow.  Currently, our implementation reads and saves from the user's sandbox, and they're allowed to submit files into workflows.  But they can't see other user's changes, until the other user put the file in a workflow
In other words, We need users to look at each other's edits, and make further edits on top of that.

Possible solutions we've came up with -
1) Have a common sandbox - Basically, we can copy the user's edit to a common sandbox when the user checks his/her file in, then when another user tries to retrieve the file, he/she would get the file from the common repository, and see the first user's change
2) Look in other user's sandboxes
3) Have all the users read and write from the same sandbox at all times - have a workaround the whole sandbox implementation
4) Everytime the user checks in the file, we put it in a workflow - essentially branching the file out for everyone to read/edit.  But we don't like using workflows as a workaround to share files.

Our Attempts to implement common sandbox -
We came up with this design last week and we've made an attempt to implement it.
Design: Have a common sandbox that's shared among users, so when a user checks in a file, the file gets copied into the common sandbox.  Further gets of the file will be made from the common sandbox, unless the file is checked out by the user getting the file.

Changes to our webscripts (common sandbox implementation):
1) When we check-in a file, we make a copy of the file that's in the user's sandbox and throw it in the common sandbox
2) When we read a file, unless the file is checked out, we'll read from the common sandbox
3) When we checkout a file, we'll make a copy of the file from the common repository and put it in the user's repository
4) We'll keep the save the way it is - saving it to the user's sandbox.
This way, when the user checks in a file, the file gets read by all the other users.

Issue we're having -
Right now we're using the following code to copy the files around -

var newPath = crossRepoCopy.copy(avm.lookupNode(srcPath), avm.lookupNode(destPath), destName);‍

The problem with copying files around like that across repository is, the version history gets messed up and our workflow doesn't seem to start half of the time.  When copying files with the cross repository copy, the version history descriptor ID seems to be merged, such that now we have multiple version 1, and multiple version 2.  As if when we copy the files together, its version history just all merged together.

We also have our custom nodeCopy code, which reads the source node and overwrite the destination node with a save.  But we don't want to use use our custom nodeCopy code.  Is there another copy function we can use?

function nodeCopy(srcPath, destPath, destName) {

    var srcNode = avm.lookupNode(srcPath);
    var destNode = avm.lookupNode(destPath + "/" + destName);
    // Check to see if dest exists, if not, create it
    if(destNode == null) {
        var destParentNode = avm.lookupNode(destPath);
        destNode = destParentNode.createNode(destName, "wcm:avmplaincontent");
    }
    
    // For every aspect, attach it if it's not attached
    var srcAspects = srcNode.getAspectsSet().toArray();
    for(idx in srcAspects) {
        var currentAspect = srcAspects[idx];
        // Need to fix - need to extract aspect name from current aspect
        if(!destNode.hasAspect(currentAspect)) {
            destNode.addAspect(currentAspect);
        }
    }

    // Copy all the properties over
    for(idx in srcNode.properties) {
        var currentProperty = srcNode.properties[idx];
        destNode.properties[idx] = currentProperty;
    }

    // Copy over the content (include in mimetype and encoding)
    destNode.content = srcNode.content;
    destNode.mimetype = srcNode.mimetype;
    destNode.properties.content.encoding = srcNode.properties.content.encoding;

    destNode.save();

    return destNode.path;

}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Back to our business case -
We need users to be able to look at each other's edits, and make further edits on top of that.  Having a common sandbox makes sense, but is it the right approach to this issue?  Also, if we were to copy files around, what's the best way to do it in an AVM environment?

Thanks again.

Jack

[mrogers]

We at Alfresco like the idea of shared sandboxes and were seriously discussing implementing them for 3.1     However there were concerned about the sychnronisation issues which is why we paused from rushing ahead and implemementing them.

If you are a manager you can already peek in someone else's sandbox so that may be a solution and you are right that you can use workflow.

Copying files in AVM is probably not a good idea, its kind of going against the grain of what it is.    AVM supports the concept of layers so another approach may be a "shared" layer.

[laura_]

Hmm.. unless I'm missing a simple workaround, this sounds like a pretty big problem for a big WCM environment?  Because based on what I'm experiencing, here's how this plays out in real life:

Alice checks out a piece of web content, she edits it, and checks it back in when she's finished.  She does NOT want it to get published to Staging (i.e. the live site) yet, so she does not send it through a workflow.  Instead she just checks it in and considers it good for now. 

Bob wants to make an update the same piece of content later.  But when he checks out the content, he does NOT see Alice's updates.  Instead, he can only grab a copy of what's currently on the live site.  He cannot access or even see Alice's updates. 

This basically means that whenever a user finishes editing any piece of content, it MUST go to the live site – as nobody else can work on or even see it.  Is it correct this is the way Alfresco is designed to work?  Because in most WCM environments, content needs to be touched by plenty of different people before being pushed to the live site.  And all we really need is the ability for someone to edit a piece of content and have it saved as a Draft/WIP version that can be viewed on the "Draft" version of the website by others.

So unless I'm missing something obvious, I'm guessing some other people out must be hitting this, too?  In case anyone's curious, here's what I've tried to do to work around it:
1. Put all possible "editors" into the next step of the workflow – Self-explanatory, but not really practical
2. Create a shared sandbox that "draft" content gets checked into – Unfortunately, it sounds shared sandboxes like this isn't possible
3. Create a "layer" per the above post – Is there any documentation about this?  I don't see "layer" mentioned in any of the API docs (e.g. I searched the JavaScript docs for it and didn't find anything)
4. Others?

I could really use some help here….

[pyppe]

Hi.

We're struggling with the same problem as Laura_. We'd like users to be able to commit their changes into a common sandbox, where all users could see/modify the changes, WITHOUT the changes going into production yet. The problem of staging sandbox is, that once the changes are in there, you cannot select which of the changes will go into production (well, you can select which snapshot, but you cannot which resources).

Do you guys at the Alfresco have any kind of solution/approach of addressing this problem?

Thanks!

- Pyppe

[tommorris]

Hi there,

Under the hood the staging sandbox is a just another sandbox like any other and there's nothing to stop you from using the alfresco API to submit change-lists between sandboxes that aren't the nominated 'staging' sanbox, so you could introduce an intermediate sandbox. That way the sky's the limit, but this would require some careful coding.

I think there may be other out-of-the-box workaround techniques that you could use, but perhaps none exactly like what you're after:

1) Create a new user and then give other users access to this shared sandbox, to work on directly as a collaborative space. All authorised user can preview this sandbox, and preview URLs to the virtualised application super-imposed upon these files.

2) Submit files through a workflow. By default, a temporary intermediate sandbox is created for the submitted changelist. (Note: this sandbox appears as a layer ontop of the staging sandbox not the submitter's sandbox). The address of this sandbox can be shared by multiple user who have access to make changes, incidentally. If the workflow task is a pooled-task instead of a single-user task (which is very achievable), then users of the group that was declared by the workflow definition as the recipient, need not take-ownership of the task (to retain visibility to the group), but instead work on the task directly.

With these techniques orchestrating 'who works on what and when' and 'who can decide to submit and when' is tricky and requires business process rules.

Apart from serious efforts with the Alfresco API, we've had success using technique '2'.

Tom
http://www.ixxus.com