I’ve always wanted to put together a post about DRM’s audit capabilities. I feel this particular feature might be a bit underused. Nonetheless, it does offer up a number of possibilities. So, here is the first in a series that I will update periodically on this feature.
Recently, I was asked whether it was possible to extract the details of shared nodes that were added on to a hierarchy. The ask was that a number of shared nodes were added on to a hierarchy using an action script. While that worked, there was now a need to update some local properties. While you could do this one at a time, I am sure you would baulk when the number hits the 100s. To illustrate the point, I’ve set up a simple hierarchy with shared nodes on it.
Local properties allow you to have different property values for the same node. For instance, for each instance of the “HOPSLAM” node below, you could have different values for a local property.
By the same token, you wouldn’t want to run a “ChangeProp” for a local property where you meant to have one value for the node below “IMPERIAL_IPA” versus the node below “BELLS”. The results could be incorrect.
As with anything, there are different ways to handle this. My preference in this case was to use DRM’s humble Audit feature. I selected the “BEER” version, as seen below.
I selected “Core Action” for “Levels”, from the Filters tab.
There are a number of “Actions” you could choose from. I chose “Insert Node”, as the addition of shared nodes is considered an insert as opposed to an add.
You can do further selections if you wish depending on your need. That’s all I needed in my case, and I ran the audit.
Close enough, but no cigar. Since we still don’t have the shared node name, we still couldn’t run our action script against these nodes.
The tweak to be made was to change to a “Result” level, rather than a “Core” level.
If you now run your audit, you should get the correct node names.
Further, you can also download these results to set up your action script.