While you can’t ordinarily log in as another user through the Dynamics CRM/365 front end, as a System Administrator it is possible to impersonate another user when making calls to the CRM API. This is very useful if you want to be able to do the following:
For example, if you have complex security rules involving automatic sharing of records with certain privileges, this can be very time-consuming to test through the CRM front end. Writing an integration test where a record is created by one user, and then the permissions on this record can be immediately checked for another user, is very simple using impersonation. As another example, we recently had a support issue where a team were all using a personal view created by one of the team. A few of the team were on holiday and no-one knew who had originally created the view. It was straightforward to cycle through a list of users in a particular team and list the personal views to which they had access and who the views were created by. This information is not readily accessible through the front end, nor through the API without being able to switch users, but using impersonation it was very easy to retrieve the information needed. Here is an example which works in LINQPad but which you can easily amend to work in a Visual Studio project. The code logs in with a Sys Admin account and retrieves the detail of a user and then switches the CallerId property of the organisation service to that of another user. That's all it takes to impersonate another user. Here is a LINQPad script of the above code.
For fairly obvious reasons, it is not possible to change the caller id to that of a user who is disabled, or to a user who has no security roles. Such a user would not be able to make any API calls, so there would be no point in doing so anyway.
0 Comments
Leave a Reply. |
Archives
July 2021
Categories
All
AuthorSome stuff about me! |
Proudly powered by Weebly