Asignar permisos únicos a elementos en listas de SharePoint

¡Muy buenas!

Ya tocaba empezar a actualizar el blog con contenido M365 y esta primera entrada no es casual. Los espacios de colaboración de SharePoint son utilizados de mil modos distintos por organizaciones de todo el mundo, tanto por usuarios internos a la organización como externos.

Un escenario que curiosamente me he encontrado muchas veces es la colaboración en listas o bibliotecas de documentos donde un grupo de usuarios tiene acceso, pero no todos los usuarios deben tener los mismos permisos sobre la lista. Entonces se plantea solución rápida: rompemos herencia de permisos respecto al sitio y asignamos por grupo de usuarios qué permisos les pertenecen sobre la lista (editar, leer, control total...).
Pero no, el caso es un poco más complejo: necesitamos que algunos usuarios tengan, por ejemplo, permisos de lectura solo sobre algunos elementos de la lista; o que un grupo de usuarios solo pueda editar sus propios elementos. Vamos a ver qué soluciones tenemos:

Solución 1 - vía configuración de la lista

En este caso SharePoint nos lo pone bastante fácil a nivel de configuración de la lista podemos resolver el escenario cuando los usuarios están creado ellos mismos, manualmente, los elementos:

  • Vamos a List Settings -> Advanced Settings y ahí encontramos el apartado "Item-level permissions"
  • Vemos que tenemos la opción de asignar permisos únicos de lectura o escritura para los elementos. La propia configuración es bastante clara: podemos limitar que solo el usuario que ha creado el elemento pueda verlo y editarlo.
Hay que tener algo claro: 


Esta limitación de permisos solo se aplica a usuarios con permisos "Colaborar" y "Editar", es decir que si el usuario tiene "Diseño" o "Control total" sobre la lista, esta configuración de permisos únicos no funcionará para estos usuarios. ¡Importante tenerlo en cuenta!

Pero a todo esto... ¿y qué sucede si una aplicación externa está creando los elementos?

Solución 2 - asignación de permisos únicos por HTTP


Sinceramente esta es la solución que ha resuelto el 80% de mis escenarios, pero creo que también era importante entender la Solución 1 y sus limitaciones. Podemos atacar la API de SharePoint para romper la herencia de permisos que recibe el elemento de la propia lista y asignar nuevos permisos. Esta solución es muy práctica cuando desarrollamos soluciones en Power Automate, Logic Apps, Azure Functions, etc.

Sabéis que no me gusta dejar ni un cabo suelto, así que intentaré que sea lo más completo posible. Para ello he decidido mostrarlo como se hace en Power Automate, se verá más esquemático y bonito que en varias líneas de llamadas HTTP.

Primero aclarar que si bien podríamos trabajar con usuarios individuales, me gusta asignar los permisos por grupos (aunque sea un grupo de una persona). Se hace más entendible añadir permisos a grupos específicos, que a usuarios (que si perdemos el usuario en la plataforma, deberemos retocar los permisos). Pero eso ya dependerá del escenario y vuestras preferencias.

Entonces supongamos que tenemos el grupo "Estudiantes", podemos hacer una llamada a la API de SharePoint para recuperar la ID del grupo o tenerla ya preguardada en una variable. Así sería la llamada:


Una llamada a la API de SharePoint con un pequeño filtro por nombre. Así obtenemos las propiedades de vuelta, entre ellos la ID: 27.

Entonces vamos a proceder rompiendo la herencia de permisos del elemento de la lista, podemos hacerlo de dos modos: o dejamos los roles por defecto de la lista, o lo rompemos sin ningún tipo de permiso asignado al elemento (solo los site collection admins van a poder gestionarlo).

Se hace con la partícula copyRoleAssignments, "true" para mantener de base los permisos de la lista, o "false" para borrarlos. Soy bastante fan del segundo, facilita bastante y deja claro de dónde partimos.



A partir de aquí deberemos asignar los permisos a cada grupo que queramos. Recuerdo que los administradores de la colección de sitios siempre podrán verlo, pero por si acaso tuviéramos otros grupos intermedios como "agentes" que pudiesen ver también todos los elementos, habría que añadirles los permisos también.

Necesitamos la ID de rol de permisos a parte de la ID de grupo, esta ID acostumbran a ser únicas para permisos por defecto (Leer, Contribuir, Control total...), pero no está de más hacer una llamadita a la API de SharePoint para saber la ID exacta del rol de permisos. Podemos hacerlo con Power Automate o como he dicho antes, tenerlo preguardado en una variable.

La url es: https://[sitio SharePoint]/_api/web/RoleDefinitions




Efectivamente puedo ver que la ID para solo una lectura del elemento (recomendaría añadir el de Editar, pero esto solo es un ejemplo) es 1073741826.

Entonces solo nos queda lanzar una petición a SharePoint con estos valores donde principalid es la ID del grupo al que quiero dar permisos y roleDefId es la ID de rol de permisos que hemos extraído en último paso.



Pues en principio ya está :) Hemos roto la herencia de permisos, hemos asignado permisos únicos y ahora cada usuario tiene sus propios permisos para cada elemento de la lista.

No dudéis en preguntarme lo que sea, este tema daría para una tesis en SharePoint jejeje recuerdo que cuando trabajamos con permisos únicos podemos caer en escenarios tan pintorescos como el de Acceso Limitado ;)





Previous
Next Post »