Issues with NodeService.moveNode & FileFolderService.move

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

rsulliv1

Hello all,

Has anyone worked with the NodeService's moveNode or FileFolderService's move functions? I'm seeing the same odd behavior with both functions.

The requirement I am fulfilling is that when a folder of my custom type is created, move it to a single containing folder. There are two main cases for this to occur: upon initial creation (i.e., created directly via alfresco explorer's adv space wizard), or when a new folder is created via Share, then the type is changed via the "Change Type" document action.

For example, Under a share site:

documentLibrary –> Consultants –> <items should go here>

The basic rundown of the code is that it's a behavior that binds to the onCreateNode, onUpdateNode, and onDeleteNode policies. The frequency is TRANSACTION_COMMIT. I'm binding to a single custom content type which has a parent type of cm:folder.

I'm not doing anything besides outputting a logger for the delete event.

I'm executing two validations (and one delete-provision validation for create) for create and update: 1. Verify that node isn't already under the correct parent folder & 2. verify that the folder to be moved isn't the same as the parent folder (i.e., prevent child/parent cyclical relationships).

If both of the above validations are passed, then I attempt to move the node.

The commands I'm executing are either:

I found the assocRef param on this page http://kickjava.com/src/org/alfresco/service/cmr/model/FileFolderService.java.htm

ChildAssociationRef assocRef = this.nodeService.getPrimaryParent(sourceNodeRef);
nodeService.moveNode(sourceNodeRef, targetNodeRef, ContentModel.ASSOC_CONTAINS, assocRef.getQName());‍‍

or

fileFolderService.move(nodeRef, targetParentFolderNodeRef, null);‍

Initially, either after the folder of the custom type is created or converted via the "Change Type" Action, the folder is in the correct location, under the "Consultants" folder. See image 0 for grandparent folder, image 1 for parent folder, image 2 for the target item.
[img]http://permanenttangent.com/imgs/alf/0.png[/img]
[img]http://permanenttangent.com/imgs/alf/1.png[/img]
[img]http://permanenttangent.com/imgs/alf/2.png[/img]
After updating the name from "t1" to "t1s", the folder automatically moves up one level. It's located under the documentLibrary folder. See image 3 for the documentLibrary node after the metadata update to the target node (the folder that should have been moved to under the "Consultants" folder; now named "t1s").

[img]http://permanenttangent.com/imgs/alf/3.png[/img]

NOTE that at this point, the "Child Name" of the target node is "move" instead of its previous name of "t1". The cm:name attribute still is correct, but the "Child Name" has been modified.


See image 4 for the contents of the target node. Again, it appears normal except the "Child Name" has changed to "move".
[img]http://permanenttangent.com/imgs/alf/4.png[/img]
See image 5 for the contents of the "Consultants" folder, which should contain the target node.
[img]http://permanenttangent.com/imgs/alf/5.png[/img]
NOTE: that even if my folder is initially created in Company Home via the alf explorer and never was a child of documentLibrary, it still behaves the same way. It doesn't appear that the node reverts to its previous location, but it moves up the hierarchy one step.
I can validate that my move code is not executing when the target node moves inappropriately. There are no errors in the log file. I'm still searching for anything that could point me towards this odd behavior.

I read this from J. Potts' article, and it doesn't appear that this is directly the cause of my issue, but the "move" is certainly described here. The only issue is that I'm explicitly defining the destinationAssocQName (parameter four in the moveNode), so I wouldn't expect to see the "move" issue in my example.

From J. Potts' actions-article:

Note that in Alfresco's “moveNode” call, they use destinationAssocQName as the qname of the newly moved
node. That variable resolves to the string “move”. If you ever move more than one document
into a folder using that action, you'll get integrity violations. This seems like a bug to me. My version of
the “moveNode” call uses the current name of the object being moved as the new name, which seems
like a better way to go.

Does anyone have any insight to this issue? Has anyone successfully used the moveNode or move function to move folder nodes within other folder nodes?

Thanks,
-ryan

rsulliv1

Update:

Appears that my issue is closely related to JIRA# ETHREEOH-2014 although this issue is marked as fixed in 3.1sp2. I'm currently hunting down the release date of 3.1sp2 as I'm assuming it's codebase wasn't merged with 3.2. Perhaps this issue was fixed in 3.2r?

Also, I just noticed that folders of type cm:folder will not stay within other folders of type cm:folder in my Share Site. If I create a new Share Site, they will stay nested correctly, but that is not the case for my Share Site. I can verify that my move behavior is not executing on these objects.