Malas prácticas para dar permisos a una columna de una lista a un grupo de usuarios - Blog de David Alonso. Microsoft SharePoint, Office 365, Azure y otras tecnologías Microsoft

Blog de David Alonso. Microsoft SharePoint, Office 365, Azure y otras tecnologías Microsoft

Microsoft SharePoint, Azure, Office 365

miércoles, 3 de octubre de 2012

Malas prácticas para dar permisos a una columna de una lista a un grupo de usuarios

Estos días nos hemos encontrado con un problema para un proyecto. Resulta que tenemos una lista de datos de usuarios (lista personalizada de SharePoint) que los usuarios e un portal han de rellenar. Cuando rellenan esta lista, los miembros de la empresa (usuarios internos), han de rellenar mas datos que el usuario. Esos datos son sensibles a ver por el usuario, es decir "privados" para los usuarios Internos.

Nos encontramos con el primer problema. Hay que darle permisos a unas columnas de una lista a un numero de usuarios.

Voy a enumerar un numero de soluciones que hemos ido afrontando y que no nos han resultado de ayuda.

1. Crear dos formularios diferentes para cada tipo de usuario. Con el designer, podemos crear 2 formularios NewForm.aspx, 2 EditForm y 2 DispForm, de manera que cuando entre un usuario acceda a unos o a otros. (No voy a explicar como hacer para que unos entren en un formulario y otros en otro, pero habria que utilizar audiencias o modificar el comportamiento del link "Agregar nuevo elemento", boton de editar, etc, con el designer).
Problema: Un formulario(para usuarios finales) era el NewForm, el otro (administrdores o usuarios internos) NewFormAdm.aspx. Si yo accedo como usuario final al NewForm.aspx y modifico la url NewFormAdm.aspx ME SALE ESE FORMULARIO.

2. Desarrollar un custom control, que muestre un TextBox, combobox, dropdownlist, en funcion de un grupo de usuarios. Interesante y FUNCIONA
Problema: El dato no aparece en los formularios, pero si en las vistas de las listas.

3. Utilizar ECMA Script para capar permisos: En otra ocasion mostraré como hacer esto, pero basicamente era ocultar por javascript en funcion de un grupo de usuarios.
Problema: Si deshabilito javascript APARECEN LOS DATOS.

4. Continuamos con el 3, hacemos que si esta deshabilitado javascript, ocultamos la pagina. (luego pongo un post de esto).
Problema: si ponemos un display:none si esta jvascript deshabilitado, APARECE EN EL CODIGO FUENTE, un usuario con conocimientos utilizaria un navegador o herramientas como firebug, para facilmente mostrar los datos. Esto se debe a que el servidor no es el que comprueba si el navegador(cliente) tiene habilitado javascript, con lo cual los datos son enviados desde el servidor al cliente, y es este ultimo el que lo oculta. Deberiamos de NO ENVIAR los datos desde el servidor.

5. Continuamos el 4. Si comprobamos al hacer login si tiene javascript o no, para avisarle y que el servidor no envie datos.
Problema: ¿y si el usuario entra con javascript habilitado, y lo deshabilita despues? Volvemos al caso 4.

6. Creamos con designer unas paginas aspx en la libreria de Paginas e introducimos los formularios de nuevo, edit y disp. Esas paginas tienen permisos
Problema:Seguimos sin capar la columna para las vistas. Si genero una vista con unos campos que el user no puede ver, igual lo consigue con conocimientos de SharePoint, por mucho que pongamos filtros en paginas.


SOLUCION: Como este problema se nos da en muchas listas, no nos quedo otra que realizar siempre 2 listas, una para el usuario final, y otra solamente con permisos a los usuarios internos (lista y lista extendida). La pagina que muestre los datos del usuario y edit, mostrará una pestaña "Datos extendidos" que será añadir los campos del otro elemento.

Cualquier otra solucion sera bien recibira ;)

Un saludo.

No hay comentarios:

Publicar un comentario