Answer: It Depends

If the plugin is running pre-operation stage and is modifying the entity image that is input parameters before the platform operation occurs then it doesn’t matter if the user that caused the operation to occur has permission to update the secured field the plugin will still be able to modify the value. It also doesn’t matter the context in which the plugin was registered to run in the plugin registration tool. The following is simple example of modifying new_secretcode that is enabled for field level security. This code was run from a plugin registered on create of account in the pre-operation stage.

var context = serviceProvider.GetService(typeof(IPluginExecutionContext)) as IPluginExecutionContext;

var target = context.InputParameters["Target"] as Entity;

target["new_secretcode"] = "1234";

To dive a little bit deeper let’s explore what happens when a plugin runs in post operation stage and attempts to create a record and populate the value of a secured field. For this example, I’ve modified the plugin to create a new account anytime a contact is created. As part of that it gets an organization service that runs in the context of the user that caused the platform operation to run. When run by the administration user the plugin fires and creates the account without any problem. When the contact was created by a user that did not have access to update secret code you would see the following error:

Here’s the revised code that is running when a contact is created and attempts to create the account and update the secured field:

var context = serviceProvider.GetService(typeof(IPluginExecutionContext)) as IPluginExecutionContext;

var target = new Entity("account");

target["name"] = "test 3";

target["new_secretcode"] = "1234";

var sf = serviceProvider.GetService(typeof(IOrganizationServiceFactory)) as IOrganizationServiceFactory;

var service = sf.CreateOrganizationService(Guid.Empty);

service.Create(target);

The key line to pay attention to above is the CreateOrganizationService call that we pass Guid.Empty. Passing Guid.Empty instructs the method to give back an organization service configured to run in the context of the user. If instead we passed null to that method the organization service would be configured to run in the system context and the plugin would be able to update the secured field.

This is a valid dialog to see at this point, but not for why it is showing itself now.  The real purpose of this dialog is to inform you of a missing component, a dependency that is not included in your solution and if not already in the target organization will block the import of this solution.  As best I can tell what you are seeing above for this specific scenario is a bug…it shouldn’t be showing. 

The risk here is you get so accustomed to seeing it for system entities that aren’t an issue you might miss the real deal.  So stay focused look past the system entities and make sure you agree with what is on the list.  Which should be true components that you are dependent on.  By the way, one easy way to keep this list short is to build your solution as you go.  As you use existing components ,add existing of them to your solution.  If you create new components, create them from within the custom solution.  It makes for less work when you go to publish your solution in the future.

The security advisory can be found here.  The urgency around this is related to details being released at a security conference yesterday.

Keep in mind that the + after the item indicates that once you turn it on it can’t be turned off.

Sometimes the toughest part of learning a new version is forgetting old version habits!

Silverlight has always been a good fit for extending the Microsoft Dynamics CRM user experience.  CRM 2011 takes that a step further by providing first class support including the ability to host Silverlight content as web resources on the server.  Silverlight can be used for a little widget on a form to a full blown rich page of content.  In fact, we start out the book by talking about where it is a good fit and where it isn’t.

The Silverlight + CRM book takes the best parts of our Silverlight Jumpstart book and adds a ton of CRM specific content.  In fact I think its safe to say right now it’s the most CRM + Silverlight content found anywhere.  We cover everything from where Silverlight can be used with CRM to how to use OData and the WCF services to perform data and service actions.  You can read the full table of contents here.

If you’ve purchased one of our other books check your e-mail we sent you a really good discount.  If you haven’t bought one of our books or are just too lazy to look in your email here’s some codes to help you along as well.

You can find the book site at http://www.silverlightpluscrm.com

Finally, I know a number of you have been asking me about updates to our full CRM book CRM as a Rapid Application Development Platform. We have been crazy busy working on that as well. In fact, last night was another late night!  Part of what takes so long is not just updating content but making sure we cover new CRM 2011 features.  Got ideas for either of these books of stuff we should cover?  Send it over but only if you don’t mind if we write about it!

Next, I setup the response detail and choose a response type of Option Set.  First of all, don’t confuse choosing Option Set here with anything to do with the Contact entity that has a real OptionSet attribute on it for the contacts favorite color. There is not currently anyway that you can pull those values  and reuse them here to avoid duplication.  Trust me I’ve suggested that be changes so hopefully we will see it in the future where you can simply reuse the values!

Notice that the Data Type is set by default to Text.  This is where a lot of people fail to make the important change.  You must set this to integer if you want to have any luck ever assigning the value collected to an OptionSet field on an entity.  Another great reason to make sure you change it right away is the fact that you can’t change it after the prompt and response is saved unless you delete it and start over.  You have been warned!

In the mean time you need to setup your favorite colors using the Response Values section of the form as you can see below.

So for our example we’ve added Red, Green and Blue or RGB!  The Value field on the right is really important if you are trying to collect values that will be used to set OptionSet values on an entity if that is the case these values must match the values of the attribute OptionSet.  So for example  they may be like 100,0001 or some large number to keep them unique if that is the case you MUST use the same values here if you ever expect it to work.

Once you take care of those two things using Dialogs to collect OptionSet values is possible.  Hopefully in the future Dialogs will be enhanced so we can reuse the OptionSet values from the global definition.  

What other features would you like to see Dialogs have?

After Mouse Over

See that little arrow to the right side of the Accounts item?  Click right there and you now see the following

So quickly you can Create a New Record, Go to a Specific System or Personal View and navigate to recently viewed records.  Those are all specific to the entity that you clicked on.  You can get global recently viewed and even pin them by looking here:

Notice the little push pin to the right of each item.  Using this you can pin them to the list.  This has the obvious use for the sales people to pin their 5 accounts they are assigned but it also can be used for any other record type so I think it has value for most people using CRM.

What’s your favorite feature in CRM 2011 that others might not have discovered?

The workaround is designed to track properties that are changed on an entity and only ship those to the server during a create or update.  Turns out, the work around doesn’t appear to send N:1 relationships to the server depending on how you set or modify the value of the property.

Imagine you have an entity Book and the Book Entity had a N:1 relationship to Contact and a attribute crmbook_contactid was created on the entity.  If you set the value of this like the following:

bookInstance.crmbook_contactid = new EntityReference {id=idValue,Contact.LogicalName};

You will find this won’t send the value to the server. If you are curious, the id and logicalname properties are marked as changed in the tracking of what is dirty, but not the crmbook_contactid property.  What I have found to work is the following:

First, Create the entity Reference

var myRef = new EntityReference {id=idValue,Contact.LogicalName};

Then set the value

bookInstance.crmbook_contactid = myRef;

Setting it this way I found properly triggered the change notification for crmbook_contactid causing it to be marked as dirty and sent as part of the create or update.

You probably know by now that if you build a plugin that runs in the sandbox it is running in partial trust.  In fact you might have even had it kill your plug-in when you executed it due to a security violation.  Many times its really obvious what is going on, and then other times like this one it might be elusive what the problem is.

This story started with building a new plug-in and trying to run it.  All it would produce was a simple “Security Exception” message on invocation.  No trace, nothing.  This started in on-line so I took it on-premise, tried it there same thing.  Checked tracing log, nothing useful.

I then tried to see if I could reproduce the exception outside of CRM.  The quickest way I found to get a partial trust environment was a simple console application – go to security settings and turn on Click Once, and set it for partial trust.  By default this is pretty locked down so you might find it too restricting but for some scenarios I think it might be helpful.  In fact it did identify one small thing that was wrong, but in the end I still got the same Security Exception message.

After gutting the plugin to nothing much left and still getting the error it was obvious I was missing something obvious.  What I failed to reproduce and/or check was the constructor getting called that took the config/secure config and in this case that was causing an exception, that exception ultimately hit some non sandbox friendly code in the constructor and killed the execution.  The net result was the simple Security Exception message with no other details.  So if you get that simple message – check your constructor.

Not all is doom and gloom, you can fix this by a few tweaks to the generated data context to ensure that when changes are posted to the CRM server that only the modified fields are sent.  You can find details and the code to add on the CRM team blog here.