MSCRM - Plugins Run in User’s Context Option
When registering steps for plugins, you are given the option to select the user the plugin should run as.Your options are bascially calling user or any CRM system user for the organisation you are registering the plugin for. By running the plugin in the context of a user you take onboard that users privilages. For example, if you registered a plugin that creates an account within the context of calling user, and my user triggers the plugin, an account will be created in my name. However if my user doesn’t have permissions to create an account, but we need it to create an account on this trigger we have a slight problem. The plugin will fail creating the account! We can’t change my security roles to allow the creation of accounts as I should not be able to do this. So our only option is to run the plugin in the context of a user that can create accounts. So lets say we have an Administrator user that we will run in the context of. Well now we have introduced the problem that I actually want to talk about!
Our problem actually surfaces when exporting our solution (which contains our plugin & step) from one system to another system which has a different set of users. So if you create small CRM products and sell the exported solutions to the world of CRM you will experience this. Or, another example if you work on a development environment and export the final customisations on to your clients system you will also experience this issue!
The Problem
So the problem is that when importing a solution, CRM attempts to install the plugin steps against the users you have specified in the “Run in User’s Context” option. Now if these users don’t exist as CRM system users within the system you are importing into, CRM goes ahead with the import but falls back to installing the plugin step as calling user. What CRM is doing is perfectly valid, I would code the same fall back myself but it has potential to cause errors for us. Imagine our early situation where we wanted to always create an account on a specific trigger. Well this may fail now as our plugin that creates the account is running in the context of the calling user, and not all system users in our imported system can create accounts. So our plugin will fail and if we then have automation that is reliant on the creation of the account that will fail… fail fail fail… so on and so forth… see where I’m going with this.
The thing to watch out for is if CRM falls back within the import, the import still succeeds with a warning. If the person doing the import doesn’t notice or read the warning they won’t know the issue is lurking within their system ready to bite them in the arse at a plugins call notice! I can see this is a problem for a product that you may be selling to the masses on the Market Place. You can’t guarantee that the user importing the solution knows what he / she is doing with the import. They will probably just ok the import. What you can guarantee is that they will be ringing you up telling you your solution is broken :( .
In a scenario where we control the development environment and the clients we can make sure that system usernames within the two systems match (For the specified calling users anyway). I’m guessing the matching is done on the domain name + system user name. This means when we perform the import everything should match and import without any fall back. For database deployments through deployment manager we SHOULD be ok as we map users as part of the deployment process. If we don’t map users though we could have problems!
This is something to be aware of, ultimately manage it how you see fit.
From : Here
0 comments:
Post a Comment