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: content policies, DM, labels, versionable, versioning
January 6th, 2010 at 2:48 am
How do you actually set the version label on the node? Is the source code or a code snippit available? Cheers
January 6th, 2010 at 5:05 pm
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
June 10th, 2010 at 7:32 am
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
June 10th, 2010 at 9:16 pm
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.
June 23rd, 2010 at 7:13 am
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?
June 23rd, 2010 at 2:05 pm
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.
July 23rd, 2010 at 6:56 am
[...] an example of a calculateVersionLabel policy look at this post and the accompanying code by Peter [...]
August 3rd, 2010 at 4:43 am
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?
Cheers,
Zoran
August 3rd, 2010 at 5:55 am
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.
August 3rd, 2010 at 6:17 am
Thanks Peter! That bit of info will make a lot of people in the company very happy.
August 3rd, 2010 at 2:38 pm
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).
August 4th, 2010 at 11:42 pm
Just letting you know that it worked like a charm! You did a good job with these plugins.
August 5th, 2010 at 1:53 am
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.
August 5th, 2010 at 3:07 am
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.
August 5th, 2010 at 4:46 am
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.
January 7th, 2011 at 9:56 am
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
January 7th, 2011 at 7:20 pm
rpalf, would you mind raising this in the issue tracker in the Google Code project? Thanks!
February 25th, 2011 at 7:14 am
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
February 26th, 2011 at 12:43 am
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.
May 9th, 2011 at 10:24 am
This is not working with Alfresco Community 3.4.d
I hope that there will be an update to correct this problem
May 9th, 2011 at 2:58 pm
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?
May 10th, 2011 at 7:44 am
Solution :
commenting the section below in file \tomcat\webapps\alfresco\WEB-INF\classes\alfresco\core-services-context.xml
<!–
cm:content
–>
Thanks to Giuseppe !
May 10th, 2011 at 7:45 am
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 …
January 31st, 2012 at 7:17 am
Hello all,
I created and uploaded a new AMP with Alfresco 4 support, you can download it below:
http://code.google.com/p/alfresco-version-baselining/issues/detail?id=2
It has the same bug as uskiki85 had, but this is easily solved using Giuseppe’s trick:
http://code.google.com/p/alfresco-version-baselining/issues/detail?id=1
Thanks Peter for creating this extension!
Nicolas Raoul
February 1st, 2012 at 11:33 am
Looking from another perspective, since 3.4.3 as can be read on the JIRA https://issues.alfresco.com/jira/browse/ALF-8190 the behaviour of the numbering has changed.
Now the initial version is 0.1 instead of 1.1, can be this controlled somehow ?