Using Plug-Ins To Modify Views
I Wish…
I realise it has been a while since I last posted, but I have been mega-busy working with some of the top UK financial services organisations and selling Microsoft Dynamics CRM 2011 into various divisions such as business banking, corporate banking, wealth management and investment banking. Just from a personal productivity perspective, the latest version of our product is so much quicker to configure compelling demos, that I can now crank out a decent demo in less than half the time it took with CRM 4.0. What’s more the new features such as charting, dashboards, goal management, team-ownership of records are really resonating with Business Decision Makers (BDM) when comparing us against the competition.
I particularly like the new data import functionality, which combines the best bits of the CRM 4.0 data import and data migration tools and adds additional capabilities. It’s not perfect (e.g. no ability to import many:many relationship data), but hey, that’s why our product teams in the USA and India are flat out working on CRM v.next :-)
I wanted to share some of the more interesting pieces of the demos I have been working on, so I will start with a security requirement that cropped up recently.
The client, a corporate & investment banking (CIB) division of a large retail bank, was looking for additional security over-and-above the role-based security model of CRM 2011. They wanted the ability for the owner of a record (either an individual, or members of the owning team), to restrict access to that record simply by selecting a “Private” check-box on the form.
Obviously, adding a new field is simplicity itself, but what about the business logic? Looking back at one of my previous posts from October 2007, I achieved something similar when trying to restrict which queues would show up in any view. So I converted the code from VB.NET to C# and, pulled some sample plug-in code from the new SDK and put together a very simple solution.
Every time you access a view in CRM user interface, it causes the CRM platform to execute a query by raising a RetrieveMultiple request. A plug-in that intercepts this request, can modify the query before it is executed by the CRM platform, and this is exactly what I have done in the code below.
1: public class RetrieveMultiple : Microsoft.Xrm.Sdk.IPlugin
2: {
3: public void Execute(IServiceProvider serviceProvider)
4: {
5: // Obtain the execution context from the service provider.
6: IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
7:
8: // Get a reference to the Organization service.
9: IOrganizationServiceFactory factory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
10: IOrganizationService service = factory.CreateOrganizationService(context.UserId);
11:
12: // Get a reference to the tracing service.
13: ITracingService tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
14:
15: // Check that all of the following conditions are true:
16: // 1. plug-in is running synchronously
17: // 2. plug-in is running on the 'pre-stage' event
18: // 3. plug-in is running on the 'RetrieveMultiple' event
19: if (context.Mode == 0 && context.Stage == 10 && context.MessageName.Equals("RetrieveMultiple"))
20: {
21: // The InputParameters collection contains all the data passed in the message request.
22: if (context.InputParameters.Contains("Query"))
23: {
24: if (context.InputParameters["Query"] is QueryExpression)
25: {
26: // Get the QueryExpression from the property bag
27: QueryExpression objQueryExpression = (QueryExpression)context.InputParameters["Query"];
28:
29: // We can modify the original query to ensure that any record marked "Private" will only be visible to either
30: // 1. The owner of the of the record (if user-owned)
31: // 2. Members of the owning team (if team-owned)
32: ConditionExpression privateFlagCondition = new ConditionExpression()
33: {
34: AttributeName = "srh_private",
35: Operator = ConditionOperator.Equal,
36: Values = { false }
37: };
38:
39: ConditionExpression owningUserCondition = new ConditionExpression()
40: {
41: AttributeName = "owninguser",
42: Operator = ConditionOperator.EqualUserId,
43: };
44:
45: ConditionExpression owningTeamCondition = new ConditionExpression()
46: {
47: AttributeName = "owningteam",
48: Operator = ConditionOperator.EqualUserTeams,
49: };
50:
51: FilterExpression newFilter = new FilterExpression()
52: {
53: FilterOperator = LogicalOperator.Or,
54: Conditions = { privateFlagCondition, owningUserCondition, owningTeamCondition }
55: };
56:
57: objQueryExpression.Criteria.AddFilter(newFilter);
58: }
59: }
60: }
61: }
62: }
No matter what the original query, the QueryExpression object can easily be modified to filter out records where the “Private” flag is set, and the the user is not the record owner.
In order show this in operation, I developed a sample Call Report solution which you can download here. Once you have imported this into your CRM 2011 environment, please feel free to customise to your own requirements.
This posting is provided "AS IS" with no warranties, and confers no rights.