Creación de paginas en MiSitio

Últimamente he estado trabajando en personalizaciones para MiSitio en MOSS 2007 y uno de los problemas que me encontré al intentar hacer esto fue el hecho de que los sitios no contienen bibliotecas de paginas o infraestructura de publicación para crear paginas como lo haríamos normalmente, también está el hecho de que todas las bibliotecas de documentos incluidas en el portal del usuario podrán ser modificadas por este, ya que el mismo es administrador de su propio sitio!.

Buscando la forma de crear una página o archivo que no perdiera las características con las que cuenta la pagina default llegue a la solución de copiar la misma página default.aspx.

SPFile f = miWeb.GetFile("default.aspx");

f.CopyTo(miWeb.ServerRelativeUrl + "DefaultCopia.aspx");

Con esto podremos copiar la pagina una vez que exista, personalizarla (por ejemplo para eliminar las webpats existentes y agregar webparts propias) y agregarla navegación.

Migrar y desinstalar flujos de trabajo de Visual Studio en MOSS 2007

Los flujos de trabajo de Visual Studio con las extensiones para SharePoint, en conjunto con el .NET Framework 3.5 y el Windows Workflow Foundation proporcionan una herramienta muy potente para manejar la lógica de un proceso de negocio y si bien existen herramientas como SharePoint Designer que permiten realizar flujos de trabajo con 0 programación, conforme la complejidad o longitud de estos avanza, se vuelve más complicado mantener una estructura entendible y/o eficiente.

El tema de los flujos de trabajo es enorme y ya iré abarcando el tema poco a poco, una de las primeras preguntas cuando uno genera su primer flujo de trabajo es como se instala, claro, si tenemos la facilidad de un F5 y listo en Visual Studio, pero si se quiere instalar el mismo flujo de trabajo en un ambiente que no tenga Visual Studio, se pensaría que el paso sería el mismo que con Webparts o receptores de eventos, ir a la carpeta, copiar el WSP y el setup.bat, ejecutarlo y listo... pero, los flujos de trabajo no funcionan así!.

Lo mismo sucede cuando intentas desinstalarlo por primera vez, no hay un "setup -uninstall" que nos ayude, así que sin más veamos cómo se resuelven estos problemas dividiendo esto en dos simples secciones: Instalación y Desinstalación.

Instalando (o migrando) un flujo de Trabajo.

Los flujos de trabajo se implementan por medio de una característica (feature) por lo que toda la información necesaria para que el flujo de trabajo funcione se encuentra en dos sitios, la carpeta de la característica y el ensamblado como tal.

La carpeta la podemos encontrar en la ruta de instalación de SharePoint, por ejemplo: "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\FEATURES", el nombre de la carpeta corresponde al nombre que hayamos declarado al crear el Workflow (para los que tengan tan mala memoria como yo, el nombre también está dentro de los archivos feature.xml y workflow.xml), de no tener un ambiente que tenga previamente instalado el Workflow y por consecuencia no ver esta carpeta simplemente crea una carpeta con el nombre de tu Workflow que contenga los archivos feature.xml y workflow.xml que genera Visual Studio automáticamente.

El ensamblado lo puedes copiar del directorio de tu solución o bien tomar el que se encuentra en el GAC (de un entorno que ya tenga el flujo de trabajo instalado) con una herramienta externa.

Copia estos dos elementos a tu servidor destino, dejando la carpeta en el lugar correspondiente a las características, e instalando tu ensamblado en el GAC (o como muchos prefieren en la carpeta bin) ya sea con alguna herramienta o manualmente pegando el .dll en la carpeta "C:/Windows/assembly", si la seguridad del servidor no te permite esta instalación manual, puedes hacerlo con un workaround desde cmd (tema aparte, si alguien lo necesita lo agrego).

Por ultimo hay que instalar la característica y activarla en el sitio correspondiente, esto por medio del stsadm, que se encuentra en ""C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\bin", dependiendo del directorio de instalación, lenguaje y sistema operativo. Sitúate en dicha carpeta dentro de una ventana de consola y ejecuta las siguientes instrucciones reemplazando "MiFlujo" por el nombre de tu flujo de trabajo y "misitio" por el sitio donde instalaras el mismo, incluyendo el puerto:

stsadm -o installfeature -name MyFlujo

stsadm -o activatefeature -name MyFlujo -url http://misitio:81

Una vez que todo se haya instalado y activado ya puedes asociar tu flujo de trabajo a la(s) lista(s) que corresponda(n), antes, asegúrate que todos los elementos que necesita el flujo de trabajo ya se encuentran en el servidor, como pueden ser listas adicionales que consulte durante el proceso, o cualquier nombre que hayas puesto en código duro (lo cual no es recomendado..).

Felicidades ya has migrado tu primer flujo de trabajo!.

Desinstalando un flujo de trabajo.

Cuando tenemos un flujo de trabajo de SharePoint Designer, basta con eliminarlo desde el mismo para cumplir este punto, mas sin embargo los flujos de trabajo de Visual Studio son en realidad esto, flujos que podemos reutilizar para n número de elementos, creando instancias en diferentes listas que podrían a su vez tener un comportamiento diferente usando los formularios de iniciación, en fin, eliminar el flujo de la lista solo quitara la instancia que se ejecutaba en esa lista, no desinstala el flujo de trabajo como tal.

Si has leído la primera parte de este post no te será tan difícil comprender como se puede desinstalar un flujo de trabajo, de lo contrario no te preocupes y sigue leyendo que pronto entenderás.

El flujo de trabajo es una característica y para desinstalarlo hay que tratarlo como tal, abre una ventana de consola (cmd) y accede a la ruta de instalación de SharePoint , en la carpeta bin (""C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\bin" usualmente). Una vez en este directorio ejecuta las siguientes líneas reemplazando los parámetros con los que correspondan a tu flujo de trabajo:

stsadm -o deactivatefeature -name MyFlujo -url http://localhost:81

stsadm -o uninstallfeature -name MyFlujo

Puedes usar el id de tu flujo de trabajo en lugar del nombre, o ambos si asi lo decides, estos se encuentran en los archivos feature.xml y workflow.xml que crea Visual Studio automáticamente.

Con esto el flujo de trabajo ya no aparecerá en las opciones para asociar nuevos flujos a una lista, así mismo, los elementos aun se encuentran físicamente en el servidor, tanto la carpeta de la característica en "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATES\FEATURES" como en ensamblado en el GAC (o en el bin si ahí lo instalaste), puedes remover estos elementos manualmente.

Conclusiones.

Como ven el proceso para instalación y desinstalación de flujos de trabajo no es tan complejo como parecería a primera vista, y se puede automatizar aun mas por medio de paquetes como wsp, archivos bat, instaladores de codeplex, etc.

Espero haber resuelto algunas dudas y creado algunas otras, deja tus comentarios si te gustaría que ampliara la información en algún tema, o bien, si tienes dudas o comentarios, la crítica es bien recibida también.

Obtener campos especificos de un item con Linq to SharePoint

Una entrada breve para describir como podemos obtener con linq los valores que necesitamos de un item, la consulta es sencilla, hay que establecer una condicion para obtener el item que necesitamos (en este caso lo hago en base al ID del item) y despues seleccionar los campos que usaremos y de donde obtendran la informacion:

using (SPSite miSitio = new SPSite(SPContext.Current.Site.ID))

{

using (SPWeb miWeb = miSitio.OpenWeb(SPContext.Current.Web.ID))

{

SPList miLista = miWeb.Lists["nombreLista"];

var res = from renglon in miLista.Items.Cast()

where renglon.ID == int.Parse(Lista.SelectedValue)

select new

{

Nombre = renglon["campoNombre"],

Direccion = renglon["campoDireccion"],

};

}

}

Una vez con esto podemos acceder a la informacion en los resultados de la forma en la que queramos, ya sea usandolo como datasource, convirtiendolo en lista, en datatable, o bien si solo se trata de un item como en este caso obtener la informacion directamente, por ejemplo:

res.AsEnumerable().Single().Nombre.ToString();

Esto nos regresara una cadena que podemos usar para cualquier cosa!

Validando un Control PeopleEditor en SharePoint

Bueno, hace poco tuve que validar uno de estos controles para un requerimiento, y buscando información encontré algunas referencias que mencionaban cosas como que no era posible usar controles de valuación para controles de SharePoint, así como preguntas en general sobre como utilizar la lógica de estas validaciones.

Según la experiencia que tuve esta ocación me pareció algo muy sencillo sin embargo aquí incluyo alguna información del mismo para aquellos que tengan problemas sobre este tipo de validaciones.

El control PeopleEditor cuenta con métodos de validación propios, que funcionan a través de algunas propiedades que nosotros establecemos, las propiedades mas comunes son:

PeopleEditorEjemplo.AllowEmpty = false;

PeopleEditorEjemplo.MultiSelect = false;

PeopleEditorEjemplo.ValidatorEnabled = true;

PeopleEditorEjemplo.SelectionSet = "User";

Con esto nos aseguramos que el control no pueda o no estar vació, contar con selecciones múltiples, y que puedan seleccionar solo usuarios o grupos, existen propiedades adicionales por ejemplo, para establecer los grupos que estén disponibles.

Una vez que se tengan establecidas las propiedades solo es necesario llamar el método correspondiente para validar el control:

void btnAceptar_Click(object sender, EventArgs e)

{

PeopleEditorEjemplo.Validate();

}

Con esto el control se validara y mostrara el error correspondiente debajo del control, los mensajes de error dependen de la conflagración de lenguaje de SharePoint. Ejemplo de validación:

Espero les sirva de algo en sus futuros desarrollos.

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.