Version Baselining

One of the great things about working with Alfresco is the vast number of extension points the system offers to developers.  Some of these stem from the pervasive use of the Spring framework, some of them to a well thought out application architecture, and many of them from a number of guiding principles that are consistently applied even when their potential uses aren’t necessarily known with certainty ahead of time.

I recently had the pleasure of being reminded of this latter case when a customer asked for an extension that allowed their content contributors to control the “baseline” version number of documents in their Alfresco installation.  The idea was to allow their contributors to (optionally) enter a version number along with each document, and have the Alfresco versioning system start with that version number instead of the default of 1.0.

Although I didn’t know how this might be achieved, in less than 10 minutes I had my answer and it relied on a slight variation of a mechanism that I’d used in the past.  The customer was also gracious enough to release the IP, so I’ve made the initial version of the extension available on google code.

Here is a brief overview of its usage:

This extension works by extending Alfresco with a custom content type called “Version Baselined Content” that includes a single property called “Base Version”.  This property is where the content contributor can set the base version to be used if/when versioning is enabled on the document.

In order to create content of this type, “Version Baselined Content” needs to be selected in the “Type” dropdown of the “Add Content Dialog”:

Provided the “Modify all properties when this page closes” checkbox is left checked (the default), the contributor will then be presented with the option to specify the base version number for this document (if/when versioning is enabled):

The default value for this field is “0.1″ – if the contributor elects to skip modification of the new content’s properties, this is the base version number it will be assigned automatically.

The base version number must be a valid non-negative decimal number (ie. it must be a number greater than or equal to 0.0).  If an invalid value is entered, an error will be displayed when the user clicks the “OK” button.

Once the version number is populated, it may be edited via the document’s properties as many times as are necessary, up until the time versioning is enabled for the document:

Once versioning is enabled for the document, the initial version number will be set to the value of the “Base Version Number” property at that time:

From this point on, any modifications to the “Base Version Number” property will be ignored as it is not possible to renumber an existing Alfresco version history.

Other than allowing explicit control over the initial version number for a document, this extension does not change any other versioning behavior in the system.  For example creating a new minor revision of a document (via checkout and checkin) will increment the version number by 0.1.  Similarly, creating a new major revision of a document (via checkout and checkin) will increment the major component of the version number by 1, and set the minor component to 0:

While the extension is quite neat and (due to the generosity of the customer) available for anyone to use, refine and extend, what really grabbed me as I developed it was how, despite having no prior experience with this particular extension point, it was familiar enough that I was able to understand it almost immediately and leverage it to achieve the desired goal.

Tags: , , , ,

  • AndyM

    How do you actually set the version label on the node? Is the source code or a code snippit available? Cheers

  • Peter Monks

    Andy, the source code is available from the Google code project referenced in the post.

    But to answer your question, the code uses a custom “Calculate Version Label” Content Policy which does one of two things:
    1. if the node is being freshly versioned (ie. has never been versioned before), it reads the baseline version number property of the node and sets that as the initial version number
    2. if the node is already versioned, it delegates to the default version handling logic to increment the version number

  • rpalf

    Can a minor version with 3 decimals, e.g. 1.001 be used? The increment for minor versions is therefore 0.001 in stead of 0.1. The next minor version for 1.001 is then 1.002. Thanks

  • Peter Monks

    rpalf, Alfresco’s default versioning system only supports increments of 0.1 or 1.0, so can’t directly do what you’re after. That said, the 0.1 increments do not carry over after ten additions, meaning that a document can have versions such as 1.4, 4.10, 17.29, 137.863, etc.

  • rpalf

    From a technical point of view, I derive that 2 separate “variables” are used for the major and minor portion of the version and that the increment is always 1 for both. The major and minor are then concatenated with a “.” to separate them. Is my conclusion correct?

  • Peter Monks

    rpalf, in effect that’s correct, though only a single metadata property is actually used to store the version number. The values in that property are split on ‘.’ prior to either of the components of the version number being incremented, then recombined prior to the updated value being persisted back into the repository.

  • Pingback: Alfresco: Max Version Policy at Jared Ottley

  • znikolovski

    Hi Peter,

    I’m using another one of your tools (the bulk loading tool) and I’m interested if I can set the version of the file(s) that I upload using the metadata properties file referencing a baseline version value?


  • Peter Monks

    Zoran, I can’t think of any reason the two extensions couldn’t be used together, although I have not tested them together in the way you describe.

    The bulk filesystem importer supports any types and/or aspects, as well as their metadata properties, and the version baselining tool works by defining a simple custom content model for capturing the baseline version number. That content model defines a single type (“vb:VersionBaselinedContent”) with a single property (“vb:BaseVersion”), so all that’s required is to create shadow metadata files in the format the bulk filesystem importer expects that sets the type of the relevant files to vb:VersionBaselinedContent, and sets the value of the vb:BaseVersion property. This is described in more detail in the README.txt file for the bulk filesystem importer.

  • znikolovski

    Thanks Peter! That bit of info will make a lot of people in the company very happy.

  • Peter Monks

    Glad to hear it! Let me know how you get on with it – always keen for feedback on how the extensions are working, particularly in cases (like yours) that I had not originally envisaged (but which makes perfect sense).

  • znikolovski

    Just letting you know that it worked like a charm! You did a good job with these plugins.

  • Peter Monks

    Good to hear! Just out of interest, did you try setting the baseline version and adding the cm:versionable aspect at the same time during import? Would be great to confirm that that scenario works.

  • znikolovski

    No I didn’t – I just went by adding the “vb:VersionBaselinedContent” type and setting the vb:BaseVersion property. I’ll have a go at that and let you know.

  • znikolovski

    Worked extremely well – before the cm:versionable aspect the system didn’t present the properties associated with that aspect (such as Version Label, Creator, Creation Date etc.) and I was actually requested to include them, but with the addition of it it all became visible. Thanks again for the suggestion.

  • rpalf

    I have installed Alfresco 3.4c and applied the baseline versioning amp file. I can upload new content and give it a new baseline version. When trying to allow versioning, I am getting the following error:

    Failed to apply the ‘versionable’ aspect to the document due to system error: 00070002 Failed to execute transaction-level behaviour public abstract void org.alfresco.repo.node.NodeServicePolicies$OnAddAspectPolicy.onAddAspect(org.alfresco.service.cmr.repository.NodeRef,org.alfresco.service.namespace.QName) in transaction d4d8c16b-3e66-4a88-b371-b377a5269cb5

  • Peter Monks

    rpalf, would you mind raising this in the issue tracker in the Google Code project? Thanks!

  • shizukesa

    Is it possible to extend the versioning behaviour to include maintenance versions, so that the new version number would then be of the format … How would I go about implementing this? Any help is appreciated. Thanks

  • Peter Monks

    shizukesa, the OOTB versioning mechanism does not support an “x.y.z” format for version numbers, but it may be possible to cleanly replace it with a custom implementation that does. I’ve not investigated that possibility myself, so don’t have much sense of the feasibility of such an undertaking.

  • uskiki85

    This is not working with Alfresco Community 3.4.d

    I hope that there will be an update to correct this problem

  • Peter Monks

    uskiki85, please feel free to submit a patch. I have not had time to install or test this extension on Alfresco 3.4, and unfortunately don’t foresee having time to look into it any time soon.

    Alternatively, if you’re an Enterprise subscriber you might consider engaging Alfresco Consulting to implement a fix for this issue?

  • uskiki85

    Solution :

    commenting the section below in file \tomcat\webapps\alfresco\WEB-INF\classes\alfresco\core-services-context.xml




    Thanks to Giuseppe !

  • uskiki85

    the bean to comment is registerContentWithVersionService in core-services-context.xml

    Sorry for last post but i don’t know why the bean to comment will be deleted …

  • Nicolas Raoul

    Hello all,

    I created and uploaded a new AMP with Alfresco 4 support, you can download it below:

    It has the same bug as uskiki85 had, but this is easily solved using Giuseppe’s trick:

    Thanks Peter for creating this extension!
    Nicolas Raoul

  • Raúl Macian

    Looking from another perspective, since 3.4.3 as can be read on the JIRA the behaviour of the numbering has changed.

    Now the initial version is 0.1 instead of 1.1, can be this controlled somehow ?

  • Vignesh

    Hi Peter,

    This works only in webclient. But not in share after customizing share in making the versionbaselining content type as default on.

  • Peter Monks

    Vignesh, that’s correct – the UI customisations included in the package only target the Explorer UI. It shouldn’t be hard to accomplish the same thing in Share, via custom metadata Forms.

  • Vignesh

    Hi Peter,

    We are using your version baselined plugin and migrated around 50k documents with different base version. Now we are trying to enable auditing for the custom content type filter settings as below

    #Enable/Disable Auditing properties

    But auditing is not working for baseline versioned content type. Could you please suggest are there any settings we missed out ?

  • Peter Monks

    Vignesh – you’d probably be best raising a support ticket. I’m not familiar enough with the auditing subsystem to know where to start troubleshooting this.

Alfresco Home | Legal | Privacy | Accessibility | Site Map | RSS  RSS

© 2012 Alfresco Software, Inc. All Rights Reserved.