Configuración inicial portales de comunicación

Hola a tod@s, en la siguiente entrada vengo a presentaros que configuración hay que realizar tras la creación de un nuevo sitio de comunicaciones de Office 365 en vuestra organización. De esta forma, se podrá minimizar en el futuro problemas a la hora de desarrollar componentes, listas, permisos de seguridad o Api Rest sobre listas de SharePoint Online.

Los antecedentes

El caso es que cuando creo un nuevo sitio de comunicaciones con mi licencia de desarrollo de Office 365, para hacer mis experimentos en Office 365 y mis entradas en el blog, suelo crear estos sitios con la cultura en inglés, con el fin de estar más alineados con el contenido de esta gran comunidad, que te lo sueles encontrar en inglés.

El caso, es que cuando entro al recién creado sitio de comunicaciones, en vez de ver todo en inglés, lo tengo en español.

Pero si entro al mismo sitio web, con uno de los usuarios que nos da la licencia de desarrolladoras de Office 365, como puede ser con nuestra usuaria y amiga Adele Vance, se visualiza todo en inglés.

Esto es de debido a como está configurado mi perfil dentro del programa de desarrollo de Office 365. En su momento, cuando me di de alta, lo tramite todo en español, y se configuro mi perfil dentro del Tenant en español.

Aun que tengo la capacidad de cambiar esta configuración, dentro de mi perfil, he preferido seguir con la configuración inicial de mi cuenta.

Debido a esta casuística de trabajar con sitios de comunicación en inglés y mi perfil en español, para realizar las pruebas de concepto que he estado haciendo con antelación, no me afectaba mucho.

Ahora preparando unas entradas e ideas para el blog, con una seria de conceptos que creo que son interesantes, me he encontrado que esta casuística sí que me afecta si pretendo hacer despliegues en diferentes entornos o implementar componentes con llamadas API Rest.

Desarrollo de un caso de uso

En este apartado, se va desarrollar un pequeño caso de uso, con el fin de mostrar los errores y problemas que se pueden producir, al disponer culturas diferentes entre el sitio de comunicación y el perfil del usuario conectado.

Para este caso de uso se va a contar con los siguientes requisitos:

• Se quiere disponer una lista que almacene términos relacionados que se relacionaran con otros contenidos del sitio de comunicación en el futuro.
• Se tiene que permitir, deshabilitar un término para no ser usado más en otros contenidos del sitio de comunicación, sin tener que eliminar el término.
• El contenido de la lista de términos relacionados es gestionado por un grupo de usuarios concretos, los demás usuarios, solo podrán utilizar los términos relacionados que no estén deshabilitados.

La implementación de estos requisitos, se ha realizado de la siguiente manera:

1. Se crea la columna de sitio de tipo Sí o No, que va a encargar de controlar si el elemento de la lista está o no deshabilitado.

   

2. Se crea el tipo de contenido que se va a usar en la lista de términos relacionados.

   Este tipo de contenido, tendrá la definición de la columna de sitio, creada previamente.

   

3. Se crea un grupo de SharePoint, que es el encargado de gestionar el contenido de la lista de términos relacionados.

   El grupo de SharePoint que se crea, a nivel de toda la colección de sitios, su nivel de permisos es el de lectura.

   

4. Se crea la lista de términos relacionados y se establecen las siguientes configuraciones:

   • Se configura el nuevo tipo de contenido a la lista

   • Se configura las vistas de la lista para que se muestre el contenido de una forma coherente al usuario

   • Se configura los niveles de permisos de la lista para los usuarios lectores y los usuarios que tienen permisos para gestionar su contenido.

     

Problemas derivados de trabajar con culturas distintas

Ahora que ya se dispone de la lista de términos relacionados, se van ir numerando algunos de los problemas que se nos puede dar, debido a tener un perfil con una cultura diferente a la cultura principal del sitio web de comunicación.

La visualización de lista no es idéntica

Uno de los problemas que se producen independientemente del entorno de la colección de sitios, es que, dependiendo de la cultura del usuario conectado, al acceder a la lista, los usuarios no se visualizan de igual forma la página, teniendo los mismos niveles de permisos en la colección de sitios.

Esto se releja en primeramente en el título de la lista, ya que no son los mismos par usuarios distintos.

• Para unos usuarios, el título de la lista viene proporcionado por el valor de la propiedad 'Title' de la definición de la lista.
• Para otros usuarios, el titilo de la lista viene proporcionado creo por el valor de la propiedad 'Name' que contiene de la propiedad 'RootFolder' de la definición de la lista.

Otro caso en el que la visualización de la página no es idéntica para los perfiles de usuarios conectados, son los nombres de las columnas personalizadas dentro de la lista.

• Para unos usuarios, el nombre de la columna viene proporcionado por el valor la propiedad 'DisplayName' de la columna definida en la lista.
• Para otros usuarios, el nombre de la columna viene proporcionado creo por el valor de la propiedad 'StaticName' de la columna definida en la lista.

Además de estos casos más evidentes, hay más, que al final echan a perder la experiencia de usuario, ya que el interfaz de usuario de no es coherente, mostrando un interfaz en el que se mezclan diferentes idiomas a la vez, o nombres internos que solo son relevantes al equipo técnico, pudiendo confundir a los usuarios del portal web.

Lista 'Términos relacionados' desde un perfil en español

Lista 'Términos relacionados' desde un perfil en inglés

Las plantillas de aprovisionamiento de sitios web no son idénticas

A la hora de desarrollar componentes y estructuras en SharePoint Online, es muy necesario generar plantillas de aprovisionamiento para poder desplegar las actualizaciones o nuevas implementaciones en los entornos superiores de nuestra organización.

Por eso, al generar estas plantillas de aprovisionamiento a través de un mismo script, pero ejecutado con usuarios que disponen de los mismos permisos dentro de la colección de sitios, pero una configuración de cultura distinta a nivel de su perfil de usuario, estas plantillas generadas, muestra diferencias considerables.

Este tipo de diferencia, deben de controlar, en los 'Pull Request' del repositorio de código fuente de nuestros desarrollos.

Aunque en la mayoría de las veces afecta únicamente a los títulos de listas o columnas, puede ser más grabe si esta diferencia se aplica sobre los permisos que tuvieran los listas, bibliotecas o los sitios web. Pudiendo en un entorno productivo eliminar o cambiar permisos al realizar una actualización, dejando el portal web caído por una mala configuración o aún peor, permitiendo el acceso a contenido restringido a usuarios no autorizados previamente.

NOTA IMPORTANTE: El motivo de redactar esta entrada en el blog, estaba motivado por un mal comportamiento de la aplicación de permisos en listas a través de plantillas de aprovisionamiento, ya que, la seguridad aplicada en el entorno de desarrollo, no se había aplicado en un entorno de preproducción, provocando que no funcionada las cosas en las pruebas realizadas.

Pero entro 'La ley de Murphy', cuando estaba redactando esta entrada en el blog, no he conseguido reproducir el error para este caso de uso, así que no puedo demostrar el problema de permisos al generar las plantillas de aprovisionamiento con perfiles de usuario distintos.

Errores en las llamadas API Rest

Desde los orígenes de SharePoint, el acceso al contenido de las listas, se ha realizado a través del título de la lista. En mi experiencia, este modo de acceso, siempre ha sido un error, ya que en cualquier momento se puede cambiar su nombre de la lista, requiriendo que se compile o se generen nuevos paquetes de actualización para los entornos o lo que es peor las aplicaciones web dejen de funcionar, sin saber el motivo.

Para SharePoint Online, no iba a ser distinto, ya que se sigue obteniendo los elementos de las listas a través del título de la lista. Ya que no es posible generar/crear las listas proporcionando nosotros mismo el GUID de la lista, como se sucede por ejemplo en columnas y tipos de contenido.

https://{site_url}/_api/web/lists/GetByTitle('List Title')

Al realizar estas llamas API Rest sobre la lista de términos relacionados en los diferentes entornos, se han obtenido los siguientes resultados.

• En el entorno de desarrollo, al realizar una consulta API Rest, la respuesta del servidor es que no existe la lista por el título proporcionado.

  

• En el entorno de preproducción, al realizar una consulta API Rest, la respuesta del servidor es favorable y devolviendo los elementos de la lista.

  

Si lo que, desde los orígenes de SharePoint, se ha estado utilizando, empieza a fallar, por tener configurado la parte del 'Backend' en múltiples idiomas, esto puede afectar a los desarrollos de los componentes SPfx o flujos de Power Automate implementados hasta ahora.

¿Cómo solventar estos problemas en el portal de comunicación?

Ante estos problemas e inconvenientes a la hora de implementar soluciones, derivados de las culturas de los perfiles de usuarios al estar trabajando en una colección de sitio de una cultura distinta, la solución pasa por configurar correctamente la parte 'Backend' de la colección de sitio.

De esta forma independientemente de la cultura configurada en el perfil de usuario, se va a trabajar con la cultura predeterminada en el portal de comunicación.

NOTA IMPORTANTE: La anulación de las culturas en el 'Backend', no anula la posibilidad de hacer multi lenguaje un portal de comunicación.

La anulación de las otras culturas en la parte 'Backed' del portal de comunicaciones se realiza con los siguientes pasos:

1. Acceder a la 'Configuración del sitio' del portal de comunicaciones

2. En la sección 'Administración de sitios' acceder a la página 'Configuración de idioma'

3. En la nueva página, pulsar en la opción 'Mostrar configuración avanzada', para mostrar más opciones.

4. En la sección 'Idiomas disponibles' desmarcar todas las culturas disponibles.

   

5. Guardar los cambios.

6. A partir de aquí, el portal se muestra con la cultura predeterminada de la colección de sitio.

Hay que indicar, que con PowerShell PnP, se puede generar una plantilla con esta configuración idioma para una colección de sitios, y no tener que desactivar manualmente todas las culturas cada vez que se tenga que recrear el entorno para comprobar que todo lo desarrollado hasta ahora, esta correctamente integrado con las especificaciones del cliente.

La sentencia de 'PowerShell PnP' para la generación de la plantilla seria la siguiente:

Get-PnPSiteTemplate -Out "[Ruta\NombrePlantilla.xml]" -Force " -Force -Handlers SupportedUILanguages

Con este simple ajuste en la colección de sitios, los comportamientos raros o incorrectos mencionados con anterioridad, utilizando usuarios con perfiles de cultura diferentes, ya no se reproducen, dejando los desarrollos más homogéneos y mejor preparados para la gestión al cambio en el futuro.