Month: Mar 2015

When an assumption is made that something very basic, can be easily configured using OOB functionalities, that is when I find myself stuck occasionally and having to rethink on how to implement a feature. I recently had one such experience. The requirement was to allow users in certain security role, to delete opportunityproducts, but not opportunities.My first thought was to use security role, to modify the permissions for opportunity products. To my surprise, I was unable to find opportunity products in Security Role.

It turns out Opportunity Product, Invoice Product, Quote Product and Order Product share a unique trait: they don’t have separate permissions and use the permission of their parent. Such being the limitation, I could implement this using ribbons or plugins. I implemented this using ribbon. Here are the steps

Grant Delete permission on the Opportunity entity for the appropriate security role

I did this on a CRM2011 organisation, but the process in same for a CRM2015 organisation. You’ll just be editing the command bar instead of the ribbon. Here are the relevant buttons in CRM2015, whose command you’ll need to edit.

I had recently to deploy one, the other way around: from CRMOnline to a CRM2013 instance. In my case the solution contained only html, png and Javascript webresources.

The entity dependencies for the solution, were already present in the CRM2013 organisation. The CRM2013 organisation was on SP1 UR1 (6.1.1). Refer to https://support.microsoft.com/en-us/kb/2917899 if you are on a higher/lower rollup and modify the version number appropriately.In order to import the CRMOnline solution I had to

You are attempting to create a user with a domain logon that is already used by another user. Select another domain logon and try again.

The strange thing I noticed about the error is that, the user I was trying to add was not already there in CRM. I checked this in the SystemUser table and confirmed that it is definitely not there. After tracing SQL Server, I found CRM uses SystemUserAuthentication table to do this check.

In my situation, the error started happening after I restored the organisation db from the backup. At the time of the backup, the user I was trying to add had not been created. After the organisation db was restored from backup, the SystemUser table in the organisation database does not contain User A, but the MSCRM_CONFIG does (as per SystemUserAuthentication). This is the root cause of this error message.

The fix was to delete the organisation and re-import the organisation from the Deployment Manager. Once this is done, the new user can be added without any issue. This was the additional step I had to perform after I restored the db from the backup.