For many of our clients, having the ability to quickly and clearly see each version of a document is critical. Version viewing is especially important for our clients in regulated industries like our Pharmaceutical, Manufacturing and Nuclear Power clients. In Alfresco, the ability to quickly view a prior version’s rendition is a bit of a challenge.
First, let’s discuss version viewing from a business perspective before a more technical explanation later in the post.
As an example, let’s say we have a Procedure document that describes the cleaning process for a certain part of a nuclear plant. Like all other controlled documents, the ability to change this document is locked down. Changes must be reviewed and approved by the appropriate people in order to be made Effective at the plant. Here’s how the process works:
- We start with an already Effective document, say version 1.0. A change happens in the plant that affects this document. Jim, a document editor, makes changes to the document, checking it out and in a few times, creating Draft versions 1.1, and 1.2.
- Satisfied with his changes, Jim routes the 1.2 version for review and approval.
- During the approval process, a number of approvers look at the document to review the changes. Sally, a document approver, wants to be completely sure that she reviews every change made to the document. To do this, she would like to:
- View version 1.3 against the latest Effective version, 1.0 to see what has changed
- View Jim’s changes from 1.0 -> 1.1 -> 1.2 to see his thought processes during the editing process. Perhaps seeing this information will trigger something in Sally’s knowledge base that may find something that Jim missed?
- The approvers, satisfied with Jim’s changes, approve the document. The 1.3 version becomes 2.0, Approved and has an Effective Date set two weeks from the approval date.
- The users that rely on this document to clean the part associated with the procedure receive a training notification that a new Approved version exists. During the training process, each user should compare version 2.0 to 1.0 and make sure that he/she understands what has changed in the document.
Working with Versions in Alfresco Share vs. TSG HPI
Alfresco Share makes it very easy to see the latest version of the document. However, viewing prior versions is a bit of a challenge. While on the document details page in Share, you can access a Version History section. In this section, you can perform three actions on each version of the document:
- Revert to the version
- Download the version contents in the native format (ex: Word)
- View properties on the version
With very limited abilities to compare or view versions quickly, Sally and other reviewers will find their approval process very cumbersome. However, in HPI, users can:
- View each version’s PDF rendition in the browser quickly – no native version download required
- View versions side by side for comparison
- Send two versions to Workshare Compare to generate a redline differences document
To see Share and HPI in action, check out this short video:
As you can see, for anyone that cares about viewing more than the latest version of documents in Alfresco, utilizing HPI will make working with versions much easier.
Technical Explanation
For our technically inclined readers, we thought we’d include some explanation as to why working with versions in Alfresco is so difficult. Essentially, when a user views a document in Share, a PDF rendition is obtained from the transformation server and attached to the node as a rn:rendition child association. The problem comes in with Alfresco associations. Unlike other ECM systems we work with like Documentum and Hadoop where relationships are version to version, in Alfresco associations are node to node. Therefore, a node can only ever have one rendition. This is why Share only allows the user to view the latest version’s rendition, and must download the native contents for older versions separately.
So how do we get around Alfresco’s node-to-node association limitation? Luckily, Alfresco allows for content properties. We apply an aspect to documents viewable in HPI that contains a rendition property where the transformed PDF is stored, rather than using a child association. Unlike associations, properties are specific to each version and we can easily control the rendition for each version.