La gestión de permisos por grupo de usuario permite añadir ciertos criterios de seguridad sobre usuarios del sistema, según la categoría del usuario dentro del ámbito de la empresa. Estos permisos permiten establecer restricciones tales como ocultar datos de formularios, acotar el acceso a determinados procesos o acciones, o impedir la modificación de determinados datos. Gracias a estos permisos es posible, por ejemplo: Ocultar los precios en los formularios, restringir acciones como servir un pedido, o anular autorizaciones de otros usuarios, etc.

La gestión de los permisos por grupos de usuario consta de tres elementos básicos:

• Definición de permisos.
• Asignación de permisos a los grupos de usuario.
• Integración del permiso en la programación de la aplicación.

Para definir un permiso, el sistema dispone de tres entidades de parametrización: Agrupación de permisos, Permisos y Valores. Dichas entidades están relacionadas jerárquicamente, de manera que: los Permisos pertenecen a una Agrupación, y los Valores pertenecen a un Permiso. Dicha jerarquía permite mantener cierto orden a la hora de definir de los permisos.

A modo de ejemplo, pensemos en añadir permisos para restringir la Contabilización de albaranes y acuerdos, y restringir también la Generación de pedidos a partir de un acuerdo. Dada esta casuística, un forma correcta de definir los permisos sería añadir dos Agrupaciones: Albaranes y Acuerdos; posteriormente añadir un permiso de Contabilizar a la agrupación Albaranes, y los permisos de Contabilizar y Generar pedidos a la agrupación Acuerdos.

Como vemos, no se han definido en ningún momento Valores, esto es porque dichos valores no tienen sentido en permisos de tipo Verdadero/Falso, como los anteriores, únicamente serán necesarios al definir permisos que puedan tener múltiples valores. Por ejemplo, supongamos que queremos añadir otro permiso a Albaranes, que determine si: se puede ver, pero no modificar, los precios; o se puede ver y modificar precios. En esta ocasión deberíamos añadir el permiso Precios a la agrupación Albaranes, y posteriormente añadirle dos valores al permiso: Ver precios y Ver y modificar precios.

Como se cita anteriormente, cualquier permiso deberá pertenecer a una agrupación de permisos; en consecuencia, la parametrización de agrupación deberá ser el primer paso a la hora de definir los permisos. Esta parametrización se realiza mediante el formulario de agrupaciones de permisos.

La función principal de la agrupación, es la de aglutinar aquellos permisos que pertenezcan a un mismo ámbito; además, mediante la parametrización de ciertos valores comentados a continuación, la agrupación otorga una serie de propiedades o atributos a los permisos asociados a la agrupación. Algunos ejemplos de agrupación podrían ser: Contabilidad general, Cobros y pagos, Acuerdos de compra, etc.

Los campos de código y descripción permiten identificar cada agrupación de permisos, el primero es un mnemotécnico que identifica cada agrupación de forma unívoca, de manera que no podrán existir dos agrupaciones con un mismo código; por otra parte, la descripción, como su nombre índica, permite añadir un texto que resuma el ámbito de la agrupación de forma clara pero concisa.

El sistema dispone de una serie de permisos estándar, cargados automáticamente durante la creación de las estructuras de la base de datos; dichos permisos son utilizados por el sistema en formularios y procesos también estándar, tales como Apuntes contables, Facturas, Albaranes, etc. En consecuencia, la modificación de estos, podría ocasionar un mal funcionamiento del sistema; por este motivo, los permisos con el indicador de estándar activado, no podrán ser modificados ni borrados desde los formularios de parametrización de permisos.

El Módulo determina, de una forma muy genérica, el ámbito al que pertenece la agrupación y sus permisos. Este ámbito está directamente relacionado con los diferentes módulos funcionales que contempla el sistema:

• Finanzas
• Gestión
• Transportes
• Retail
• TPV
• Sanidad
• Mantenimiento
• CRM
• EDI

El próximo paso en la definición de permisos es la parametrización del permiso propiamente dicho, esta parametrización se realiza mediante el formulario de permisos de usuario.

Los campos de código y descripción identifican cada permiso, el primero es un mnemotécnico que identifica el permiso de forma unívoca dentro de cada agrupación, esto es, no podrán existir dos permisos con un mismo código en una misma agrupación; por otra parte, la descripción, permite añadir un texto que resuma la funcionalidad del permiso de forma clara pero concisa.

El indicador de asignación automática determina los permisos por defecto a asignar a cada nuevo grupo de usuarios. Es decir, en el alta de un nuevo grupo de usuarios, tanto de Finanzas como de Gestión, se asignarán automáticamente todos aquellos permisos que tengan este indicador activado, y se correspondan con un módulo activo en la base de datos actual.

En caso que un permiso tenga múltiples valores, permite asignar uno de estos valores, cuando se asigna el permiso sin especificar un valor concreto; por ejemplo en la asignación automática de permisos.

Únicamente tiene sentido informar este campo cuando existan valores para el permiso actual; de hecho, el formulario ya no muestra este campo cuando no existen dichos valores. En caso contrario, cuando existan valores, es requerido el informar un valor por defecto.

Este campo no tienen ningún valor funcional, pero es de vital importancia, ya que permite documentar cual será la funcionalidad del permiso, y las implicaciones que pueda tener su activación o desactivación, así como la asignación de los diferentes valores, si es el caso. A parte de esto, conviene indicar en qué puntos del sistema se utiliza el permiso, para facilitar cualquier ajuste en el programa, ante una modificación o eliminación del permiso, que pueda realizarse en el futuro.

La definición de valores no es estrictamente necesaria, los valores aportan mayor complejidad a la gestión de permisos. Un permiso sin valores es del tipo Verdadero/Falso, de manera que la simple asignación del permiso a un grupo de usuarios otorga dicho permiso (Verdadero), mientras que si este no está asignado, el permiso no estará habilitado (Falso). La definición de Valores permite definir estados del permiso que, además de indicar si un permiso está o no otorgado, indica una determinada propiedad del permiso, ampliando así su funcionalidad. La parametrización de valores se realiza mediante el formulario de valores de permiso.

Veamos por ejemplo una definición de valores estándar, utilizada para gestionar la Contabilización de documentos; el sistema, a la hora de contabilizar un documento, permite generar directamente una contabilización real, o bien una contabilización en diferido, que pasará a real posteriormente por un usuario autorizado. Partiendo otra vez del documento inicial, el sistema propone un permiso que indica si los usuarios pueden contabilizar un documento, y si esa contabilización se realizará en real o en diferido. Para establecer esta casuística se define un permiso Contabilizar, al cual se añaden dos valores: Real y Diferido. En el momento de asignar el permiso Contabilizar a un grupo de usuarios, deberá indicarse también uno estos valores. De esta manera, un grupo de usuarios puede no tener el permiso asignado, de manera que no podrá Contabilizar el documento, o puede tener el permiso asignado con un valor determinado, de manera que podrá contabilizar el documento o bien en real, o bien en diferido.

A la hora de definir valores simplemente deben informarse dos campos: código y descripción; estos identifican cada de valor, el primero es un mnemotécnico que identifica el valor de forma unívoca dentro de cada permiso, esto es, no podrán existir dos valores con un mismo código el mismo permiso; por otra parte, la descripción, permite añadir un texto que resuma la funcionalidad del valor de forma clara y concisa.

Como se menciona anteriormente, el sistema consulta los permisos para determinar que acciones realizar, o que datos debe mostrar y/o ocultar. Por este motivo, ante la inserción de un nuevo permiso, es de vital importancia asegurar que este prevalezca en las bases de datos que puedan crearse en el futuro. A continuación se citan una serie de puntos a tener en cuenta al dar de alta un nuevo permiso:

Al dar de alta una agrupación(cuserperh), un permiso(cuserperl), o un valor(cuserperv) estándar, el permiso deberá añadirse al Data(wic_table_object_data) de las tablas físicas correspondientes. De esta manera se garantiza la inserción del nuevo permiso en las bases de datos creadas posteriormente.

Añadir una conversión que inserte la definición del permiso, de manera que prevalezca dicho permiso en las bases de datos existentes. En este caso, es posible que tenga que realizarse una asignación del permiso a los grupos existentes, dependiendo de la lógica del permiso y los tipos de grupos existentes.

La traducción idiomática permite a cada usuario ver los permisos en el idioma que tenga asignado. Todos los permisos estándar están traducidos en varios idiomas, al definir un nuevo permiso, conviene traducirlo también en los idiomas posibles. Para obtener más información acerca de las traducciones idiomáticas consultar la documentación específica de traducciones.

En caso de añadir un permiso de asignación automática, se deberá añadir el permiso al Data(wic_table_object_data) de las tablas de permisos por grupo de usuarios (cuserauth, o guserauth en caso de tratarse de un permiso de gestión), para el grupo de usuarios public. De esta manera al crear una nueva base de datos se garantiza que grupo public tenga otorgado el nuevo permiso por defecto.

La asignación de permisos se realiza por grupo de usuarios, cada usuario puede tener asignado hasta dos grupos, uno para finanzas y otro para gestión. La asignación de estos grupos a un usuario, se realiza mediante el formulario de parametrización de usuarios. Cada uno de estos grupos contempla permisos diferentes, relacionados con el módulo que representan, Finanzas o Gestión; el grupo de Gestión abarca también el resto de permisos de otros módulos, como son Transportes, Sanidad, TPV, etc.

Desde los formularios de cada grupo (Finanzas y Gestión), es posible acceder al formulario de Permisos, a través de la pestaña con el mismo nombre. Este formulario muestra todos los permisos posibles a asignar a cada grupo; y permite añadir y quitar permisos a los diferentes grupos.

Una vez definidos y asignados los permisos a los diferentes usuarios, es posible integrar los permisos en el sistema, añadiendo restricciones en función de si un usuario tiene o no determinados permisos; para ello se proponen varias funciones que facilitan la consulta de permisos, el uso de una y otra depende principalmente del elemento a restringir, y el tipo de código que gestiona estos elementos.

La función cuserauth_allow, determina la existencia de un permiso para el usuario de actual; dicha función está implementada en código Javascript, y puede ser referenciada desde cualquier evento Javascript del formulario, así como desde la sentencia de activación de botones, o bien desde la sentencia para habilitar campos de entrada, en la definición de los campos en el Layout del formulario.

La función recibe tres valores cuserauth_allow(agrupación, permiso, valor), cada uno de estos parámetros hace referencia al código mnemotécnico de cada uno de las tres entidades que definen un permiso; el último parámetro (Valor), es opcional, y solo es necesario informarlo cuando se pretenda consultar si el usuario tiene otorgado un valor determinado del permiso indicado. La función simplemente retorna un booleano, indicando si el usuario actual posee el permiso indicado (true), o no(false).

En la medida de lo posible, es recomendado comprobar la existencia de un permiso mediante la función Javascript, ya que esta no requiere acceso a la base de datos, y por consiguiente, consume menos recursos del sistema.

if(cuserauth_allow("gcomacuh", "PRECIO", "MODPRE") == false)){
    setFieldNoentry("gcomacuh.imptot", true);
}

Otra forma de comprobar la existéncia de un permiso para un determinado usuario, es mediante una función XUDF, con el mismo nombre que la anterior cuserauth_allow; esta función es accesible desde cualquier parte del sistema, tanto en formularios como en procesos, o incluso triggers.

El XUDF recibe cuatro parámetros cuseraut_allow(usuario, agrupación, permiso, valor), a diferencia de la función Javascript, también recibe el código del usuario para el que se comprueba la existencia del permiso; en caso de no indicarse ningún usuario realiza la comprovación para el usuario de la base de datos con el que se conecta el usuario de . La función retorna un valor númerico (0/1), indicando si el usuario actual posee el permiso indicado (1), o no(0).

<set name='m_gcomalbh_contab' type='smallint'>
    <execute-function name='cuserauth_allow' type='integer'>
        <system.user.getCode />
        <string>gcomalbh</string>
        <string>CONTAB</string>
        <null />
    </execute-function>
</set>