Configuración Básica de Permisos

Configuración permisos KMKey

Por defecto KMKey viene con los siguientes grupos de permisos asociados a roles de CPS, y configurados como Perfiles de Aplicación:

- Lector Aplicación (WorkspaceReader)--> Ver Contenido (y Listar)
- Usuario Aplicación (WorkspaceMember)--> Ver, Crear y Modificar
- Responsable Aplicación (WorkspaceManager) -->Ver,Crear,Modificar,Gestionar equipo y Planificar

Estos permisos se pueden configurar desde la gestión de grupos, pero respetando la coherencia de cada uno de los grupos. Por ejemplo, por comodidad, podemos tener la tentación de dar permiso de escritura al 'Lector de Aplicación' , pero lo correcto es agregar los usuarios al grupo 'Usuario Aplicación'.

Por defecto, Lector Aplicación está asociado a authenticated (vía ZMI), a nivel de site, de tal forma que cualquier usuario que se logine , podrá entrar al KM (pero no podrá ver expedientes, ya que por defecto, en los patrones, se bloquea Lector y Usuario)
Opcionalmente, También podemos asociar authenticated a Usuario Aplicación si queremos que todo el mundo pueda crear expedientes.

Por otro lado tenemos los siguientes grupos de permisos asociados a roles, pero no activados como Perfil de Aplicación, si no que serán perfiles de Expediente (sólo actuarán a nivel de expediente)

- Lector Expediente (Reader) --> Ver Contenido
- Propietario (Owner) --> Ver,Crear,Modificar,Gestionar Equipo,Planificar
- Responsable Expediente (Responsable) --> Ver,Crear,Modificar,Gestionar Equipo,Planificar

Por defecto, cuando se crea un objeto dentro de KM, se asigna automáticamente el usuario que lo crea como Owner (si no, una vez creado, no podría acceder a él)
Para dar acceso a un usuario dentro de un expediente, podemos agregarlo como 'Lector Expediente' y en este momento podrá verlo
Para dar permisos de Modificación u otros a un usuario dentro de un expediente, crearemos los nuevos perfiles de expediente necesitemos (Técnico, Secretaria, etc...) intentando unificar y utilizar el menor número de perfiles posibles

Con esta configuración mínima, ya podemos gestionar los siguientes casos:

- Todo usuario podrá entrar a la aplicación y ver expediente, contactos y grupos
- Todo el mundo que pertenezca a 'Usuario Aplicación' podrá crear cualquier tipo de expediente (ya pertenezca al grupo de forma implicita o vía asignación a authenticated)
- Todo el mundo verá únicamente los expedientes donde esté asignado (Como creador , lector u otro)

Esta configuración contempla la mayoría de casos que necesitaremos

Configuraciones avanzadas:

Como hemos comentado antes, creando nuevos perfiles de expediente determinaremos qué podrá hacer cada usuario dentro de cada expediente (Técnico podrá añadir, pero no planificar, Responsable Delegación podrá planificar, etc... )

En la configuración de patrones, tenemos las dos utilidades siguientes:

1- Qué perfiles pueden participar y qué perfiles se bloquean (Opción 'Modificar') en los expedientes creados a partir de este patrón
2- Qué perfiles pueden ver o no el propio patrón (Acción 'Bloquear Perfiles')

La opción 1 nos permite configurar, por ejemplo (viene por defecto en todo nuevo patrón) que 'Usuario Aplicación' y 'Lector Aplicación' NO puedan ver los expedientes creados con este patrón.

La opción 2 nos permite bloquear el propio patrón, o sea, podemos bloquear el 'Usuario Aplicación' para que NO pueda crear expedientes de determinado tipo

Estas configuraciones también son aplicables a los patrones de Píldoras, permitiendo seleccionar qué perfiles podrán o no crear ventas, horas, etc...

Ejemplos:

Caso: Queremos que TODO usuario loginado vea los expedientes de determinado tipo:
Configuración : Patrón --> Modificar --> Roles Bloqueados --> Desactivar 'Lector Aplicación' (Esto lo podemos hacer también a nivel de un expediente, en gestionar contactos, desactivando el perfil bloqueado)

Caso : Queremos que únicamente el 'Responsable Aplicación' pueda crear expedientes con el patrón 'Oferta'
Configuración : Patrón --> Bloquear Perfiles --> Columna de perfiles bloqueados --> activarlos TODOS menos el de 'Responsable de Aplicación'. (Nota : Esta configuración tiene el 'problema' que, cuado añadamos un nuevo perfil de aplicación, deberemos revisar los patrones para bloquear este nuevo perfil, si es necesario, ya que no se hace de forma automática)

La definición de los permisos se puede llegar a complicar bastante, así que és muy recomendable definirla bien desde el principio.

El caso más 'problemático' sería la creación o cambios de configuración en los Perfiles de Aplicación una vez ya se hayan introducido expedientes, lo que requiere, por un lado, revisar la configuración de los patrones, y por otro, reindexar todos los expedientes para que se apliquen los nuevos cambios (sólo en caso de modificación de un perfil existente)

La recomendación es NO CREAR NINGÚN perfil de aplicación, utilizar únicamente los 3 que ya viene por defecto (Lector Aplicación, Usuario Aplicación y Responsable Aplicación) y gestionar los accesos a los patrones mediante los bloqueos de grupos de sistema, siguiendo la misma técnica q hemos comentado antes, ya que se puede aplicar a cualquier perfil, y solucionamos la problemática antes comentada

finalmente tendríamos el caso de de que queramos dar acceso a un grupo determinado a los expedientes de determinado patrón. Esto la haremos creando un campo del tipo 'KM Relation' en el schema, con un default value y un write expression string:docid_de_grupo, y asociado al role Reader, de tal forma q se asignará automáticamente al crear el expediente, una asoación entre el grupo y el perfil Reader, lo que dará acceso al expediente.

De esta forma se pueden ir añadiendo funcionalidades y cada uno sigue
viendo lo suyo, y solucionamos el problema que produce añadir un nuevo
perfil de aplicación con respecto a los expedientes existentes de
otros departamentos.






Etiquetas: