Did you know there is a right way and a wrong way to rename nodes (documents, folders, etc.) in Alfresco? The most common way to rename a node is by changing the cm:name property. It might come as a surprise that this is actually the wrong way, for reasons that we will get into in a moment. We’ll also explain why, and look at a way to find nodes that have been renamed incorrectly so they can be fixed.
The Right Way
FileInfo rename(NodeRef fileFolderRef, String newName). This is the method to use when renaming a node in Java:
The Wrong Way
The wrong way to rename a node is to just set the cm:name property to the new name:
Why is this wrong?
In Alfresco, the node name is also used in the XPath. When you change the cm:name property, the XPath remains the same as it was before the name property change, and now you can’t find your node with a path search.
For example, if you have a folder node with the following display path and name:
The XPath query for this folder is:
(NOTE: you can paste this into the Alfresco Node Browser and select “XPath” as the query language, and get the NodeRef of the “Frankenstein” folder)
If you then rename the folder “Frankenstein” just by changing cm:name as in the “wrong” examples above, and then try your XPath search with the new name (“Fronkensteen”):
This XPath search will fail.
It fails because the XPath is derived from the name property of the association which links parent nodes to child nodes, and not the cm:name property of the child node itself. When you create a node and give it a name, the association name property and the node name property are the same, but when you set the node name property, you are not changing the XPath. And since the association name property is not visible (at least to an end user), any XPath search functionality based on the name that is visible (the cm:name property of the node) won’t work after the rename of the node.
In the Share property editor, changing the name property will actually call the FileFolderService.rename(), which will update both the cm:name property of the node as well as the association name property.
Oops! I’ve been doing it this way all along…
We’ve been renaming nodes the wrong way forever and XPath searches aren’t working.
If there are lots of nodes that have been renamed the wrong way, finding them might present a problem. Fortunately there is a database query that can figure this out. This query is specific to nodes of type cm:folder:
To query cm:content nodes, substitute ‘content’ for ‘folder’ in the qn.local_name clause. If you have a custom type, use that and the fully-qualified namespace in the qn.local_name clause and the ns.uri clause.
The last record in the query results is “Frankenstein” which is now named “Fronkensteen,” but the XPath still has “Frankenstein.”
Also note the first four records in the query results. These are built-in Alfresco nodes and are created out of the box with mismatches between the XPath and the node names. Note that there are more nodes than this, but these are the ones that are in the cm (http://www.alfresco.org/model/content/1.0) namespace. The others are in the app namespace (http://www.alfresco.org/model/application/1.0) which is excluded from the query.
Now, armed with the NodeRefs for your offending nodes, you are ready to correct them!
So, how can I fix this?
Never fear, once you’ve identified the nodes that have this problem, the solution is pretty straightforward: if you call the correct methods to change the name again, that will fix it.
You do have to change the name to something even newer (for example from “Fronkensteen” to “Eyegore”), because the underlying FileFolderService implementation will not go to the trouble of actually renaming a node and the association/XPath name if the new name is the same as the old name (as defined by the cm:name property).