Changing Microsoft CRM Dynamics 4.0 Encoding
Recently I worked on a project involving Microsoft CRM Dynamics 4.0 and because the application was in french we decided to change the encoding from UTF-8 to ISO-8859-1 which is quite simple to do but we ended up with a lot of problems...
If you change the encoding of the CRM in the web.config (globalization tag), CRM will then start to show you weird things (horrible characters) instead of accents. The reason is simple, if you convert a text (containing accents) from an encoding like ISO-8859-1 (or Windows-1252) to URF-8 all the accents will be replaced with fucked up characters, leaving normal non-accentuated characters intact.
I discovered that CRM seems to have parts that are always running under UTF-8 instead of following the encoding in the web.config file, so this cause a constant-encoding-converting-glitch. I did not found a solution to solve those CRM glitches so I decided to come back to default CRM encoding: UTF-8.
Beeing in UTF-8 causes convertion problems to the files I add to the CRM (.js - JavaScript). Because my files I create are in Windows-1252 (default), when CRM flush them to the client, they get "converted" and so the accents are beeing mashed up, this causing IE to not load those .js files. The only solution for this is to manualy change the encoding of the .js files to UTF-8 so that they don't get converted automatically.
Conclusion
Never change the CRM encoding; let it to UTF-8 and adapt your stuff.
Microsoft Dynamics CRM 4.0 tabSet list
As I explained in another article, when you want to retrieve to name of the entity displayed in a CRM page it's easy to check for the etc parameter and then translate the number to a name by calling the MetaData service. But, as I also said, when you check for the page "areas.aspx", you don't have the entity number of the related entity... instead you get a tabSet parameter. The tabSet contains either the relationship name or a tabSet name...
Because the same related entity can have multiple tabSet names, I decided to list everything I found to simplify the job for you (I all got those using Fiddler and clicking on every link of related entities in CRM...).
| Area name |
Related entity name |
| areaActivities |
ActivityPointer |
| areaActivityHistory |
ActivityPointer |
| areaAsyncOperations |
WFProcess |
| areaRelationships |
CustomerRelationship |
| areaRelationship |
CustomerRelationship |
| areaContacts |
Contact |
| areaSubConts |
Contact |
| areaSubAccts |
Account |
| areaAddresses |
CustomerAddress |
| areaOpps |
Opportunity |
| areaOpportunities |
Opportunity |
| areaQuotes |
Quote |
| areaOrders |
SalesOrder |
| areaInvoices |
Invoice |
| areaService |
Incident |
| areaCases |
Incident |
| areaContract |
Contract |
| areaListsInSFA |
List |
| areaCampaignsInSFA |
Campaign |
| areaProducts |
Product |
| areaSubs |
Product |
| areaComp |
Competitor |
| areaComps |
Competitor |
| areaSalesLit |
SalesLiterature |
| areaItems |
ProductPriceLevel |
| areaContractLines |
ContractDetail |
| areaRoles |
Role |
| areaTeams |
Team |
| areaServices |
Service |
| areaResourceGroup |
ResourceGroup |
| areaResourceGroups |
ResourceGroup |
| areaUsers |
SystemUser |
| areaBiz |
BusinessUnit |
| areaResource |
Resource |
| areaUnits |
UoM |
| areaPrices |
ProductPriceLevel |
| areaMembers |
SystemUser |
| areaExistingProducts |
QuoteDetail
SalesOrder
Invoice |
| areaWriteInProducts |
QuoteDetail
SalesOrder
Invoice |
All this may save you some hours of clicking !
Retrieving the entity name or number from a CRM page URL
Recently I had to create an HttpModule that catch every call to a CRM page and inject some JavaScript code in it. The first the HttpModule does is to retrieve to entity name (or number) and instanciates a class that contains some information about the page (organization, page url, entity name, entity number, etc...). Normally it is easy, you can get the etc querystring parameter to get the number and then call the MetaData service to get the entity name. Sometimes the querystring parameter gets another name... it's not always etc: it can be "etc", "oType" or "iObjType".
Life will be too easy if everytime when want to get the entity number we just have to check for the querystring parameter... so Microsoft though about a more challenging way to get the entity number. You will face that if you catch the "areas.aspx" page. This page is the one that is called when you click a left navigation bar item (in an entity record).
Let's check some different URLs you can get in CRM :
For the entity form...
...of CRM entities
- http://crmserver/org/sfa/accts/edit.aspx (Account)
- http://crmserver/org/sfa/conts/edit.aspx (Contact)
- http://crmserver/org/activities/email/edit.aspx (Email activity)
...of user-defined entities
- http://crmserver/org/userdefined/edit.aspx?etc=#entity_number#
These looks very easy to understand and it's easy to retrieve the entity numer or name. You will have to hard-code the entity number or name in your code when you get CRM entities because the URL (page) tells which entity it is. For the user-defined, you simply get the "etc" parameter in the QueryString.
For the entity record list...
...of the activites, campains and cases
- http://crmserver/org/workplace/home_activities.aspx
- http://crmserver/org/ma/home_camps.aspx
- http://crmserver/org/cs/home_cases.aspx
...of anything else
- http://crmserver/org/_root/homepage.aspx?etc=#entity_number#
These looks also very easy to understand but you will notice that barely everything (including user-defined entities) are shown in the same page (homepage.aspx) so you will not have to hard-code a lot of thing. And now, for the entity relationship view (the one you get on the right side of the CRM entity form when you click on a left navigation bar item of the entity form)...
...of CRM entities
- http://crmserver/org/sfa/accts/areas.aspx?oId=[GUID]&oType=1&security=[number]&tabSet=areaContacts (Account showing related contacts)
...of user-defined entities (one-to-many relationship)
- http://crmserver/org/sfa/accts/areas.aspx?oId=[GUID]&oType=1&security=[number]&tabSet=account_new_myentityname (Account showing related new_myentityname)
...of user-defined entities (many-to-many relationship)
- http://crmserver/org/sfa/accts/areas.aspx?oId=[GUID]&oType=1&security=[number]&tabSet=areaaccount_new_myentityname (Account showing related new_myentityname)
This not sound very cool... the same querystring parameter (tabSet) can contains 3 different types of value... depending on whether the related entity is custom or built-in and if it is a one-to-many or many-to-many relationship... !
More horrible than this, for the same related entity (shown in different parent entity), the tabSet parameter will not be named the same way (but sometimes it is...). For example, if the related entity is a contact, the tabSet can be named "areaContacts" or "areaSubConts". Wow ! I don't have to tell you it has to be a lot hard-coded !
For the user-defined entities it is a lot more simple than this; the value in the tabSet is the relationship name. This is cool because you can query the CRM MetaData service and get both entities of the relationship. There's only a little twist with this... when you have a many-to-many relationship, the tabSet starts with "area"... I don't know why but MS decided to do it this way so we have to deal with it.
Because the tabSet parameter is a pain, I decided to write an article listing all the different tabSet values I've found in hour of clicking in CRM (because I didn't find it on the web).
CRM read-only fields don't get saved in the database
If you have some fields that are only informative fields that you populate yourself by JavaScript, normally you will set them to be readonly because you don't want your users to be able to edit the value. If you do so, your value will no be saved in the database. The main reason for this is because when you post a form in an HTML page with disabled fields, the disabled fields do not get posted. If you want their values to be posted, you need to enable them.
CRM offers you the ability to save the values of the disabled fields. There is a boolean property named ForceSubmit on each field of the form. You can set this property to true if you want its value to be saved.
crmForm.all.fieldname.ForceSubmit = true;