By rbishop on Mar 13, 2014
Today, let's talk about move validations. They are a kind of real-time validation you can create. Before the introduction of Dynamic Scripting, it wasn't really possible to make use of move validations (because they only fired after the move) so they often get overlooked.
With Dynamic Scripting, a move validation actually gets fired twice in a two-phase execution. The "move.IsPre" and "move.IsPost" tell you which phase you are in, so a simple if/else check allows you to separate your script.
1. IsPre - Before the move takes place
This phase gives you the node as it exists under the old parent and is your opportunity to collect information to be checked in the second phase. Record any values in your "move.Values" object, but be aware that any complex objects like nodes or versions will get "flattened" to simple strings because the objects they represent change state after the move, so be sure to dig out any actual property values you are interested in.
2. IsPost - After the move takes place
This is what we normally think of as the regular validation phase and happens after the move. The node is now under the new parent, which means any inherited property values have changed, calculated values are updated, etc. That means you can compare the new values to any old values you saved in the "move.Values" object.
In both phases, you have access to "move.OldParent" and "move.NewParent" so you can check any property values or structure you like of the old parent and new parent both before and after the move. For example, you could stop the move if the new parent already has too many children in the pre move phase; or you could stop the move if the value of a derived property on the old parent changed after the move.
I hope with these new capabilities customers will find that Move validations are a powerful tool for data quality.