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/

Obtener parámetros de la URL

Constantemente utilizamos la URL para pasar parámetros cuando estamos trabajando con SharePoint. De hecho el propio SharePoint es el primero que lo hace y el caso más fácil de ver, es cuando accedemos a un elemento de lista, ya sea en forma de edición o de presentación:

http://misitoweb/Lists/Alertas/EditForm.aspx?ID=39&Source=http%3A%2F%2Fmisitioweb%2FLists%2FAlertas%2FAllItems%2Easpx

En este ejemplo, podemos ver que tenemos dos parámetros ID y Source, que sirven para identificar el elemento y a dónde nos va a llevar una vez aceptemos o cancelemos la edición del elemento.

Normalmente para obtener y tratarlo, utilizaríamos JavaScript y/o JQuery, y trataríamos la URL.

La idea que propongo en esta entrada es encapsular una función que ya nos lo obtenga y que incluyéndola en un archivo .js, nos permitiría referenciarla en la página maestra y utilizar en nuestro portal.

El código sería sencillo:

function getUrlVars() {
  var vars = {};
  var parts = window.location.href.replace(/[?&]+([^=&]+)=([^&]*)/gi, function(m,key,value) {
    vars[key] = value;
  });
  return vars;
}

Esto nos permitiría recuperar dicho parámetro haciendo algo tan sencillo como:

var elemento = getUrlVars()["ID"];
var destino = getUrlVars()["Source"];

Y poder trabajar con ellas. Como se ve, es algo fácil y sencillo.

La idea la obtuve de:
http://papermashup.com/read-url-get-variables-withjavascript/

Jugando con las vistas dinámicas

Muchas veces en el trabajo te suelen pedir vistas dinámicas, sobre listas de Sharepoint. Generalmente, la mayoría suelen ser juegos con una fecha y la fecha del día actual.

Como por ejemplo, mostrar en una vista, los elementos que estén a menos de 30 días de llegar a la fecha de expiración marcada por el usuario.

Para ello, en el formulario de creación de elementos de la lista, había un campo de tipo Fecha, que el usuario debía rellenar. Este campo, lo llamamos Valid Until a petición del usuario, en el se marcaba la fecha en que expiraba una oferta, la cual debía ser revisada por un administrador. Para facilitarle el trabajo, se creo la vista que he comentado.

Para ello, basto con un simple juego de lógica con la columna Valid Until y los filtros de una lista:

Como se puede apreciar en la imagen, se le dijo que mostrará sólo los elementos que el campo que Valid Until fuese menor o igual que la fecha de Hoy más 30 (Valid Until ≤ Today + 30), si restamos 30 a ambos lados de la desigualdad (Valid Until - 30 ≤ Today), veremos que estamos fijando el limite inferior, es decir a partir de que día estamos empezando a mostrar las entradas: 30 días antes de que expiren.

Ahora nos quedaría fijar el límite superior, es decir, hasta cuando queremos que nos lo muestre.

Tal y como vemos en la imagen, ese límite debe ser para cuando estemos en un fecha anterior o igual a la fecha de expiración (Today ≤ Valid Until),

Pero a nosotros sólo nos interesa mostrar los que cumplen ambas condiciones, por eso uniremos las dos condiciones con un AND lógico. Con ello, ya habremos conseguido la vista que nos pedía el cliente.

Esta entrada tiene más utilidad como recordatorio personal, que como novedad, pero siguiendo la línea de este blog, la muestro, por si a alguien le pudiera ser de utilidad.