In one of our last projects we used an editable grid from Microsoft, but had a strange issue.
Read here how we detected and identified a missing privilege for editable grids.
During testing with an user account we found that the editable grid for a custom entity does not render. For admins is all fine.
This is how it should look.
This what it actually was.
First thing we’ve checked was whether someone has changed the form rendering mode because editable subgrids don’t work on legacy forms. But it was still correct set.
Also we checked the known editable grids limitations for fields from related entities, the state field, partylists, customer and composite fields. But there was no such field in the view.
Further we’ve checked the users security roles. They have a custom role, but it includes all privileges for the parent and child entity.
Next we proved what happens when we remove the editable grid control and use the read only version instead. As a result, everything was ok in the read only grid.
Now I had a look at the browser console and found an error . . . a few times.
As desperation act we gave the user the default sales person security role and were surprised that now everything worked fine.
Identify the missing privilege for editable grids
We compared the two security roles and identified the “prvReadRole” as origin of the issue.
It was set to “None Selected”. I assume it is needed by the editable grid control the check if the user has all necessary privileges to edit the records in his security roles.
Just as a little hint for the community because it took me two hours to find the resolution.
Editable subgrids wan’t be rendered with the legacy form rendering engine. It will show the normal read-only subgrid instead.
After an update to Dynamics CRM 18.104.22.1689 it happens that the “From” field of the email entity is permanently disabled / locked on all forms, even in the workflow-editor.
It seems as the updates deletes a part of the fieldsettings. But you can easily restore the settings.
- Create a new solution with the “From” field of the email entity in it.
- Export the solution, unzip it and open the customizations.xml.
- Find the tag:
- Replace it with:
- Save the customizations.xml and zip it again into the solution file.
- Upload and publish the updated solution.
All credits go to the people of the following threads. They found and tested the solution.
Anyone who has ever worked with the Dynamics CRM for Outlook client, is familiar with the procedure of email tracking. You press the “Track” button and the CRM client creates on an e-mail record on the CRM server which again resolves the recipient and sender addresses, and linked to the corresponding records. But what if I want to same more e-mail addresses?
Are e-mails tracked when the e-mail adress is noted in a custom field?
The entity “Contact” has by default already three e-mail address fields. So, I’ve created a custom field as the fourth e-mail field.
When creating your own e-mail address field, it is important that chooses the “e-mail” format. So the CRM know that it can search here for e-mail addresses. By the way is then performed a validation in this field and the e-mail address is formatted as a mailto link, so that your email client will directly open when you click it.
Next, I’ve created a contact record with four different e-mail addresses and wrote them a message to them and tracked it.
Conclusion to E-mail tracking with custom E-mail fields
In the following screenshot you can see that it works perfectly. All present and the new e-mail address field are actually assigned only by tracking to the contact, to set a regarding was not necessary.