Inicio > Entradas > Establecer la cuenta de un Organizational Browser

Establecer la cuenta de un Organizational Browser


Debo de admitir que SharePoint tiene algunos controles y WebParts que son muy padres y que de hecho son muy útiles. Algunos, como los que están clasificados bajo “Social y colaboración”, son muy llamativos para los usuarios. De hecho, uno que vale la pena mencionar es el Organizational Browser.

 
 

Si no lo conoces, te comento que este WebPart crea un navegador de jerarquías de empleados, es decir, un organigrama. Comienzas con tu cuenta de usuario y te aparece en la parte superior la jerarquía de jefes hasta llegar al nivel más alto (presumiblemente un CEO). Hacia abajo, muestra a tu equipo de trabajo: quiénes te reportan directamente. Y hacia los lados están tus colegas: aquéllos quienes reportan al mismo jefe que tú.

 
 

Pero no solo es mostrar una estructura determinada, sino que al dar clic en cada persona (ya sea jefe, tu equipo o tus colegas) ésta pasa al centro y se muestra su propia estructura: jefes, colegas y equipo. Así, puedes navegar por toda la estructura organizacional de la empresa (claro, siempre y cuando el Directorio Activo esté sano).

 
 


 
 

Si tu granja tiene habilitado el My Site, entonces ya cuentas con una página en tu perfil donde se muestra este control. Si no, puedes agregar el control en cualquier página mediante el WebPart llamado Organizational Browser localizado en la categoría de Social Collaboration.

 
 

La capacidad de contar con un organigrama cuando creamos Team Sites dentro de SharePoint es fundamental, y muchas veces ignorada. Considera un Team Site para dar soporte sobre un servicio X dentro de la organización. Tener el organigrama disponible permite ver con quién dirigirse para tratar un tema determinado, o con quién realizar una escalación. Asimismo, para los miembros del equipo, nos pone a la mano la información de contacto: teléfonos, correos, direcciones, etc.

 
 

Por todos los bienes que trae este control, cuenta sin embargo con una gran deficiencia. Cuando añadimos el WebPart, éste siempre va a renderizar el organigrama a partir de la cuenta que ha ingresado. Es decir, siempre mostrará tu cuenta. Este es, a mi juicio, un error de funcionalidad. Si bien es cierto que este comportamiento es deseable dentro del My Site, debería dar la capacidad de configurar la cuenta de inicio de forma sencilla. Esto es lógico: si creamos un Team Site para el área de finanzas, seguramente querremos que el organigrama se despliegue con el CFO (Chief Financial Officer, o director de finanzas) en el centro. Y esto es algo que los tíos del SharePoint Development Team no nos dejaron hacer, al menos de forma sencilla: editar

 
 

Al respecto, estuve investigando formas para trabajar alrededor de esto. Hay varias ideas al respecto, la mayoría sugieren crear una página ASPX y empotrar un par de controles: un ProfilePropertyLoader y un ProfileBrowser. En este hilo dentro de los foros de MSDN es lo que sugieren, con este código.

 
 

<%@ Page language=”C#” … otras declaraciones de ASP.NET… %>

 
 

<asp:Content contentplaceholderid=”PlaceHolderAdditionalPageHead” runat=”server”>

 

</asp:Content>

 
 

<asp:Content contentplaceholderid=”PlaceHolderMain” runat=”server”>

 
 

<SPSWC:ProfilePropertyLoader id=”m_objLoader” LoadFullProfileOfCurrentUser=”true” runat=”server” />

 
 

<div class=”orgBrowser”>

<SPSWC:ProfileBrowser ChromeType=”None” runat=”server” __WebPartId=”{553DA676-D81E-4B0B-B8FA-58518A90C5D8}” />

</div>

</asp:Content>

 
 

Según esto, con invocar al ASPX pasándole como parámetro por el Query String un accountname=midominio\micuente es suficiente. De hecho, encontré varios foros y blogs donde sugieren este mismo enfoque. Sin embargo, plantea un problema: se requiere del SharePoint Designer para poder editar los ASPX de esta forma. Y en muchos casos las granjas corporativas bloquean por seguridad el uso de esta herramienta. De hecho, mi granja sufre de esto mismo.

 
 

Así las cosas, estuve buscando alternativas para solventar este problema. Dado que no encontré una, me decidí por investigar el control a fondo. Una rápida examinada al código HTML generado por una página que contenga este control indica que en realidad es un control de Silverlight, y que el WebPart no es más que un envoltorio que lo invoca. El objeto en cuestión se localiza en la url ‘/_layouts/ClientBin/hierarchychart.xap’.

 
 

Ahora bien, tras descargar dicho XAP, cambiarle la extensión por ZIP, y descomprimir el archivo, tuve acceso a HierarchyChart.dll. Tras abrirlo con algún desensamblador (yo usé el integrado de SharpDevelop) y explorar las clases, pude ver que en realidad el control toma el parámetro llamado initialParameters, y espera que éste sea una cadena de texto con los parámetros separados por coma. En particular, espera que el primer parámetro sea el Profile ID, es decir, el dominio + cuenta del usuario inicial que el control habrá de renderizar; y el segundo parámetro el tipo de usuario, usualmente UserType.

 
 

Mi reacción ante este hallazgo fue de gusto: entonces la solución sería crear un WebPart de tipo Silverlight Content, apuntar al XAP en cuestión, y en los parámetros iniciales (que sí pueden editarse desde el propio WebPart) poner mi cuenta, seguido del UserType separado por comas. Sin embargo, al probar esto no me funcionó. Tras revisar, resulta que nuestro buen WebPart Silverlight Content añade la URL a los initialParameters que configuramos, y por tanto el control de Silverlight nunca leería bien el ID de cuenta, pues estaría leyendo la URL.

 
 

Este hecho me frustró y obligó a cambiar de enfoque. Regresé a revisar el código generado por el Organizational Browser, con mayor detenimiento, y me topé que en realidad el WebPart no genera el enlace hacia el XAP, sino que hay un JavaScript que crea dinámicamente el control Silverlight. El pedazo de código más importante se encuentra en la función CreateHierarchyChartControl, cuyo extracto reproduzco a continuación.

 
 

function CreateHierarchyChartControl(parentId, profileId, type, persistControlId)

{

var initParam = profileId + ‘,’ + type + ‘,’ + persistControlId;

var host = document.getElementById(parentId);

 
 

host.setAttribute(‘width’, ‘100%’);

host.setAttribute(‘height’, ‘100%’);

 
 

Silverlight.createObject(

‘/_layouts/ClientBin/hierarchychart.xap’,

host,

‘ProfileBrowserSilverlightControl’,

{

top: ’30’,

width: ‘100%’,

height: ‘100%’,

version: ‘2.0’,

isWindowless: ‘true’,

enableHtmlAccess: ‘true’

},

{

onLoad: OnHierarchyChartLoaded

},

initParam,

null);

}

 
 

Como puedes ver, esta función crea el objeto XAP y le pasa los parámetros iniciales. La función toma como segundo parámetro un profileId, que es de hecho la cuenta (dominio\cuenta) inicial del Organizational Browser. Así, si de alguna forma pudiéramos invocar la función con el parámetro cambiado… pero intentar hacerlo resulto un completo dolor en el cu…erpo, puesto que hay muchas otras funciones involucradas.

 
 

Tras explorar el código, recordé sin embargo una característica interesante de JavaScript, más bien oscura. Toma este ejemplo.

 
 

<script type=”text/javascript”>

 
 

function foo() {

alert(‘Foo 1’);

}

 
 

function foo() {

alert(‘Foo 2’);

}

 
 

foo();

 
 

</script>

 
 

Al ejecutarse, ¿qué pasará con este script? Evidentemente tenemos definida la función un par de veces. Sin embargo, no ocurre un error. Lo que sucede aquí al ejecutarse es que se muestra una alerta con el texto Foo 2. Esto se debe a una característica de JavaScript: cuando dos funciones con la misma firma y nombre son declaradas, el compilador / intérprete deberá tomar en cuenta la definición más reciente (es decir, la última). ¡Con esto ya tenemos la solución, y ni siquiera tenemos que usar el SharePoint designer! En efecto, lo que tendríamos que hacer es crear una segunda función llamada CreateHierarchyChartControl y añadir los initParams que queremos.

 
 

Vamos paso a paso.

 
 

1.- Crear una página que permita añadir WebParts, ya sea a un WebPartZone o a un RichContent.

2.- Editar la página y añadir un Organizational Browser WebPart.

3.- Abajo del WebPart anterior (y es importantísimo que sea abajo) añadir un Content Editor WebPart (localizado en la categoría Media and Content.

4.- Seleccionar nuestro Content Editor WebPart y en las propiedades de WebPart, hacer clic en editar.

5.- Colocar el cursor en el espacio vacío del Content Editor WebPart y se habilita la cinta contextual (Ribbon) de Format Text. En el panel Markup, seleccionar la opción Edit HTML Source.

6.- En el panel HTML Source que aparece, añadir este código y guardar

 
 

<script type=”text/javascript”>

function CreateHierarchyChartControl(parentId, profileId, type, persistControlId)

{

//var initParam = profileId + ‘,’ + type + ‘,’ + persistControlId;

var initParam = ‘midominio\\micuenta,’ + type + ‘,’ + persistControlId; // editar

var host = document.getElementById(parentId);

 
 

host.setAttribute(‘width’, ‘100%’);

host.setAttribute(‘height’, ‘100%’);

 
 

Silverlight.createObject(

‘/_layouts/ClientBin/hierarchychart.xap’,

host,

‘ProfileBrowserSilverlightControl’,

{

top: ’30’,

width: ‘100%’,

height: ‘100%’,

version: ‘2.0’,

isWindowless: ‘true’,

enableHtmlAccess: ‘true’

},

{

onLoad: OnHierarchyChartLoaded

},

initParam,

null);

}

</script>

 
 

7.- En la segunda línea de la función, donde está el comentario “// editar”, hay que cambiar “midominio\\micuenta” por el dominio/cuenta del usuario que deba mostrar por vez primera el Organizational Browser. Nota que la diagonal invertida tiene que escaparse, de ahí que sean dos.

8.- Guardar la edición de la página con todos sus cambios, y regenerar la página.

 
 

¿Sí notaste lo que hicimos? El Content Editor WebPart añade una función que se llama CreateHierarchyChartControl. Como pusimos el WebPart después que el Organizational Browser, esta segunda función será la que el Organizational Browser ejecute en lugar de la normal, debido a que JavaScript siempre tomará como válida la última. Y en nuestra función JavaScript, armamos el initParameters a nuestro gusto, hardcodeando en este caso la cuenta (en tu caso, puedes leer desde query string o algún otro lado, si no te gusta hacer un hardcode).

 
 

La siguiente imagen muestra cómo quedó mi sitio.

 
 


 
 

 
 

Por favor, no dejes de enviar comentarios con sugerencias para monitorear si esta solución es escalable o presenta algún problema raro. En mi caso funcionó súper bien, pero ya ves que luego esto puede variar: your mileage may vary, dirían en EE.UU.

 
 

Eso es todo amigos.

 
 

 
 

 
 

 
 

 
 

 
 

Categorías:Entradas
  1. Carlos Vigo
    agosto 6, 2014 a las 10:05 am

    Hola Fer, un artículo magistral el que has escrito. Me has salvado la vida :)
    Veo que no hay comentarios al parte de mi felicitación. Sin animos de ofender, si lo escribieras en inglés recibirías muchísimo más visitas.
    Saludos
    Carlos

  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s