Posted on November 24th, 2010 – by Jan-Willem Cobelens
The last couple of weeks have been like a roller coaster. I was lucky enough to visit the Microsoft road show on CRM 2011 in Amsterdam ánd attend the extreme 2010 conference in Las Vegas. Both were very interesting and inspired me to take a look at some of the new features.
One nifty feature is the use of field level security (FLS). As you all may know this functionality is only available for custom attributes, for now. If you really want to apply it on out of the box attributes, you might want to check this blog post (unsupported of course).
As described in the SDK it is rather easy to set up and use field security. It also tells us how such fields behave in the application.
“When you call Retrieve or RetrieveMultiple, the system evaluates if the caller or impersonated user has access to each retrieved record (normal security process) and each secured field. The call does not throw an exception if the criteria contains secured fields for which the caller does not have access, instead, null values are returned for secured fields if they are part of the output Columnset.”
Unfortunately I found out that fields which have field security enabled can’t be accessed during bulk edit. In the example below I selected five contacts and clicked the edit button. In this case I can’t select the Yearly Income field, but it does not show read only like the Parent Customer field.
More “did you knows” are on their way.
Posted on October 13th, 2010 – by Jan-Willem Cobelens
For a CRM 4.0 implementation at one of our clients we had to create a lot of custom entities. Since we wanted to improve the usability for the users, we decided to customize the sitemap. With the help of the SDK SiteMap Overview (http://msdn.microsoft.com/en-us/library/cc150833.aspx) and the related subjects, a nice layout was constructed.
However the sitemap did not work… 
Having checked the XML over and over again, and even asking a Microsoft consultant for advice (who happened to be in the same room) I was lost.
It turned out that the “ShowGroups” attribute needed to be set in the Area Element. It is described in the SDK (http://msdn.microsoft.com/en-us/library/cc150877.aspx), but we totally forgot.
So when customizing the Sitemap, remember to set the ShowGroups to ‘true’, it can save you a lot of frustrations.
<Area ResourceId=”Area_Sales” Icon=”/_imgs/sales_24x24.gif” DescriptionResourceId=”Sales_Description” ShowGroups=”true”>
Posted on October 7th, 2010 – by Huib Aarts
It took me too long to figure out how to put my extensive JavaScript code into the ISV.config xml. Eventually it worked, but a far more easier way is to trigger the JavaScript, is to put a function name in the xml file and put the contents of the function in the onLoad of your form. As I reminder to myself, I stored it over here.
(In case the ISV button is not placed on the a form, but for example on a view, than you still have to put the JavaScript into the xml file.)
Here is a xml example of the ISV.config part:
And the onLoad script example:
Function_onclick = function()
{
alert('Button has been clicked');
}
Loading ...
4.0 Implementation Guide
