Skip to content
This repository has been archived by the owner on Sep 25, 2022. It is now read-only.

Versions numbers as they appear on disk should be used for versions in the repository #13

Open
pmonks opened this issue Dec 12, 2013 · 4 comments

Comments

@pmonks
Copy link
Owner

pmonks commented Dec 12, 2013

Migrated from https://code.google.com/p/alfresco-bulk-filesystem-import/issues/detail?id=85

Currently the tool ignores the version numbers that appear on disk (with one exception - see below) and instead starts the version history at 1.0 and increments by 0.1 or 1.0 for each additional version. Instead the tool should use the exact version numbers that appear on disk, even when a version series is gappy.

Note: this is currently not possible - Alfresco does not allow version labels to be explicitly set. Technically speaking, the "cm:versionLabel" property is a protected property that cannot be set directly. See http://issues.alfresco.com/jira/browse/ALF-10155

@igorbga
Copy link

igorbga commented Aug 31, 2015

This is the core of an action I use to change the version label of a node:

@Override
protected void executeImpl(Action action, NodeRef actionedUponNodeRef)
{
    NodeService nodeService = serviceRegistry.getNodeService();
    VersionService versionService = serviceRegistry.getVersionService();

    Version currentVersion = versionService.getCurrentVersion(actionedUponNodeRef);
    if (null == currentVersion)
    {
        String msg = MessageFormat.format(MSG_ERROR_NODE_DOES_NOT_HAVE_CURRENT_VERSION, actionedUponNodeRef);
        throw new AlfrescoRuntimeException(msg);
    }

    String versionLabel = (String) action.getParameterValue(PARAM_VERSION_LABEL);

    VersionHistory versionHistory = versionService.getVersionHistory(actionedUponNodeRef);
    boolean versionExists = true;
    try
    {
        versionHistory.getVersion(versionLabel);
    } catch (VersionDoesNotExistException e)
    {
        versionExists = false;
    }
    if (versionExists)
    {
        String msg = MessageFormat.format(MSG_ERROR_NODE_ALREADY_HAS_VERSION_LABEL, actionedUponNodeRef,
                versionLabel);
        throw new AlfrescoRuntimeException(msg);
    }

    NodeRef legacyFrozenStateNodeRef = currentVersion.getFrozenStateNodeRef();
    /*
     * In Alfresco 4.2 the version service points to nodes with a non
     * correct protocol something like, versionStore or something similar. I
     * guess this is some kind of legacy protocol used prior to Alfresco 3.1
     * and those protocol references are used for legacy compatibility...
     * Anyway we must change the protocol so that the low level
     * dbNodeService finds the node correctly.
     */
    NodeRef frozenStateNodeRef = new NodeRef(versionService.getVersionStoreReference(),
            legacyFrozenStateNodeRef.getId());

    dbNodeService.setProperty(frozenStateNodeRef, Version2Model.PROP_QNAME_VERSION_LABEL, versionLabel);
    nodeService.setProperty(actionedUponNodeRef, ContentModel.PROP_VERSION_LABEL, versionLabel);
}

Just in case it gives any clue about how to solve the issue.

@pmonks
Copy link
Owner Author

pmonks commented Dec 1, 2015

Changing version labels is not currently supported by Alfresco, and while it may be technically possible in specific releases of the product via low-level mechanisms (such as those used above), there's no guarantee that such code will work on anything but a specific release.

Ultimately until / unless ACE-3735 is fixed, this issue remains blocked.

@pmonks pmonks added the blocked label Dec 1, 2015
@rmknightstar
Copy link

may be better to add an aspect with the original version number if it differs from the one that ends up in the repository

@pmonks
Copy link
Owner Author

pmonks commented Aug 20, 2018

Absolutely - the way to do that would be to deploy an appropriate content model to the repository, prepare appropriate shadow metadata files, then run the tool as-is.

It is not appropriate for the tool to deploy content models of its own, as that's an intrusive operation that would inhibit the ability for an administrator to uninstall the tool once their bulk imports are complete (something that is possible today).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants