Aceptación de condiciones con SharePoint

Esta semana me han pedido que al acceder a la página principal de un SharePoint saliera un recordatorio respecto a la normativa corporativa de la empresa. Querían que saliera todas las veces que accedían al portal.

Solución rápida: Un alert de JavaScript.

Como era de esperar a los tres días les ha parecido que no era una buena solución y que les parecía mejor la solución que les propuse inicialmente, que sólo saliera la primera vez que accedes al espacio y que quedase registrado cuando has dicho que estabas de acuerdo con los términos legales de la empresa.

Para ello, lo primero que he creado ha sido una lista llamada AceptaciónCondiciones. En ella, sólo utilizo la columna Título, Creado por y Creado. Todas ellas propias del tipo de contenido Elemento, propio de una lista personalizada.

Y en la página de inicio he incluido el siguiente script en un editor de secuencias de comando:
<script type="text/javascript">
 $( document ).ready(function(){
 var usuario = $().SPServices.SPGetCurrentUser({
  fieldNames: ["FirstName", "LastName", "UserName"],
  debug: false
 });
 $().SPServices({
    operation: "GetListItems",
    async: false,
    listName: "AceptacionCondiciones",
    CAMLViewFields: "<ViewFields><FieldRef Name='Title' /></ViewFields>",
CAMLQuery: "<Query><Where><Eq><FieldRef Name='Title'/><Value Type='Text'>"+usuario.UserName+"</Value></Eq></Where></Query>",
    completefunc: function (xData, Status) {
if($(xData.responseXML).SPFilterNode("z:row").length == 0){
//No está y lo incluyo
alert('Advertencia: Este acceso sólo está disponible para usuarios autorizados por personal del servicio. Cualquier intento de acceso no autorizado quedará registrado para su posterior análisis. La documentación aquí alojada es para uso profesional, no permitiéndose su divulgación. ');
AddListItem(usuario.UserName);
}    
    }
  });
})
function AddListItem(TitleField) {
        $().SPServices({
            operation: "UpdateListItems",
            async: false,
            batchCmd: "New",
            listName: "AceptacionCondiciones",
            valuepairs: [["Title", TitleField]],
            completefunc: function (xData, Status) {   
            }
        });
    }
</script>

Lo que hace este Script es guardar en una variable llamada "usuario" el Nombre, Apellido y Nombre de usuario. Luego hago una llamada a la lista AceptacionCondiciones a través de una Query de CALM preguntando si existe algún elemento que en la columna Title (Nombre interno de la columna Título) que contenga el valor de UserName del usuario de DA que esta accediendo a la página principal.
En caso de que no este, hago saltar un Alert de JavaScript con el texto deseado y tras ello incluyo en la lista el usuario, a través de la función AddListItem, completando el campo Titulo con el UserName y como los campos "Creado" y "Creado por" toman automáticamente el nombre a mostrar del usuario y el momento en que hemos aceptado las condiciones.

Ya tendríamos nuestra lista de aceptación de condiciones pedida.

Sí nos hubieran pedido que esta aceptación saliera en cualquier página de nuestro sitio, bastaría con incluir este Script en la página maestra e incluir la línea que indica donde esta la lista, por si estamos en un sitio diferente al de la lista:
webURL: "https://URL del sitio donde esta mi lista de Aceptación de condiciones",

Quedando algo como:
 $().SPServices({
    webURL: "https://URL del sitio donde esta mi lista de Aceptación de condiciones",
    operation: "GetListItems",
    async: false,

Y el resto igual.

Posiblemente con .Net se pudiera hacer algo más completo, pero seguro que también sería más costoso en tiempo.

Campos dependientes en SharePoint

Esta es una entrada que tal vez debiera haber hecho hace mucho tiempo. Una de las limitaciones que más sorprende a la gente cuando se acerca por primera vez a SharePoint, es el hecho de que no se pueda establecer una dependencia entre los campos de tipo elección.

La verdad es que es una gran limitación en el día a día. Por suerte, como siempre tenemos JQuery y en este caso en concreto SPServices.

Uno de mis clientes nos solicito un formulario para etiquetar empresas que ofrecían servicios, clasificables en tres niveles, niveles dependientes entre ellos.

Lo primero que tuve que hacer es una lista con los valores del primer nivel:

Tras ello, crearemos otra lista, que tendrá un campo de tipo texto, donde irán los valores del segundo nivel, y un campo de tipo búsqueda que buscará sobre la columna de la primera lista:

Y de manera análoga el para el tercer nivel:

Estas serán nuestras tres listas maestras, desde donde podremos gestionar los valores de los tres campos de elección. Lo siguiente que haremos será crear tres columnas de tipo búsqueda, en la lista donde queremos utilizar los valores:

Cada una de las columnas, buscará sobre la lista correspondiente a su nivel, eligiendo al crearlas, si son de valor único o múltiple selección (en mi caso los tres son de múltiple selección):

Y por último tendremos que añadir en los formularios que deseemos que se comporten como campos dependientes el siguiente código:

<script type="text/javascript">
$(document).ready(function() {
$().SPServices.SPCascadeDropdowns({
relationshipList: "Nivel 2",
relationshipListParentColumn: "Nivel",
relationshipListChildColumn: "Title",
parentColumn: "Listado1",
childColumn: "Listado2";
});  
$().SPServices.SPCascadeDropdowns({
relationshipList: "Nivel 3",
relationshipListParentColumn: "Nivel",
relationshipListChildColumn: "Title",
parentColumn: "Listado2",
childColumn: "Listado3";
});
});
</script>

En la primera llamada a SPCascadeDropdowns, lo que se indica es la lista sobre la que se va a filtrar el valor, en nuestro caso Nivel 2, que es donde se encuentra la relación. Lo siguiente que diremos es sobre que columna de esa lista va a actuar como Padre y cual sobre Hijo, es decir, cual la que nos permite seleccionar el valor para filtrar y sobre cual se filtran los valores. Por último, indicaremos sobre que campos de nuestra actual lista actuará.

En la segunda llamada a SPCascadeDropdowns, se repite la operación pero sobre el segundo y tercer valor.

Quedando un funcionamiento de campos dependientes:

NOTAS: 

• Se da por supuesto, que en la página maestra o bien en el código de la página, se encuentra una referencia a JQuery y otra SPServices.
• Los líneas relationshipListParentColumn: "Nivel" y relationshipListChildColumn: "Title", hacen referencia al Nombre interno del campo en la lista donde hacemos la relación "Nivel 2". De hecho, en mi ejemplo, como utilizo SharePoint en Español, el nombre externo es Título y no Title.
• Las segundas referencias parentColumn: "Listado1" y childColumn: "Listado2", hacen referencia al nombre a mostrar de la columna y no al nombre interno.
• En esta última referencia, si un campo es obligatorio, la referencia debe ser de la forma: parentColumn: "Listado1 Campo requerido", que corresponde con el title en HTML del campo. En mi caso es Campo requerido, porque mi SharePoint esta en Español, si lo tenéis en Inglés, posiblemente sea Requiered field.

Fuentes:
http://sympmarc.github.io/SPServices/value-added/SPCascadeDropdowns.html
http://www.bentedder.com/sharepoint-sketches-spservices-cascading-dropdowns/

Trabajando con las Master Pages de SharePoint 2013

Si estáis acostumbrados a trabajar con SharePoint 2007 y/o 2010, seguro que más de una vez habréis tenido que modificar su página maestra o master page.

Para ello, habréis abierto el sitio raíz de vuestra colección de sitios con SharePoint Designer y habréis accedido a la carpeta _catalogs/masterpage, donde están esos maravillosos archivos .master:

O bien, habréis accedido vía web a través de la opción Páginas maestra y diseños de página, que se encuentra en la configuración de sitio del sitio raíz de vuestra colección de sitios:

Pues bien, habréis modifica esos archivos .master y seguro que con un poco de trabajo, habéis conseguido lo que queríais: Modificar las migas, incluir una CSS, incluir un JS...

Al ir a hacer esto en 2013, puede que os hayáis encontrado una sorpresa y tras copiar el archivo .master, habréis intentado renombrarlo y os habrá salido un mensaje que dice: Error del servidor: Este archivo no se puede mover, eliminar, editar ni se puede cambiar su nombre.

Comprobareis que tampoco podéis borrarlo.

La solución para todo, es copiar el archivo .html que tiene el mismo nombre. Tras ello, ya podremos por medio del archivo .html, modificar el nombre, eliminarlo, etc... Pero en cambio, si lo que hacemos es modificar el código del archivo .master, veremos que no nos deja. Eso es porque el código .master, esta asociado al .html.

La manera de modificar la master page que plantea Microsoft, es por medio de la edición del archivo .html asociado. Esto puede ser muy engorroso y no muy agradable (al menos esa ha sido mi experiencia).

Para ello, existe la posibilidad de desasociar el .html del .master y trabajar con el .master directamente. Bastaría con acceder a la configuración del sitio raíz de nuestra colección de sitios y elegir la opción Páginas maestras y diseños de página que se encuentra bajo la agrupación Galerías del diseñador web:

Una vez dentro, buscaremos nuestro archivo .html y editaremos sus propiedades, desmarcando la opción de Archivo asociado:

A partir de este momento, ya será posible modificar el archivo .master, tal y como estábamos acostumbrados en las versiones 2007 y 2010.

Importante: NO volver a marcar esta opción, ya que como nos advierte, que nos macharía nuestro archivo .master, con el código generado a paritr del .html que no ha sido modificado.

¿Qué plantilla de sitio se está usando en mi sitio?

Algunas veces nos puede interesar saber que plantilla de sitio ha sido utilizada para la creación de un sitio en concreto. Pues en SharePoint 2010 y 2013 hay una manera muy sencilla de hacerlo.

Basta con hacer clic con el botón derecho sobre la página del sitio que queremos conocer su plantilla y en el menú contextual que nos sale, elegiremos la opción de Ver código fuente:

Esto nos abrirá una nueva ventana con el código fuente de la página en cuestión. Ahora sólo habrá que buscar g_wsaSiteTemplateId en el código (para ello podremos utilizar el buscador Ctrl+F):

Y ahora copiaremos el identificador de la plantilla, en mi caso, PROJECTSITE#0 e iremos a buscarla a la página de Microsoft:
http://social.technet.microsoft.com/wiki/contents/articles/20100.sharepoint-2010-default-site-templates.aspx
ó
http://social.technet.microsoft.com/wiki/contents/articles/20149.sharepoint-2013-default-site-templates.aspx

De hecho, también hay una página interesante con los cambios que ha habido de la versión 2010 a la 2013:
https://technet.microsoft.com/en-us/library/ff607742.aspx

En nuestro caso, veremos que es una plantilla de sitio de proyectos:

Como podéis ver, ha sido muy fácil.

Error en los espacios de reunión de SharePoint: 'g_InstanceID' no esta definido

Jugando con las páginas maestras en SharePoint, descubrí que al volver a aplicar la default.master, a un sitio que tuviera como subsitio un espacio de reuniones, me genero un error de Javascript que me decía que 'g_InstanceID' no esta definido y me impedía que al hacer clic en las fechas de la parte izquierda, pudiera ver el contenido de los documentos asociados a dicha fecha:

Para solucionar esto, basta con hacer una copia de la página maestra, en nuestro caso default.master, renombrarla y añadir tras la etiqueta <%@ Import Namespace=”Microsoft.SharePoint” %>:

<%@ Register Tagprefix="Meetings" Namespace="Microsoft.SharePoint.Meetings" 

Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, 

PublicKeyToken=71e9bce111e9429c" %>

Y tras la apertura de la etiqueta de <body> añadiremos:

<Meetings:PropertyBag runat="server"/>

Guardaremos la nueva pagina maestra, la publicaremos y la aplicaremos a nuestro espacio de reuniones y veremos como el problema se ha solucionado.

Fuente: http://sympmarc.com/2008/07/02/how-to-fix-recurring-meeting-workspace-error-%E2%80%98g_instanceid%E2%80%99-is-undefined/

Abrir enlaces en nueva pestaña

En algunas entradas anteriores, hemos visto como hacer que se abran los PDF en ventanas nuevas u otras particularidades.

Pero si queremos un método general, en el que el usuario pueda elegir que enlaces se abren en nueva ventana, podemos aprovechar que las URL soportan anchas.

Es decir, si quiero ir a San Google, tengo que ir a:

https://www.google.es

Pero también voy si accedo a:

https://www.google.es#nuevaventana

Esto es un ancla:

#nuevaventana

Y nos aprovecharemos de ello para crear un Jquery que puede ir en la página maestra y que nos permita que todos los enlaces que los acabemos con dicha ancla, se abran en nueva ventana.

Bastará con incluir:

<script src="https://ajax.microsoft.com/ajax/jquery/jquery-1.3.2.min.js" type="text/javascript"></script>

<script type="text/javascript">

$(document).ready(function() {

  $("a[href$='#nuevaventana']").each(function() {

    $(this).attr("target", "_blank");

    $(this).attr("href", $(this).attr("href").replace(/#nuevaventana/, ''));

  });

});

</script>

Con esto, estaremos recorriendo cada elemento que tiene en su href, la cadena '#nuevaventana', le estaremos diciendo que su target es '_blank' (nueva pestaña) y por último retiraremos de la url, nuestra ancla, ya que no la necesitaremos.

Fuente:

http://blog.scoreman.net/2010/10/open-sharepoint-links-in-new-window-using-jquery/