Mostrar datos de cualquier lista en la granja.

Como saben, las características nativas de MOSS nos permiten mostrar información de listas que se encuentren dentro de la misma colección de sitios, ya sea con la WebPart de Consulta de Contenido, desde SharePoint Designer con ListView y los orígenes de datos. Sin embargo, cuando intentamos mostrar información de listas que se encuentran en otras colecciones de sitios o aun en distintas aplicaciones, se complica el asunto. Lo mismo sucede con WSS que no cuenta con la WebPart de consulta de contenido, y no todos los usuarios están tan familiarizados con SPD, más aun, no todas las empresas

Para solucionar estos problemas existen WebParts de la comunidad, las hay de varios tipos, encontré tres de ellas que me pareció importante compartir con ustedes:

http://www.endusersharepoint.com/2009/09/16/aggregating-across-site-collections/

http://www.novolocus.com/2008/07/24/content-roll-up-options-conclusions/

http://blogs.infosupport.com/blogs/porint/archive/2006/11/14/WSS-v3-Solution-and-Feature-framework-applied-to-the-FlexListViewer-webpart.aspx

Son dos las opciones que me llamaron mas la atención:

FlexListViewerMoss (http://blogs.infosupport.com/media/p/10976.aspx)

Lightning Conductor Web Part (http://www.lightningtools.com/pages/lightning-conductor-web-part.aspx)

1. El primero es gratis y nos presenta la oportunidad de mostrar información de cualquier lista en la granja, inclusive puede mostrar directamente una vista, como una solución básica y flexible es de mucha ayuda.

2. La segunda es una WebPart de paga que es muy configurable y poderosa, cuenta con una versión de evaluación para revisar la funcionalidad de la misma.

Mi recomendación es que evalúen todas las posibilidades y al final decidan cual es la mejor opción para su ambiente, considerando si necesitan liberar estas WebParts al usuario, permitir que las personalice o bien solo desean mostrar información de una lista en un caso especifico, eviten un "overkill".

Posteriormente realizare un análisis mas exhaustivo de comparación para este tipo de WebParts.

Establecer permisos de Item en un receptor de eventos programaticamente parte 1

Supongamos que es necesario que cada item de una lista tenga permisos distintos dependiendo de campos especificos que el usuario llena a la hora de crear un item, por ejemplo en una lista de tareas donde queramos que las tareas sean visibles para todos si no estan asignadas a nadie, per que solo un grupo en especifico pueda editarlas, para esto podemos ayudarnos de un receptor de eventos que lea esta informacion y modifique los permisos del item de acuerdo al requerimiento.


El primer paso es el crear un receptor de eventos, puedes ayudarte con las extensiones para Visual Studio que cuentan con una plantilla para la generación de receptores de eventos, esta plantilla no es visible en la creacion de una solucion, solo esta disponible cuando agregas un elemento nuevo a la solucion ya existente. No entrare en detalles en este tema a menos que les interese en cuyo caso dejen sus comentarios.

Sea cual sea el metodo por el que creas el receptor de eventos este debe atrapar el evento ItemAdded, si utilizaste las extensiones solo debes de quitar los tags de comentarios ("//"), ojo, no quites los tags de la descripcion del evento ("///").

Ahora debemos ejecutar el codigo con privilegios elevados, ya explicare la razon de esto mas adelante:

SPSecurity.RunWithElevatedPrivileges(delegate() { using (SPSite miSitio = new SPSite(properties.SiteId)) { using (SPWeb miWeb = miSitio.OpenWeb(properties.WebUrl.Replace(miSitio.Url,""))) {

Con esto lo que hacemos es delegar todo nuestro codigo para ejecutarse con privilegios elevados, en base a estos privilegios obtenemos los objetos SPSite y SPWeb correspondientes al contexto en el que se ejecuto el evento, es muy importante que al crear el sitio lo hagan haciendo referencia al ID del sitio (properties.SiteId) y no lo tomen el sitio del contexto o el sitio como tal, ya que estos incluyen las credenciales del usuario actual; en caso de el SPWeb si solo utilizamos el metodo OpenWeb sin mandarle parametros tambien tendremos problemas con el tipo de credenciales que manejan, es por esto que se le envia la direccion relativa del subsitio actual (por eso se elimina el inicio de WebUrl ya que este incluye la direccion completa del subsitio).

Ahora que tenemos los componentes principales, podemos emepzar a obtener los datos que necesitamos:

miWeb.AllowUnsafeUpdates = true;

SPRoleDefinition RoleDefinition = miWeb.RoleDefinitions.GetByType(SPRoleType.Contributor);

SPListItem miItemActual = miWeb.Lists[properties.ListId].GetItemById(properties.ListItemId); miItemActual.BreakRoleInheritance(true);

miWeb.AllowUnsafeUpdates = true;

while (miItemActual.RoleAssignments.Count > 0)

{

miItemActual.RoleAssignments.Remove(0);

}

Explicando el codigo anterior lo que hacemos es permitir las actualizaciones en la web que obtuvimos (que es un requisito para ejecutar BreakRoleInheritance), despues obtenemos la definicion de rol de Contribuir, puedes cambiar este usando el enum SPRoleType, despues obtenemos el item asociado al evento (ojo aqui vuelvo a hacer referencia al ID de la lista y el item para obtenerlo, si haces referencia directa tendras problemas en el codigo).

En la siguiente parte explicare como crear definiciones de rol de uso.