Views in Dynamics are based on the definition of a filter. Via a filter a query is in fact defined. However, the possibilities are limited when defining a filter. In this blog I will explain an approach with which it is possible to create more complex view filters. This approach uses a pre-operation RetrieveMultiple plugin, which modifies the view filter query before it is executed in Dynamics. In this way much more complex views can be created than is normally possible.
The case
In this example, we will create a dynamic view, which allows you to see a list of reports from the last 30 days, but should only show reports on topics you are interested in.
A report can be linked to 0 or more tags (N:N relationship), which can be used to indicate for a report which topics it is about.
You can also add tags to your own interests, to indicate which topics you are interested in (N:N relationship).
The approach
As said a view in Dynamics is nothing else than a query. When you, as a Dynamics user, use a view to look at certain records, a RetrieveMultiple call takes place in Dynamics where the filter query is given, executed and the found records are returned and shown.
The way we are going to make the view logic dynamic consists of the following steps:
- Defining the view filter, containing a certain specific condition
- Building a RetrieveMultiple plugin, which recognises the view filter from step 1 and adapts it
- Adding the plugin step, so the plugin will be used
Step 1: Definition of the view filter
In this step, we define the view filter (as System View, so it is available to all users). We include a dummy condition [Name Equals CallReportsOfInterestToCurrentUser] to make the filter query recognizable to our plugin to be built.
Step 2: building the plugin
In this step, we first create the plugin code:
The class QueryModifierFactory defines the modifier class to be used, which will modify the original query via the call modifier.ModifyQuery(query).
As a last step, we overwrite the original query input parameter with the (possibly modified) new query.
The QueryModifierFactory GetModifier method is relatively simple.
We check if the original query is a fetch query and if so, use the query XML to look for the text CallReportsOfInterestToCurrentUser (the dummy condition from step 1). If this text is found, a CallReportQueryModifier is returned that can describe the query. Otherwise, a NoModificationQueryModifier is returned, which does not modify the original query:
Now let’s look at the CallReportQueryModifier class, which modifies the query:
As you can see, the dummy condition, which we had added in step 1 only to make the view query recognizable for our plugin code, is first removed. Then the interest tags of the currently logged in user are retrieved and these tags are added to the query. LINQ-to-XML is used to modify the original query XML.
We then need to upload the plugin DLL into our Dynamics environment.
Step 3: adding the plugin step
Finally, we need to add a plugin step for the message retrieveMultiple, on the dp_callreport entity, during the pre-operation stage, because then the query can still be modified.
Voilà
And voilà, after this last step, our view created in step 1 is now dynamically modified by plugin code and expanded with the interest areas of the logged in user. In this way dynamic views can be created in Dynamics.