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!
When creating a plugin you have to try and cater for any possible issues that may occur. You want to handle these issues in a way that is acceptable to the browsing client. As there are many things which can go wrong, there are also many things we can do to handle errors. One way is to simply check our collection of attributes actually contains the attribute we are trying to access!
Typically a CRM system would capture data for a range of system users. Even though these users may be capturing the same type of data they may be entering it differently to each other. For example the same address can be entered in many different ways. CRM Codex’s Formatter allows text fields to be formatted in order to keep to a defined format. The formatter will work on an attribute-by-attribute basis, which can be specified by the CRM system customiser.