In our organization, we wanted that some of our users should not be allowed to close an opportunity. In the user roles we didn’t find this specific privilege. Hence, we removed the “AppendTo” privilege from the opportunity entity for the role of those users who are not allowed to close opportunities.
Thereafter, whenever that user tries to close an opportunity for which he does not have permission, he would get the following message of “Insufficient permissions”
Note: Having done the above privilege changes, this particular user would not be able to associate any type of activities with opportunities.
Inogic is a hub of like minded professionals who believe in innovativeness and are committed to putting our time and efforts to R & D on Dynamics CRM.We endeavor to share some of our work on this blog by introducing Tips, Tricks and products from our labs.
Monday, May 31, 2010
Wednesday, May 26, 2010
Call an Update on the Post Update event of an entity
Now everyone knows, this would result in a recursive loop. It is always preferred that in such cases, the attribute that needs to be updated should be added to the property bag in the Pre-Update event itself.
However, if you do come across a situation where you need to update an attribute on the successful update of another attribute of the same entity, you might want to check the “Depth” property that is available in the Plug-in context.
The Depth property stores the depth of the plug-in that is count of the call that has been made to the same plug-in. In case of our situation, when it calls itself the depth is incremented and we can break the recursion by check for Depth Count > 1.
However, if you do come across a situation where you need to update an attribute on the successful update of another attribute of the same entity, you might want to check the “Depth” property that is available in the Plug-in context.
The Depth property stores the depth of the plug-in that is count of the call that has been made to the same plug-in. In case of our situation, when it calls itself the depth is incremented and we can break the recursion by check for Depth Count > 1.
Tuesday, May 18, 2010
How to change top(n) rows command in sql server 2008
By default SQL allows editing of only 200 records at a time. In case you want to we edit more than 200 rows you can edit the setting for the count of rows to be edited. Here are the steps to make this change.
Goto Tools -->Options
Goto Tools -->Options
In the commands tab,
Monday, May 10, 2010
User Mapping Error while Importing Organization
While importing an organization into CRM, one may come across the following error message “At least the setup user needs to be mapped before this organization can be imported”.
For this issue follow these steps:
- Update “Accessmode” , “Setupuser” and “IsDisabled values in systemuser table.
Query to update:
Update SystemUser Set Accessmode=’0’, Setupuser=’0’, IsDisabled=’0
- Click Start, All Programs, Microsoft Dynamics CRM, and then click Deployment Manager.
- Click on “Import organization”
For this issue follow these steps:
- Update “Accessmode” , “Setupuser” and “IsDisabled values in systemuser table.
Query to update:
Update SystemUser Set Accessmode=’0’, Setupuser=’0’, IsDisabled=’0
- Click Start, All Programs, Microsoft Dynamics CRM, and then click Deployment Manager.
- Click on “Import organization”
Monday, May 3, 2010
Append v/s append to
Append and Append To are two privileges that most user are not very clear about regarding their functionality. In this article we try to explain the difference between “Append” and “Append To” Privileges and how it affects the user access.
Append and Append To basically deal with the entities that are parties to a 1:N relationship or N:1 relationship.
Append: When an entity has the lookup of another entity on its form. It is important that the user have the “Append” privilege on this entity so that it can set the values for the lookups on this entity. For eg: Contact has the lookup of Account on its form so here the user needs to have the “Append” privilege to be able to set the parent account.
Append To: When an entity is available as a lookup on another entity form. It is important that the user have the “Append to” privilege on the entity that is referred to in the lookup so that it can set the values for the lookups of this entity on any other form. For eg: Account has the lookup of primary contact. So here the user needs to have the “Append To” privilege to be able to set the Primary Contact for the Account.
Lets us take an example of Contact entity.
We have modified the Order Role and removed the “append” privilege to the Contact entity.
Append and Append To basically deal with the entities that are parties to a 1:N relationship or N:1 relationship.
Append: When an entity has the lookup of another entity on its form. It is important that the user have the “Append” privilege on this entity so that it can set the values for the lookups on this entity. For eg: Contact has the lookup of Account on its form so here the user needs to have the “Append” privilege to be able to set the parent account.
Append To: When an entity is available as a lookup on another entity form. It is important that the user have the “Append to” privilege on the entity that is referred to in the lookup so that it can set the values for the lookups of this entity on any other form. For eg: Account has the lookup of primary contact. So here the user needs to have the “Append To” privilege to be able to set the Primary Contact for the Account.
Lets us take an example of Contact entity.
We have modified the Order Role and removed the “append” privilege to the Contact entity.
When a user with this role logs in, they would find the Parent Account lookup disabled.
This is because the user does not have the “Append” privilege to the contact entity. So all the lookups on the contact form are Disabled.
Now we have modified the Order Role and provided the “Append” privilege for the contact entity and removed the “Append To” privilege from the contact entity.
The Primary Contact on Account is disabled.
This is because the user does not have the “Append” privilege to the contact entity. So all the lookups on the contact form are Disabled.
Now we have modified the Order Role and provided the “Append” privilege for the contact entity and removed the “Append To” privilege from the contact entity.
The Primary Contact on Account is disabled.
It means the lookup of contact entity will be disabled on all the entities if the “append to” privilege to contact is removed.
Hope this helps decipher the mystery behind “Append” and “Append To”.
Hope this helps decipher the mystery behind “Append” and “Append To”.
Subscribe to:
Posts (Atom)