- Incluyendo la información de versiones
- Sólo registros en donde cambie el estado
- Utilización de SPListItemVersion para leer la información de versiones
- Generación de los datos en XML para poder conectar fácilmente Excel
sharepoint & project server
Sharepoint me proporciona seguridad y me hace sentir más fuerte. Las 10 cosas que más me gustan de Sharepoint.
Microsoft Project es quizá la herramienta de gestión de proyectos más conocida y utilizada por los líderes de proyectos...
Serie de artìculos que nos ayudan a incorporar diseño gráfico en las implementaciones de SharePoint...
Artículos publicados en la revista especializada en SharePoint: CompartiMOSS.
El objetivo de esta prueba es identificar y validar un método para mover un sitio dentro de la estructura de sitios sin perder datos de la historia.
Escenario:
El objetivo es subir un nivel en la estructura a NIETO sin que se pierda la historia:
No perder la historia incluye:
Para realizar esta prueba, creamos un ambiente con las siguientes características:
A partir de una colección de sitios existentes, creamos primero el sitio HIJO, heredando permisos del padre:
Luego creamos un sitio NIETO, heredando los permisos de HIJO. Obtenemos una estructura como la siguiente:
En este segundo paso, vamos a crear la historia del sitio NIETO:
Creamos una biblioteca de documentos y una lista de tareas.
A estas dos listas, les activamos el control de versiones:
Creamos un flujo de trabajo para la biblioteca de documentos. Es un flujo sencillo que tienes los siguientes pasos al momento de subir un documento:
Definimos las opciones del flujo de trabajo para que se dispare automáticamente al momento de subir un documento:
Trabajamos primero con el Documento 1:
La historia del flujo de trabajo muestra:
La historia del documento muestra la creación y una modificación posterior:
La historia de la tarea muestra la creación y la modificación cuando se ejecutó el flujo de trabajo:
Ajustamos la seguridad utilizando el siguiente criterio:
Para realizar el movimiento del sitio, vamos a trabajar con la opción Contenido y Estructura dentro de la Configuración del Sitio:
Dentro de esta opción, utilizaremos el comando Mover.
Una vez dentro de la estructura, veremos reflejada la actual jerarquía:
Abrimos la lista desplegable de NIETO y elegimos la opción MOVER:
Aparecerá un cuadro de diálogo para elegir el sitio destino, elegimos PADRE:
Presionamos aceptar y esperamos... Luego veremos reflejada la nueva estructura:
Lo primero que se observa es que NIETO ya no es hijo de HIJO:
Se observa que se mantuvieron las configuraciones de seguridad:
Al verificar el historial de versiones del Documento 1 se observan los mismos valores que antes:
Lo mismo sucede den el historial de versiones de la tarea:
En la siguiente pantalla se ven los detalles de la historia del flujo de trabajo con los mismos usuarios y fechas:
Abrimos SharePoint Designer y vemos que el flujo de trabajo existe:
El segundo paso es subir un segundo documento al sitio, para verificar que el flujo de trabajo funcione correctamente. Para ello luego de subirlo, completamos la tarea asignada. El resultado es el siguiente:
Por último, volvemos a abrir SharePoint Designer y modificamos el flujo de trabajo agregando un tercer paso. Publicamos y vemos que todo funciona sin problemas:
Subimos un tercer documento y verificamos que el flujo de trabajo se ejecuta sin problemas:
En esta prueba se observa que SharePoint 2010 permite mover sitios dentro de la estructura manteniendo la historia de la información. Es una prueba de laboratorio sencilla sin estructuras complejas.
Antes de avanzar con este método en un ambiente productivo, es conveniente revisar las particularidades de cada caso, hacer las pruebas en un ambiente de QA y tomar los recaudos necesarios de copias de seguridad.
