El propósito de este artículo es hacer una demostración de aplicación de filtros en un campo lookup de SharePoint 2007. Para llevar adelante esta tarea trabajaremos con el proyecto de CodePlex llamado SharePoint Filtered Lookup Field que pueden acceder en este enlace: http://filteredlookup.codeplex.com/.
Las características descriptas en CodePlex para este proyecto son:
Un punto importante a tener en cuenta es que este tipo de columna es adicional a los ya existentes en SharePoint, no se trata de una mejora al campo estándar. Por lo tanto, si lo que se quiere es aplicar los filtros en una lista ya existente, se necesita crear un campo nuevo y copiar los datos desde el campo viejo. Luego se puede eliminar el campo viejo.
En este enlace se puede encontrar información sobre la licencia de este producto: http://filteredlookup.codeplex.com/license
A continuación se detalla el paso a paso de instalación y uso.
El proyecto está armado en un paquete de instalación de Windows que usa el instalador de soluciones de SharePoint. El primer paso es descargarlo desde: http://filteredlookup.codeplex.com/downloads/get/70292
Luego crear una colección de sitios de prueba y ejecutar el instalador:
Antes de empezar a utilizar el producto, verificar que esté correctamente instalado. Para ello crear una columna en una lista para verificar que exista este nuevo tipo de columna:
Probar con un ejemplo sencillo. En este caso existen dos listas:
La lista de tipo de Clientes posee 5 clientes, dos de ellos en estado inactivos:
Crear una vista que muestre únicamente los clientes activos:
En la lista de Temas Pendientes crear un campo fileteed lookup hacia la lista de Clientes, pero que únicamente muestre los clientes activos:
La configuración es tan sencilla como seleccionar la opción “Apply List View Filter” y luego elegir la lista de Activos.
Realizar una prueba: el primer paso es generar un alta en la lista de Temas Pendientes. Observar como sólo se muestran los 3 clientes activos:
Hacer clic sobre “Cliente 1” para probar su correcto funcionamiento:
Verificar qué sucede si Cliente 1 pasa a estado inactivo:
Al intentar modificar el tema pendiente que tenía asignado el tema 1, me permite modificar el registro con el Cliente que ahora está inactivo. Este era el funcionamiento que al menos yo esperaba:
Por supuesto si intento crear un nuevo tema pendiente, la opción de Cliente 1 ya no aparece:
Una prueba adicional es crear un vista que agrupe por este campo, para verificar que funcione de la misma forma que el campo estándar de SharePoint:
Ese proyecto de CodePlex permite agregar una funcionalidad muy necesaria en SharePoint, haciendo que las aplicaciones sean más amigables y permitan agregar algo de lógica de negocio. El producto funciona correctamente y es estable.
Personalmente, como contra le veo que utiliza un nuevo tipo de campo que no es el estándar de SharePoint, pero si pensamos que SharePoint ofrece la creación de este tipo de campos como forma de extender el estándar, no lo veo mal.
Por otro lado, el código fuente es público, lo cual siempre es importante, en caso que su autor discontinúe el mantenimiento del mismo o no brinde más soporte: http://filteredlookup.codeplex.com/downloads/get/70293.
También existe una versión para SharePoint 2010, que si bien escapa al alcance de este artículo su prueba de funcionamiento y su posibilidad de migración, da una idea de que es posible seguir usando el producto cuando cambiemos de versión: http://sp2010filteredlookup.codeplex.com/.
Es posible que estén experimentando este problema. Desde El Faro de Project Server nos llega una traducción y una explicación del workaround hasta que salga el parche oficial. Esto incluye desde limpieza de cache hasta modificación de registros en la BD Draft. Aquí el link:
Project Server 2010 incorpora la funcionalidad de flujos de trabajo como novedad. Esta funcionalidad se encuentra integrada con Project Server.
El flujo de trabajo para aprobar un proyecto y la creación del Gantt se integran naturalmente.
A modo de introducción, enumeramos los pasos que hay que seguir para poner en marcha un flujo de trabajo en Project Server 2010:
Los flujos de trabajo se asocian a un tipo de proyecto corporativo (EPT). Esto quiere decir que al elegir un tipo de proyecto, en el momento de la creación del mismo, comienza a ejecutarse el flujo de trabajo. Esto también quiere decir, que el proyecto debe ser creado desde PWA.
En Project Server 2010, los flujos de trabajo poseen fases y etapas. Esto es importante por varias razones, entre las que podemos nombrar:
· Se pueden analizar los proyectos, dependiendo de la etapa del flujo de trabajo en que se encuentran.
· Los campos que se completan durante el flujo de trabajo pueden variar su obligatoriedad dependiendo de la etapa del ciclo en la que nos encontremos.
Los campos personalizados corporativos estándar de Project Server, ahora pueden ser completados desde el flujo de trabajo. Esto hace más amena la carga de los datos e incluso puede ser escalonada. También puede ser que con el flujo de trabajo, podamos variar la obligatoriedad del campo, dependiendo del momento del flujo en que nos encontremos.
Las páginas de detalle de proyectos serán visibles en PWA para capturar la información de los campos personalizados. Permiten estructurar la información para que no se vea toda junta como en Project Pro. También es posible decir qué páginas estarán habilitadas en cada etapa del flujo. Además permiten manejar algunos campos no disponibles en Project Pro como el de texto de varias líneas que soporta hasta 4.000 caracteres.
Una vez que hemos definido todo lo anterior, que se hace vía parametrización, se necesita programar la lógica del flujo de trabajo. Esto se hace con programación en Visual Studio y puede incluir acciones como:
· La lógica del circuito, condiciones y bifurcaciones.
· Completitud de campos según valores que se capturan.
· Gestión de aprobaciones.
· Envío de mails.
Esta imagen nos muestras las distintas capas y la arquitectura. Se puede observar claramente como los flujos de trabajo de Project Server son una capa superior a los de SharePoint.
Fuentes de las imágenes: http://msdn.microsoft.com/en-us/library/ee767704.aspx
Vean este post de Juan Carlos en donde nos explica como manejar parámetros en cascada desde Reporting Services:
SSRS 2008 R2: Como crear parámetros con comportamiento en cascada a un informe!
Sí, esta posibilidad existe gracias a una herramienta. No dejen de leer el artículo de Juan Carlos para enterarse de los detalles:
SharePoint 2010: Migración de Reporting Services nativo a modo integrado con SharePoint!
