updateVersionHistory wrongly creates everything as 0.1 when called from the signature page code

[benallenallen]

When a document is either:

1. obsoleted
2. periodic reviewed

the code calls TSGAlfrescoAppendSignaturePageImpl to append the updated signature page. The problem is that on the last line of that method, AlfrescoEmbUtil.updateVersionHistory(serviceRegistry, nodeRef) is called, which seems to have a bug that changes the 1.0, 2.0, 3.0, x.0 document to 0.1.

This is more than likely caused by a combination of the following:

AlfrescoEmbUtil#updateVersionHistory (~ line 467)

This method is what is being called, and it seems like it is removing all of the "reserved" properties that Alfresco should be setting. One of the reserved values that is being removed is versionLabel, which we think is causing issues with the behaviour:

//remove reserved props
for(String reserved : VersionUtil.RESERVED_PROPERTY_NAMES){
    vProps.remove(reserved);                        
}

TSGControlledDocumentBehaviors.java

This class has our custom behaviours that are messing up when the versionLabel is not passed in. There are various methods in there using the ContentModel.PROP_VERSION_LABEL constant, and in some cases, when we see 'null' as the value of this property, we are assuming it should be a '0.1' document (which is the core issue).

onCreateVersion

String oldVersionLabel = (String) serviceRegistry.getNodeService().getProperty(versionableNode, ContentModel.PROP_VERSION_LABEL);
...
//if this is still blank this is a new document
if(StringUtils.isBlank(oldVersionLabel))
{
    //brand new node
    newVersionLabel = "0.1";
    }
        else
        {
        newVersionLabel = calculateNextVersion(oldVersionLabel, (VersionType)
                versionProperties.get(VersionModel.PROP_VERSION_TYPE));
        }
}

onUpdateProperties

//recalculate name in case doc number changed
String versionLabel = (String) after.get(ContentModel.PROP_VERSION_LABEL);
if(StringUtils.isBlank(versionLabel))
{
    //new doc nothing to do
    return;
}

[gsteimer]

@benallenallen - I tried fixing this in the behaviors, but to no avail. Some notes:

• My idea of checking for the first version in a different way didn't work because the oldVersionLabel is still null. This throws off the calculateNextVersion method.
• Removing the property from the list doesn't work, since they're getting different keys. The the reserved property is VersionBaseModel.PROP_VERSION_LABEL and our behavior gets ContentModel.PROP_VERSION_LABEL
  • Removing ContentModel.PROP_VERSION_LABEL does nothing, since it's not in the map
  • Removing VersionBaseModel.PROP_VERSION_LABEL causes the createVersion method immediately after the loop to fail (which is most likely why the remove was put in there in the first place).

So, after all that, I just tried removing the call to updateVersionHistory in the eSig code. That seemed to work in all our test cases (update content, annotations, etc), so that's what I'm going with for now. Perhaps if we can get some of @parzgnat's time at some point, there's a better solution.

I changed the logic a little bit though. Instead of not calling updateVersionHistory every time the signature page is added, I simply don't call it when we're signing a major version:

String versionLabel = (String) serviceRegistry.getNodeService().getProperty(nodeRef, ContentModel.PROP_VERSION_LABEL);
if( !versionLabel.endsWith(".0") )
{
    //fix the version store since we are updating a node inline without checking it out first
    AlfrescoEmbUtil.updateVersionHistory(serviceRegistry, nodeRef);
}

This makes it so the version store is only wrong for major versioned documents, which I think is OK. We can talk through this during the AW weekly meeting...

Fixed in OC Rev 10102