A plugin registered in the validation step won’t intercept any of the changes that get added to the plugin Target in the pre-create. It seems so obvious.. but it’s not something I’d normally be thinking about when developing the plugins.
One of the plugin patterns most of us like using looks like this:
– We would create a pre-operation plugin
– In that plugin, we would populate some attributes of the plugin Target
That way, we can save time/resources which would, otherwise, be required if we did the same in the post-operation plugin (since we would have to call service.Update on the target entity in the post-operation):
This process works great, most of the times. There is one exception.. If we wanted to validate something in the pre-validation, that validation won’t work for whatever changes we would add in the pre-operation. There is no going back in that sequence above.
Imagine we had a plugin that would not allow any changes to the description field on the account entity:
Here, I have created two steps.
Everything looks right – I’m getting an error message when trying to update description field on the account form:
But, if I don’t update description field manually, and, instead, update some other field just so Pre-Operation plugin would kick in.. that plugin would have absolutely no problems updating the description field:
That’s exactly because those changes would happen after the validation step. Actually, the same may happen if we do these validations in the pre-operation if we configure incorrect execution order on the steps.