Nishant Rana

Account Search based on account name through a ribbon button on account grid in CRM 2011

Hi,

Just created a simple managed solution that will show a button on Account’s grid. It will only get enabled when only one record is selected in grid otherwise it would remain disabled.

For that we can use SelectionCountRule in our EnableRule definition.

On click of button we are calling a JavaScript function and passing guid of the record selected using CrmParameter as the part of JavaScriptFunction Action.

The JavaScript function uses that guid, makes a OData call and retrieves the account name and passes that account name as a query parameter to google search url and uses window.open method to open the page.

RibbonDiffXml for that:-

<RibbonDiffXml>
        <CustomActions>
          <CustomAction Id="MyOrg.CustomAction" Location="Mscrm.HomepageGrid.account.MainTab.Collaborate.Controls._children" Sequence="1">
            <CommandUIDefinition>
              <Button Id="MyOrg.Button" ToolTipTitle="Search in Google" ToolTipDescription="Search detail of the account selected" Command="MyOrg.Command" Sequence="1" LabelText="Search in Google" Alt="Search in Google" Image16by16="$webresource:new_search16" Image32by32="$webresource:new_search32" TemplateAlias="o1" />
            </CommandUIDefinition>
          </CustomAction>
        </CustomActions>
        <Templates>
          <RibbonTemplates Id="Mscrm.Templates"></RibbonTemplates>
        </Templates>
        <CommandDefinitions>
          <CommandDefinition Id="MyOrg.Command">
            <EnableRules>
              <EnableRule Id="MyOrg.EnableRule"></EnableRule>
            </EnableRules>
            <DisplayRules />
            <Actions>
              <JavaScriptFunction Library="$webresource:new_search" FunctionName="search">
                <StringParameter Value="Guid Selected"></StringParameter>
                <CrmParameter Value="SelectedControlSelectedItemIds"></CrmParameter>
              </JavaScriptFunction>
            </Actions>
          </CommandDefinition>
        </CommandDefinitions>
        <RuleDefinitions>
          <TabDisplayRules />
          <DisplayRules />
          <EnableRules>
            <EnableRule Id="MyOrg.EnableRule">
              <SelectionCountRule AppliesTo="SelectedEntity" Maximum="1" Minimum="1"></SelectionCountRule>
            </EnableRule>
          </EnableRules>
        </RuleDefinitions>
        <LocLabels />
 </RibbonDiffXml>

JavaScript:-

function search(message,value)
{
var  Id = value;
var serverUrl = Xrm.Page.context.getServerUrl();
var ODataPath = serverUrl + "/XRMServices/2011/OrganizationData.svc";

var retrieveAccountReq = new XMLHttpRequest();
retrieveAccountReq.open("GET", ODataPath + "/AccountSet(guid'" + Id + "')", false);
retrieveAccountReq.setRequestHeader("Accept", "application/json");
retrieveAccountReq.setRequestHeader("Content-Type", "application/json; charset=utf-8");

retrieveAccountReq.onreadystatechange = function () {
  retrieveAccountReqCallBack(this);
 };

retrieveAccountReq.send();
}

function retrieveAccountReqCallBack(retrieveAccountReq) {

  if (retrieveAccountReq.readyState == 4) {
  if (retrieveAccountReq.status == 200) {

 var accountName = eval('('+retrieveAccountReq.responseText+')').d.Name;
 window.open("http://www.google.com/search?q="+accountName);
}
  else {
     alert("Call Failed.");
  }
 }
}

The managed solution:-

https://nishantrana.me/wp-content/uploads/2011/10/accountsearch_1_0_0_0_managed.doc

Just change the extension to zip from doc.

Hope it helps!

Field Security in CRM 2011 – New Features.

Hi,

Field Security in a new out the box feature in CRM 2011. The most important thing to know about it is that Field Security doesn’t work on out of the box attributes. It only supports custom attributes on system entity or custom entity.

Let us open one of the out of the box fields on Contact entity from customization area.

As we can see the radio buttons for Field Security are disabled. However there is some unsupported way to get that enabled for out of the box attributes

http://weblogs.asp.net/gayanperera/archive/2010/11/02/crm-2011-field-level-security-for-oob-attributes.aspx

Let us create a custom field named “Password” (text) in our contact entity and enable field level security for it.

Dragging it to the form shows a “key” symbol beside it.

If a user with System Administrator role opens the record, he would be able to view, add a value and update the value for the password field.

If a user with role other than system administrator opens the same record, this is what he gets to see

The field level security is governed through Field Security Profiles.

Opening Field Security Profiles we can see that the System Administrator is already added over there.

If we try to delete it, we get the following error message.

We can add users and teams to security profile.

The specific points to remember about the System Administrator Security Profile are following

It has System Administrator user account added by default.
Has all the field permission set to Yes for all security enabled fields.

Any user or team with System Administrator role automatically gets added here, and these automatically added user or team cannot be removed. However it can have other users or team also added to it, which can be removed.

“Users who do not have the System Administrator Security Role have no permissions on secured fields unless the users are added to a Field Security Profile (either directly or through team membership). Any user who has no permissions on a secured field will still be able to see the field on a form or in field selection lists for a view, but will not be able to see or change the data in the field. On a form, the field will appear with dots in place of any data.”

Talking about field permission, there are three field level permissions.

Read, Update and Create. They are independent of each other i.e. it is not necessary to have read permission to have update permission.

To understand it more clearly let us create new security field profile named “Test Security Profile”, add a user (test user) other than System Administrator to it. By default the field permissions would be set as No.

Let us edit it and set Read as Yes.

Now on opening the contact record with the test user who has been added to this profile, we can see the following changes now

The value of the password field is visible to the user. But it is disabled so can’t be edited. It remains disabled in case of new record as well.

What if we set Yes for Allow Update and No for Read and Create?

In that case, the field appears blank but it is editable.

If we update the field with some value, after save the field again goes blank.

However for the System Admin user we can see the updated value.

Now let us look at how Field Security and Security Roles apply.

Suppose user A has read access to records of a particular Entity record, and then we create a Security Profile that has Read and Update set as Yes for a particular field for that entity and add the user A to it. Here User A would not be able to edit the field because of the restriction put by Security Role.

One thing to remember is that through Field Security Profiles we won’t be able to increase the access of user then what he has got through his security role.

Suppose user A shares a record with user B and gives him Read access. The user B is also part of a security profile that gives him read and update access on a particular field for that entity’s record. Here the User B will be able to see the value of that particular field as he has been given Read access by user A through sharing but he won’t be able to update it.

There is one more thing we should be aware of i.e. Sharing Secured Fields just like sharing records.

We can add user or team with whom we want to share the secured fields. Here we can only set Read and Update, no Create because to Shared Fields apply for Shared Records which are already created.

By share secured fields, permissions granted through sharing can be selectively reduced for secured fields.

“Connie shares a contact record with Patricia. The share permissions are read and write. Patricia also has read and update permissions on a custom field in the entity. When Patricia views the form for the record, she finds she can change the custom field. Connie then adds an entry in Share Secured Fields for the record that grants Patricia only read access to the custom field. Now when Patricia views the form, she cannot update the custom field. It also allows permissions to be increased over those granted through Field Security Profiles” (from Microsoft’s CRM 2011 training material)

It also allows permissions to be increased over those granted through Field Security.

“Jose shares a record with Chris, granting read and write share permissions. Chris has no access to a secured field through any Field Security Profiles. When Chris views the record in the form, he cannot change the value of the secured field. Jose then adds an entry for Share Secured Fields granting Chris update permissions on the secured field. Chris can now change the value of the secured field on the record.” (from Microsoft’s CRM 2011 training material)

A record does not have to be shared with a user in order to grant shared secured field permissions.

The permissions required to share fields can be set on the Business Management tab of the Security Role under Field Sharing.

Hope it helps.

Data Audit (Auditing) in CRM 2011 – New Features.

Let us take an example,

Suppose we have created a new organization and we want to enable auditing on “Topic” field of Lead what do we need to do here?

First to enable auditing let us open the field for customization.

There we can see that it is already enabled for auditing. However below we have warning icon that tells us that “This field will not be audited until you enable audition on the entity”.

That means we need to first enable it for our lead entity. So let us open our lead entity for customization.

For the entity it is not enabled by default, we need to check the Auditing checkbox to enable it. However there we again see a message below that asks us to enable auditing for the organization first.

On checking the Auditing checkbox,

we get a note over there that tells us that by default auditing will get enabled for all the fields.

But we want auditing for only the topic field, and obviously we are not going to open each field and disable auditing there. So what can we do here?

Here we can select all the fields from our customization area and click on edit button to open the dialog box that will allow us to bulk edit the customization information for them.

So let us first disable it for all fields and then select those fields for which we want to enable it. Remember to click on Next to select all the fields on each page and disable them.

While doing so we might get this error

What it means is that Auditing cannot be set for some fields. (Not Applicable)

Following are the fields in lead entity to which audit is not applicable

Mostly it would be GUID fields, fields internally used by CRM, CreatedOn, ModifiedOn etc.

Now let us go back and enable Auditing system wide,

Check Start Auditing and Click Ok button to close the dialog.

Now let us change the topic field in our lead record and check its audit history. (From the left navigation pane of the record’s form)

Apart from change in the name of the topic we can see one more record in our Audit History that shows when the Audit was enabled for the Entity.

Right now we saw record level auditing, we can also see the system wide auditing. For this we need to go to “Audit Summary View”

Opening the record will give us more detail

Now I log in with another user having Sales Person role,

I don’t see Audit History link on left navigation pane.

And from settings, I get the message the I don’t have enough permissions.

So here we have four permissions related to auditing.

We understand Audit History and Audit Summary, let us check Audit Partitions, for this click on Audit Log Management.

Here each audit log stores audit records for one calendar quarter. If we try to delete log with serial number 2, we get the following message

i.e. only the oldest partition can be deleted, the current active partition cannot be deleted.

Now the question is what all things we can audit apart from change in the record’s field?

Changes to security roles:-

I have enabled auditing on Security Roles entity, and now I go and change the Access Level of Sales Person role on View Audit History privilege. So that should be tracked now…

Now as the Security Role entity doesn’t have a form similar to our other entities, I expect to see the audit for it in “Audit Summary View”. Let us open it.

It does have record for our access level change, let us open it

Changes to Shared Privileges of a record:-

Ok so now I opened a lead record and shared it with the other user, so that should be audited?

Yes it is there. Let us open it

Audit changes at attribute, entity and organization level: –

Now let us try disabling audit for the entity, and open the audit history

It says that entity/attribute audit has stopped; now let us open the last Share log

So by disabling the audit we will lose our old information as well.

Deletion of Audit logs:-

Let us delete audit log from Audit Log Management, and check the audit summary view. It is being logged.

N: N association or disassociation of the records:-

Let us create a new N-N relationship between lead entity and one of our custom entities (name G), and then associate there records. We can see one entry in our Audit History for that event.

On opening the record we can get the details.

Here as we have not enabled auditing on the G Entity (our custom entity) we won’t see any audit information there in its Audit History link.

Now let us find out what happens in the case of 1-N relationship.

For this delete the existing N-N relationship between lead and custom entity, and create a new N-1 relationship between lead and the custom entity g. so that our custom entity appears as a lookup in lead entity.

Now let us open any of the lead record and set value for our lookup there.

On doing so we can see a new event update being added to our audit history.

However we can’t see old value new value there as we have not enabled that field for auditing. So let us open that field from customization area and enable auditing for it and change the lookup value in the lead entity.

Now if we update the lookup we can see the old value and new value both.

Hope it helps.

Custom Ribbon Button to get the Guid of the record in CRM 2011

Update :- Works for CRM 2013 as well.

Hi,

Normally to get the guid we need to click on “Copy a link” button and then get id from the url, so just thought of creating a custom button that only copies the guid.

Clicking on Get Guid button will copy the id to the clipboard

RibbonDiffXml:-

 <RibbonDiffXml>
    <CustomActions>
      <CustomAction Id="Sample.all.form.GetGuid.CustomAction"
                    Location="Mscrm.Form.{!EntityLogicalName}.MainTab.Collaborate.Controls._children"
                    Sequence="75">
        <CommandUIDefinition>
          <Button Id="Sample.{!EntityLogicalName}.form.GetGuid.Button"
                  Command="Sample.form.GetGuid"
                  Sequence="61"
                  LabelText="$LocLabels:Sample.all.GetGuid.LabelText"
                  ToolTipTitle="$LocLabels:Sample.all.GetGuid.LabelText"
                  ToolTipDescription="$LocLabels:Sample.all.GetGuid.ToolTip"
                  TemplateAlias="o2"
                  Image16by16="/_imgs/ribbon/copyshortcut16.png"
                  Image32by32="/_imgs/ribbon/copyshortcut32.png" />
        </CommandUIDefinition>
      </CustomAction>
    </CustomActions>
    <Templates>
      <RibbonTemplates Id="Mscrm.Templates"></RibbonTemplates>
    </Templates>
    <CommandDefinitions>
      <CommandDefinition Id="Sample.form.GetGuid">
        <EnableRules>
          <EnableRule Id="Mscrm.FormStateNotNew" />
        </EnableRules>
        <DisplayRules />
        <Actions>
          <JavaScriptFunction FunctionName="getGuid"
                              Library="$webresource:new_formActions" >
            <CrmParameter Value="FirstPrimaryItemId" />
          </JavaScriptFunction>
        </Actions>
      </CommandDefinition>
    </CommandDefinitions>
    <RuleDefinitions>
      <TabDisplayRules />
      <DisplayRules />
      <EnableRules />
    </RuleDefinitions>
    <LocLabels>
      <LocLabel Id="Sample.all.GetGuid.LabelText">
        <Titles>
          <Title languagecode="1033" description="Get Guid" />
        </Titles>
      </LocLabel>
      <LocLabel Id="Sample.all.GetGuid.ToolTip">
        <Titles>
          <Title languagecode="1033" description="Get the guid of the current record." />
        </Titles>
      </LocLabel>
    </LocLabels>
  </RibbonDiffXml>

Download the managed solution here ( Change the extension to zip from doc).

https://nishantrana.me/wp-content/uploads/2011/10/getguidapplicationribbon_1_0_0_0_managed.doc

Hope it helps.

Adding the existing Add Notes button to Actions Tab for Incident Entity Ribbon in CRM 2011

We had a requirement to add the Add Note button to Actions tab for incident entity.

Location="Mscrm.Form.incident.MainTab.Actions.Controls._children"
Defines the location where we want to add the Add Notes button.

Below is the RibbonDiffXml we used to achieve that.

<RibbonDiffXml>
<CustomActions>
<CustomAction Id="MoveAddNoteCustomAction" Location="Mscrm.Form.incident.MainTab.Actions.Controls._children" Sequence="1">
<CommandUIDefinition>
<Button Id="Mscrm.Form.incident.AddNote" ToolTipTitle="$Resources:Mscrm_Form_Other_Related_Document_AddNote_ToolTipTitle"
Sequence="1"
ToolTipDescription="$Resources(EntityDisplayName):Ribbon.Tooltip.AddNote" Command="Mscrm.AddNoteToPrimaryRecord"
LabelText="$Resources:Ribbon.HomepageGrid.Add.Document.AddNote" Alt="$Resources:Ribbon.HomepageGrid.Add.Document.AddNote"
Image16by16="/_imgs/ribbon/AddNote_16.png" Image32by32="/_imgs/ribbon/noteyellowadd32.png" TemplateAlias="o1" />
</CommandUIDefinition>
</CustomAction>
</CustomActions>
<Templates>
<RibbonTemplates Id="Mscrm.Templates"></RibbonTemplates>
</Templates>
<CommandDefinitions />
<RuleDefinitions>
<TabDisplayRules />
<DisplayRules />
<EnableRules />
</RuleDefinitions>
<LocLabels />
</RibbonDiffXml>

Hope it helps.

Custom Entity in CRM 2011

Hi,

Let’s first start with the Entity Definition

Display Name, Plural Name, Description are the properties that can be changed at any time in the future.

Name and Ownership cannot be changed once the entity is created.

If we check Define as an activity entity check box,

Ownership drop down becomes disabled i.e. Activity entities cannot be organization owned.

We can additionally specify if we want this entity to be displayed in the Activity Menus along with other activities.

These options cannot be changed once set i.e. if we have defined the custom entity as activity entity we won’t be able to change it back or if we have unchecked Display in Activity Menus option while creating the entity and then we decide later to enable it, we won’t be able to do so.

For activity type custom entity, we can’t specify the area where they can be displayed (expect the Activity Menus)

Notes, Connections and Queues will be automatically enabled.

We can enable Document Management, Auditing, Duplicate Detection etc. on the custom Activity Entity.

For our non-activity type Custom Entity, we can set the following options

Areas where we can want to display them; this can be changed anytime in the future.
Mail Merge, Document Management, Duplicate Detection, Auditing, Mobile express, Reading Pane in Outlook, Offline Capability are the options that can be changed, i.e. enabled\disabled as required.
Notes, Activities, Sending Email, Connections and Queues: – These options once enabled cannot be changed\disabled later.