• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
TSB Alfresco Cobrand White tagline

Technology Services Group

  • Home
  • Products
    • Alfresco Enterprise Viewer
    • OpenContent Search
    • OpenContent Case
    • OpenContent Forms
    • OpenMigrate
    • OpenContent Web Services
    • OpenCapture
    • OpenOverlay
  • Solutions
    • Alfresco Content Accelerator for Claims Management
      • Claims Demo Series
    • Alfresco Content Accelerator for Policy & Procedure Management
      • Compliance Demo Series
    • OpenContent Accounts Payable
    • OpenContent Contract Management
    • OpenContent Batch Records
    • OpenContent Government
    • OpenContent Corporate Forms
    • OpenContent Construction Management
    • OpenContent Digital Archive
    • OpenContent Human Resources
    • OpenContent Patient Records
  • Platforms
    • Alfresco Consulting
      • Alfresco Case Study – Canadian Museum of Human Rights
      • Alfresco Case Study – New York Philharmonic
      • Alfresco Case Study – New York Property Insurance Underwriting Association
      • Alfresco Case Study – American Society for Clinical Pathology
      • Alfresco Case Study – American Association of Insurance Services
      • Alfresco Case Study – United Cerebral Palsy
    • HBase
    • DynamoDB
    • OpenText & Documentum Consulting
      • Upgrades – A Well Documented Approach
      • Life Science Solutions
        • Life Sciences Project Sampling
    • Veeva Consulting
    • Ephesoft
    • Workshare
  • Case Studies
    • White Papers
    • 11 Billion Document Migration
    • Learning Zone
    • Digital Asset Collection – Canadian Museum of Human Rights
    • Digital Archive and Retrieval – ASCP
    • Digital Archives – New York Philharmonic
    • Insurance Claim Processing – New York Property Insurance
    • Policy Forms Management with Machine Learning – AAIS
    • Liferay and Alfresco Portal – United Cerebral Palsy of Greater Chicago
  • About
    • Contact Us
  • Blog

Alfresco Versioning – How to make it better with the TSG Chain Version Module

You are here: Home / Alfresco / Alfresco Versioning – How to make it better with the TSG Chain Version Module

August 14, 2017

For those that have read the Alfresco and Documentum comparison whitepaper, Alfresco has significant benefits when compared to Documentum for the majority of ECM capabilities.  One of the few capabilities where Alfresco is not as strong as Documentum is document versioning and lifecycle as we described on a blog post about the versioning differences.   For the TSG Compliance Solution TSG built a work-around for Alfresco with our OpenContent products. Recently, we have been working with Alfresco engineering to make Alfresco versioning better at the repository level for all Alfresco customers.  In this post, we’ll discuss our solution along with a demonstration.

If you haven’t already, be sure to read the blog post linked above as well as the versioning section of the Documentum to Alfresco comparison whitepaper.  Essentially, the problem with the default Alfresco versioning functionality is that versions are not treated as first class citizens in the repository.  The approach has some advantages for file mapping capabilities (CIFS and WebDAV) but some downsides include:

  • Versions cannot have different security.  You cannot have a 1.0 (typically Approved) version that everyone can see, but a 1.1 (typically Draft) version that only document editors can see and modify.
  • Versions cannot be searched.  You cannot run a search and bring back multiple versions of the same document.  Note that Alfresco is allowing this functionality in version 5.2 but it’s off by default and turning it on enables it repository wide.  Our approach, discussed below, allows for this functionality to be applied on a type by type basis.
  • Versions cannot have their own associations.  One obvious issue out of the box in the Alfresco Share interface has to do with document previewing in Share.  Since PDF renditions are associations, you can only preview the latest version of a document in Share.  If you want to view an old version, your only option is to download the native content and view it locally.  Another example of associations are annotations with OpenAnnotate.  If you add annotations to version 1.4 of a document, when the document is versioned to 1.5, all of the annotations come over to 1.5 rather than ‘sticking’ to 1.4 as the user would expect.
  • Versions need to be migrated in order.  For complex migration of documents with versions, all versions for a document need to be migrated in order from oldest to newest limiting the flexibility of the migration as well as the speed.  For example, it’s not possible to migrate document versions in a multi-threaded manner.

To make Alfresco versioning and security better, TSG has created a Chain Versionable module.  The idea here is that it will piggy-back on the default cm:versionable module in Alfresco and will be optional on a per-type basis.  In other words, Alfresco clients will be able to have types of documents in the repository that utilize the current out of the box Alfresco versioning, and other types that use the new Chain Versionable module.  Additionally, since we build upon Alfresco’s default versioning the “version number” attribute is no different between normal versionable documents and new Chain Versionable documents.

How Does the Chain Versionable Module Work?

The Chain Versionable module addresses all of the limitations stated above.  When a document type implements the Chain Versionable module, each version is a first class citizen in the repository and implemented with a hidden “version chain container”.  This container is used by the module to link the version chain together.

Since versions are first class citizens with the Chain Versionable module:

  • Each version can have its own security applied.  By default, a new version will have the same security as the previous version, but this can be overridden by rules, behaviors or lifecycle configurations (more on lifecycles later).
  • Each version can be searched and multiple versions of the same document can be present in a single query’s results.
  • Each version can have its own associations.  We get this one for free with the Chain Versionable module – since each version has its own associations, it’s now possible to preview any version directly within the Share interface.  Additionally, OpenAnnotate annotations are tied to the correct version and are not carried over.
  • Document versions can be migrated in any order.  With TSG OpenMigrate and Chain Versionable products, versions can even be migrated in a multi-threaded manner.

For readers interested in the technical details, here’s how it works under the covers.  First – when a document is created, we set the initial version number to 0.1 to follow best practices for in process (minor versions) vs. approved content (major versions):

The document is linked to the hidden version chain container as the primary association, and the Alfresco folder as a secondary association.  We also include flags for the ‘Active’ and ‘Latest’ version that will come into play as we version the document.  When a user views this folder in Share (or any other interface), the 0.1 version of the document will be visible.  Note that security rules could be set to enforce that the correct users have access to this document.  Now lets see what happens when the document is versioned to 1.0:

When the 1.0 version is created, we move the secondary association as well as the Active and Latest flags over to the 1.0 document.  When viewing the folder in Share, the 1.0 document will appear if the user has access.  As with above, security rules could be created to set the permissions on the 1.0 version since typically a wider user base has access to major versions.  Let’s take it one step further and minor version the document again:

As with the previous step, we create a new node, link it to the hidden version chain container and move over the Latest flag.  However, there are two important differences – the secondary association and Active flag both stay on the 1.0 document.  This means that when viewing the document in Share, the 1.0 version will display.  Typically in this scenario, security is applied to the 1.1 version to ensure that only document authors have access.   Once the 2.0 version is created, then the association and Active flag will move over and the wider audience will see the updated document.

See a Demo

Let’s see it in action.  We’ll use Share to demonstrate the module, but it will work with any interface:

We’d love to hear your thoughts on the new Chain Versionable module.  Going forward, we’re going to utilize this module for all Alfresco clients that require more complex versioning and security features than Alfresco can provide out of the box.

What’s Next?

While we are addressing versioning here, but not security and lifecycle.  Those two features are the logical next step.  Currently, TSG clients can meet lifecycle and version security requirements with OpenContent in the Compliance Management Solution, but we’d love to implement this more at the repository level so that all Alfresco clients can take advantage of it.

We’d also love for Alfresco customers to reply here: Do you have requirements in your system around document lifecycle and  security across versions?  If you’re not implementing the OpenContent Compliance Management solution, how are you (or how do you plan to) meet these requirements with Alfresco’s current limitations?

If you’re interested in utilizing the TSG Chain Versionable module for Alfresco, contact us here!

Free Alfresco Documentum Comparison Whitepaper

Filed Under: Alfresco

Reader Interactions

Comments

  1. Ivan Listes says

    August 14, 2017 at 3:32 pm

    I’d love to be able to branch a version, similarly to how Documentum handles it.

    Reply
    • George Steimer says

      August 16, 2017 at 1:54 pm

      Ivan, thanks for your comment. We haven’t implemented version branching in this first iteration, but it’s certainly possible to add at some point in the future.

      Reply

Trackbacks

  1. Alfresco – ADF and OpenContent Comparison- REST Web Services says:
    July 20, 2018 at 9:42 am

    […] impossible to have separate renditions on two or more versions of a document.  See this post on Alfresco versioning for more […]

    Reply

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Search

Related Posts

  • Alfresco Content Accelerator and Alfresco Enterprise Viewer – Improving User Collaboration Efficiency
  • Alfresco Content Accelerator – Document Notification Distribution Lists
  • Alfresco Webinar – Productivity Anywhere: How modern claim and policy document processing can help the new work-from-home normal succeed
  • Alfresco – Viewing Annotations on Versions
  • Capture 2.0 – Document Classification with Machine Learning
  • Modernizing Claims Content Processing – Next Generation Digitization Tools
  • Microsoft Teams integration and the Alfresco Enterprise Viewer for Document Review
  • Alfresco Content Accelerator for Patient Records
  • Redaction – a focus on efficiency with Alfresco Enterprise Viewer
  • Alfresco Claims Management – Streamlining Claims Document Requests

Recent Posts

  • Alfresco Content Accelerator and Alfresco Enterprise Viewer – Improving User Collaboration Efficiency
  • Alfresco Content Accelerator – Document Notification Distribution Lists
  • Alfresco Webinar – Productivity Anywhere: How modern claim and policy document processing can help the new work-from-home normal succeed
  • Alfresco – Viewing Annotations on Versions
  • Alfresco Content Accelerator – Collaboration Enhancements
stacks-of-paper

11 BILLION DOCUMENT
BENCHMARK
OVERVIEW

Learn how TSG was able to leverage DynamoDB, S3, ElasticSearch & AWS to successfully migrate 11 Billion documents.

Download White Paper

Footer

Search

Contact

22 West Washington St
5th Floor
Chicago, IL 60602

inquiry@tsgrp.com

312.372.7777

Copyright © 2023 · Technology Services Group, Inc. · Log in

This website uses cookies to improve your experience. Please accept this site's cookies, but you can opt-out if you wish. Privacy Policy ACCEPT | Cookie settings
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT