Lately I’ve been hearing this word “It can’t be done” or “It’s not possible” all the time and it’s getting annoying, these words/phrases are poison to developers, especially young people who are just starting out their career, when all they hear is “can’t / not possible” it conditions them to think that way by default, it gets even worse when you get them in-front of customers and instead of thinking and coming up with a solution the default answer becomes “can’t” or “not possible”.
Let’s take a real word example using CRM 2011.
Today we were talking about field level security and couple of people said “It can’t be done for out of the box fields in CRM 2011”, “it’s not possible for out of the box fields”…this is simply not true, the Dynamics CRM team are a smart bunch of people that won’t hard code limitations like that, so to clear this up let’s open up SQL Management Studio and take a peek at the metadata.
Open up the MetadataSchema.Attribute table from *_MSCRM org database, filter on any attribute (eg: accountnumber)
By default the CanBeSecured* columns will be set to False, all you have to do is make these fields True, then you have the ability to enable/disable Field Security on the attribute.
So far so good, making progress…odds not looking good for the nay sayers…
The only other thing that’s left to do is to insert 2 rows into the FieldPermissionBase table, first row with ComponentState=2 and second row with ComponentState=0
|FieldPermissionIdUnique||has to be a unique guid for both rows|
|ComponentState||0 or 2|
|SolutionId||find the default solution or your solution id and use that guid|
|FieldSecurityProfileId||grab one from the FieldSecurityProfileBase|
|EntityName||mislabelled db column, it’s actually wanting the typecode of the entity, not the logical name|
|OverwriteTime||set to 1900-01-01|
|AttributeLogicalName||logical name of the attribute|
And the result
There we have it! Field Level Security on out of the box attributes. Next time consider saying “I don’t know” instead of “can’t”.