Las ventajas de esta práctica son:
Tienen una distribución/dependencia que hace que los responsables de la granja de SharePoint no quieran que el correcto funcionamiento de sus sitios dependa de otros departamento. Por lo que (generalmente), en estos casos el resultado es que hay dos departamentos que se encargan de gestionar permisos, con lo que se duplican esfuerzos y se duplica la posibilidad de fallo e inconsistencia.
En muchos post hemos comentado que el desarrollo sobre SharePoint depende mucho del conocimiento sobre la plataforma. Para obtener un mismo resultado tenemos múltiples posibilidades, pero no todas las opciones son las adecuadas. Con el tema de los grupos/usuarios NO iba a ser una excepción. Recientemente ya hablé sobre la legibilidad de la propia API de SharePoint. En este caso, la problemática radica sobre los grupos a los que pertenece un usuario para realizar una acción u otra.
Tenemos una lista de noticias de nuestra organización que debemos de mostrar en la Home de la Intranet dependiendo del grupo a la que pertenezca un usuario. De tal forma que cuando el publicador añade una nueva noticia, indica al departamento/s a los que le interesa. En la Intranet disponemos de un grupo de SharePoint por cada Departamento de nuestra organización. A su vez, dentro de cada grupo de SP, hay un grupo de AD con los integrantes de dicho departamento.
Dentro del Contexto de SharePoint, disponemos un objeto que nos indica el Usuario que está autenticado contra SharePoint y con este objeto podemos obtener los grupos a los que pertenece dicho usuario. Con un código similar al siguiente:
SPUser currentUser = SPContext.Current.Web.CurrentUser; SPGroupCollection grpColl = currentUser.Groups;
Como podréis deducir este código no funciona o por lo menos no nos devuelve los grupos a los que pertenece este usuario. Si vamos a nuestro desarrollo, no visualizamos ninguna noticia. Si agregamos de forma individual a un usuario a un grupo con este mismo código, nuestro desarrollo ahora mismo funciona.
Los primeros pensamientos son como SharePoint se comporta Out of the Box con los grupos de AD y funciona tal y como esperamos. Es decir, si asignamos un permiso a un Grupo de AD, todos los usuarios que pertenecen a ese grupo tienen dicho permiso.
Ahora bien, ¿hay otra posibilidad para saber si un usuario pertenece a un determinado grupo?
La respuesta rotundamente es SÍ. Un ejemplo sería este código:
private IList<SPGroup> GetGroupsUser(SPWeb web)
{
IList<SPGroup> groupCollection = new List<SPGroup>();
foreach(SPGroup group in web.SiteGroups)
{
if (group.ContainsCurrentUser)
{
groupCollection.Add(group);
}
}
return groupCollection;
}
Pues seguramente algo que nos ha pasado en algunas ocasiones y es que hay varios grupos de desarrollo que no se hablan entre sí e implementan funcionalidad similar de forma distinta. Esto ocasiona no sólo que el código sea difícil de mantener, sino que funcionalidad igual de un resultado diferente. A la hora de desarrollar, siempre es un bueno seguir unas buenas prácticas y una buena comunicación en el equipo, para evitar fallos que son subsanables con hablar.
En la versión 2013 por lo menos si que lo es, ya que el funcionamiento de la API va en contra del funcionamiento por la propia interfaz. Con el cambio a la versión 2013, la forma de autenticación de cambio a claims posiblemente afectará a este método. Dado que ahora mismo no he tenido un entorno de 2010 para poder verificar este funcionamiento en otras versiones. Mi compañero Alberto Díaz dice que tenemos que tener en cuenta que SharePoint es un monstruo que ha ido evolucionando con multitud opciones desde su versión de 2003, pero también tenemos que ser conscientes de estos fallos para mejorar el producto y corregirlo 🙂
Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continuas navegando, estás dando tu consentimiento para aceptar las cookies y también nuestra política de cookies (esperemos que no te empaches con tanta cookie 😊)