Roles de un usuario a través de FilteredViews

Hay muchas cosas en el CRM que pueden recogerse a través de los propios métodos de los Web Services, pero que también pueden accederse a través del SQL Server de forma soportada (a través de las "FilteredViews").
Este ejemplo es una consulta SQL que nos devuelve los nombres de los Roles de un usuario determinado, en este caso "DOMINIO\usuario":

SELECT RB.Name FROM FilteredRole RB
INNER JOIN FilteredSystemUserRoles UR ON UR.RoleId=RB.RoleId
INNER JOIN FilteredSystemUser U ON UR.SystemUserId=U.SystemUserId
WHERE U.DomainName='DOMINIO\usuario'

Ahora bien, si queremos saber un poco más de sus permisos por ejemplo que nivel de acceso tiene de lectura en contactos (Rol de seguridad "prvReadContact"), podemos acceder a traves del SQL Server, pero ahora de forma NO SOPORTADA:

SELECT RB.Name, RP.PrivilegeDepthMask FROM FilteredRole RB
INNER JOIN FilteredSystemUserRoles UR ON UR.RoleId=RB.RoleId
INNER JOIN FilteredSystemUser U ON UR.SystemUserId=U.SystemUserId
INNER JOIN RolePrivileges RP ON RP.RoleId=RB.RoleId
INNER JOIN Privilege P ON P.PrivilegeId=RP.PrivilegeId 
WHERE 
U.DomainName='DOMINIO\usuario' AND P.Name='prvReadContact'

El atributo "PrivilegeDepthMask" dará un número con el nivel de acceso, donde por ejemplo "1" es a nivel de usuario y "8" es a nivel de organización.

Para un listado de los permisos recomiendo este enlace:
http://msdn.microsoft.com/en-us/library/bb955027.aspx

Un saludo!

Atención con los CustomerAddress utilizando DynamicEntity y FilteredViews

Lo ideal al desarrollar con aplicaciones para CRM, es utilizar las famosas "DynamicEntity".
De esta forma podemos realizar cualquier tipo de accion (crear, actualizar, etc.) con cualquier tipo de entidad.
Para formatear correctamente los valores, podemos acceder primero a los MetaDatos de los atributos de la entidad, para saber de que tipo es el registro, y asi crear dinamicamente los atributos de la entidad "Dinámica".
El problema surge con la entidad "CustomerAddress" en el atributo "objecttypecode". Este atributo es obligatorio y debe ser rellenado siempre para crear un registro de dirección. Al recoger el tipo del atributo, nos dice el CRM que es de tipo "Picklist", cuando en realidad es de tipo "EntityReference". Si intentamos crear una dirección pasando ese atributo como de tipo "Picklist", el CRM da un error y no nos lo permite.
Para solucionar esto hay que crear una propiedad de tipo "EntityNameReferenceProperty".
Para recoger el tipo del atributo hay que hacer:

RetrieveAttributeRequest atrreq = new RetrieveAttributeRequest();
atrreq.EntityLogicalName = "customeraddress";
atrreq.LogicalName = "objecttypecode";
RetrieveAttributeResponse atrresp = (RetrieveAttributeResponse)meta.Execute(atrreq);

Y luego verificar el valor de "atrresp.AttributeMetadata.AttributeType".

Nota adicional sobre la FilteredView: Si hacemos una consulta SQL en la vista "FilteredCustomerAddress", el atributo "parentid" que es la referencia a la Cuenta o Contacto relacionado con la dirección, no tiene el campo "parentidname" que deberia tener por ser un atributo de tipo "Customer".

Conclusión: mucho cuidado al trabajar con "CustomerAddress", que tiene cosillas que no son del todo "Dinámicas" como en el resto de entidades, y podemos encontrarnos cosas raras.

un saludo

FilteredViews y autenticación de SQL Server.

Como todos saben, la información de MSCRM está almacenada en una base de datos en SQL Server.
La forma soportada y documentada en la SDK de Microsoft CRM 4.0 de acceder a la información directamente en el SQL Server, es a través de unas vistas que son llamadas "FilteredViews".
Las FilteredViews, son vistas en SQL Server cuyo nombre contiene el mismo nombre de la entidad, con el texto "Filtered" por delante. Por ejemplo "FilteredAccount" para la entidad de "Cuentas".

Al SQL Server uno se puede conectar de dos formas, y con cada una de las mismas, las FilteredViews se comportará de forma diferente:

1) Autenticación integrada de Windows:
Al conectarse de esta forma, y al realizar una consulta, automáticamente resolverá con el usuario conectado, los roles de seguridad, idioma, desplazamientos horarios, etc.
Así, por ejemplo podríamos de esta forma hacer la siguiente consulta:

SELECT * FROM FilteredAccount

Las FilteredViews detectan el usuario del directorio activo conectado al SQL Server, y lo relacionan con el usuario correspondiente de CRM.
Esto lo realiza con una función en SQL Server que podemos probar de la siguiente forma:

SELECT dbo.fn_FindUserGuid 

2) Autenticación de SQL Server:
Al acceder mediante autenticación de SQL Server, las FilteredViews no pueden reconocer al usuario conectado, y si ejecutamos la consulta anterior, simplemente no devuelve nada, como si no se tuviese permisos para ver ningún registro.
Si nos conectamos de esta forma, y queremos hacer una consulta a las "FilteredViews" solo lo podemos haces "Impersonalizando" la consulta, es decir, ejecutando la misma como si fuesemos otro usuario.
Esto se puede lograr con la cláusula "EXECUTE AS USER=..." de la siguiente forma:

SELECT * FROM FilteredAccount EXECUTE AS USER='contoso\admin'

De esta forma, la consulta se realizará con los roles de seguridad y perfil del usuario que se determine.

Consultando información en el SQL Server

Uno de los temas que suelen surgir en las implataciones de MSCRM es el de como acceder a los datos directamente a través de consultas directas al SQL Server.
Para esto intentaré explicar la estructura de las tablas de SQL Server en MSCRM 4.0.
MSCRM 4.0 crea una base de datos por cada empresa por ejemplo "Contoso_MSCRM".
Allí, por cada entidad creará 2 tablas por ejemplo para Cuentas:

AccountBase: con todos los campos de sistema.
AccountExtensionBase: con todos los campos personalizados que añadamos.

Por encima de estas dos tablas, existe una vista: "Account", que ya nos devuelve todos los campos de las dos tablas anteriores. Además esta vista añade columnas que resulven nombres de las referencias añadiendoles el texto "name".

Acceder a las tablas fisicas, o a esta vista, son formas no soportadas de acceder a la información, y por lo tanto no deberían ser utilizadas si se quiere hacer un trabajo 100% soportado.

La forma soportada de acceder a la información es a traves de las "FilteredViews" que son otras vistas que crea MSCRM que para nuestro caso se llamará "FilteredAccount".
Esta vista no solo resolverá los nombres de las referencias (lookups) sino tambien resolverá los textos de los desplegables (picklists), resolverá los desplazamientos horarios en los campos de tipo fecha y adicionalmente filtrará la información segón los permisos que disponga el usuario que está realizando la consulta.

Para hacer todo esto, para consultar las FilteredViews será necesario conectarse al SQL Server a traves de una conexión mediante autenticación de Windows.

Este recuadro explica las diferencias entre cada una: