Interesting Collaboration System Issues

For the past few months we've been working to develop a special collaboration system for news which allows our client to include captions when they post images to the news story.

We successfully implemented a solution which created a custom collaboration system which additionally keeps track of meta data for each file uploaded to the system.

In our initial release of this collab system, we discovered a problem.  In order to add captions to photos, you had to first upload them and commit the post.  The reason for this is that when you create a new post, there is no storage location until you hit the editSave method.  Our solution allows the user to preview the images which uploads them and then shows the photos to the user allowing them to add captions, etc.  If no storage location is present, however, the photos don't get uploaded.

I set out to solve this problem and ran into some interesting issues.

Let me set the stage, a method called www_editImage was created by the initial developer which handles posting the images and meta data related to the images and then returns the www_edit method.  This method was triggered by clicking the "Preview Images" button on the edit screen.

While this might seem like a decent solution, it was actually the cause of the problem.  To better understand this, you have to think about the way the Collaboration system works.  The collab system itself is responsible for adding new posts to itself.  Therefore, you are still within the scope of the collaboration system when adding a new thread.  When you try to call the editImage method when adding a new post, it complains that it can't find the editImage method in the collaboration system package which is correct because it's not there it's in the Post package (a similar problem existed for deleting images).

To remedy the situration, I removed the www_editImage method moving all of the logic into www_edit which only runs if certain form params are set.  That solved the problem of not being able to find an editImage method within the collaboration system.

The next problem to tackle was how to deal with non-existant storage locations.  The problem here was two fold.  First, in order to add images to a storage location before the editSave method was called, I needed to create a temporary storage location to upload the images.  This created a second problem in that if that temporary location was created and then never posted, there would be a situation where orphaned storage locations containing images would start building up on the client's server.

I solved the problem by creating a database table in which to store the storageId and creation time any time a new storage location is created in this fashion.  Additionally, I added a hidden form field containing the current storageId of the Post.  When the editSave method is finally called, if the Post is a new Post and the storageId is set, all of the photos uploaded are copied into the Posts storageId (created automatically when adding a new revision), the temporary storage location record is deleted from the database, and the temporary storage location is purged.

I also created a workflow activity which purges any orphaned storage locations after a predetermined amount of time.

Once I implemented all of this, I began testing.  This is where the fun started.  New posts worked fine, but any time I edited the post all of the meta data related to the images disappeared.

I knew that this was likely due to the fact that when a post is edited, a new revision of it is created, but I didn't know why.  After some digging, I finally found out.

Here's how it breaks down:

When www_editSave is called, it calls the superclass method which adds a new revision, copying all the images into a new storage location and then setting the new storageId as the storageId value for the new revision of the post.

Once that is finished, processProperitesFromFormPost is called on the new revision.  At the end of this method is the following statement:

delete $self->{_storageLocation};

I mistakenly thought that I would be able to get the storageId of the new revision in the www_editSave method.  This is not the case though.  After the superclass www_editSave method returns, you actually are returned to your original state which means I was still getting the storageId of the current revision and not the new.  This explained the behavior I was seeing.  Whenever I updated the data, the meta data was simply being updated for the current storage location.  After the commit, the new storage location was being refrenced and since none of the meta data was being updated for it, it seemed to have disappeared.

This was a valuable lesson in why you should always do any database updates in processProperitesFromFormPost rather than www_editSave.  However, when I moved my code I was seen the same results.

It turns out that even though processPropertiesFromFormPost was called on the new revision of the post, the current storage location was still stored in the object.  The final step to solving the problem was to move delete $self->{_storageLocation}; to the top of the procesPropertiesFromFormPost rather than the end.  I debated moving it to addRevision, but I wasn't sure if it would take correctly.  That is something I will probably test out sometime, but I think it should work.

This brings up an interesting question in my mind.  What else in WebGUI might be affected by this same problem?  At least I'll have a good idea of what the issue might and hopefully so will you.