A key part to any document management system is the ability to version documents. In most cases, the ability to provide minor (1.1 to 1.2), major (1.0 – 2.0) versioning, view version comments, and revert to previous versions is acceptable. However, for controlled documents tied to regulatory mandates, more functionality, specifically in regards to versioning, is required. We’ll review core versioning capabilities covered exposed within Alfresco Share, but also outline additional ways in which to leverage versioning within the Alfresco platform.
Versioning in Alfresco Share
By default, content must have the “versionable” aspect applied to allow versioning of documents. The easiest way to enable this for all documents in a repository is to designate the “versionable” aspect as mandatory for cm:content, hence all inherited types would also be considered versionable. Versioning of documents can be configured to occur either each time a document is updated, or even if metadata is updated.
Alfresco Share exposes basic versioning functionality that the platform provides. Users can check in and check out documents, and create major and minor versions. Users are also able to view the complete version history, properties of a document (including version comments) and who updated the document. If required, you can revert the document, which creates a new version of document. On a document by document level, users can also control whether the “versionable” aspect is applied to a document as well.
Versioning for Controlled Documents
When working with documents in regulated environments industries such as pharmaceuticals or utilities, versioning of documents, particularly controlling which versions of documents users can view becomes increasingly important. Versioning requirements may include the following:
- Ability to search for current and previous versions of documents via a search interface.
- Modifying attributes on older versions of documents, without making it the current version.
- Various ACLs applied to different versions of a document, depending on the version label.
In regulated industries, consumers of documents should only be able to see the effective version of a document. In the meantime, the latest version of the document may be in the process of being routed for approval. Consumers should never see these minor versions being edited, routed and approved. Once the approved document is made effective, Consumer searches would return the new effective version. Some Consumers may be able to see the old effective versions (now in a superceded state), but this depends on security. A typical routing / approval in which this may be the case is as follows:
So although Alfresco “out of the box” interfaces such as Alfresco Share Explorer expose versioning functionality, it does not provide all capabilities within the Alfresco repository that is available. For most users of Alfresco Share, it probably doesn’t need to be. Traditional ECM interfaces which expose ALL document management functionality tend to be intimidating for the typical user.
Exposing this functionality can be leveraged via the direct Alfresco Repository Java API. In our case, by deploying our OpenContent web services layer as an Alfresco Subsystem, we were able to leverage the the Alfresco Java API directly and provide these versioning features through our services. HPI, which leverages OpenContent services, can now provide this functionality in both Documentum and Alfresco. This approach makes communication into the repository much more efficient for our services framework.
Overall, this continues to outline the flexibility of the Alfresco platform as a repository. Although out of the box interfaces such as Alfresco Share exposes key document management concepts such as versioning and security, additional functionality can be exposed through alternative document management interfaces such as HPI. Would be curious to hear others who may have exposed this functionality through other interfaces as well.