Muchos me imagino que habréis tenido que dar de alta usuarios y definir los permisos de acceso a la aplicación.  AX es tan flexible a la hora de dar los permisos, que permite definir estos accesos hasta el detalle de un campo de una tabla o un botón de un formulario.

Para quien no se haya puesto todavía con estas tareas para que vean lo versátil que es la aplicación, comentaré unas directrices para llevar a cabo esta definición de accesos:

  • La seguridad se define a nivel de grupo de usuarios, por defecto la aplicación crea el grupo Admin, por lo tanto es recomendable ir de menos a más e ir cerrando el acceso de la aplicación y crear un grupo nuevo porque Admin no se puede modificar.
  • Si se desarrolla nueva funcionalidad en la aplicación, para que se tengan en cuenta a la hora de definir los accesos, se deben definir claves de seguridad o security keys, las cuales podemos hacer que hereden de una estándar si es una ampliación de funcionalidad estándar, o crear unas nuevas que no heredan de esta si es una funcionalidad completamente nueva.
  • Otro concepto que se usa es claves de configuración o configuration keys, pero estas no se usan para definir los accesos a la aplicación pro grupo de usuarios, sino para activar / desactivar completamente una funcionalidad para todos los grupos de usuario..
  • Para definir los permisos es recomendable hacerlos primero a nivel de menú principal, para guiarse  según lo que se quiere que se vea en la aplicación, y luego ir depurándolo a nivel de seguridad.

image

image

  • Mientras lo estamos haciendo a nivel de menús, tener cuidado e ir poco a poco mirando todo lo que cuelga de un formulario porque puede haber funcionalidad que queramos restringir o permitir y si no bajamos a los diferentes niveles, es posible que no nos percatemos que tiene sub claves de seguridad. 

image

Una vez definido un grupo con los permisos pertinentes debemos asociarle el usuario que utilizará ese grupo, tener en cuenta que a la hora de utilizar los grupos va de lo más abierto a lo más cerrado, por lo que si asocias a un usuario 2 grupos y uno es menos restrictivo que el otro, cogerá los del primero.

Si son muchos los grupos que se van a manejar en una instalación, y se va a tener diferentes niveles de acceso, la tarea de definir grupos puede resultar demasiado tediosa. En una implantación reciente nos ocurrió esto, por lo que creamos una utilidad a nivel del formulario de grupo para permitir duplicar los grupos de usuario de una forma rápida incluyendo los permisos asociados a dicho grupo duplicado.

Para ello en el formulario de grupos de usuario (SysUserGroupInfo) vamos a incluir un botón que sea duplicar grupo.

image

Este botón llamará a la clase AX3DuplicateRol cuyos métodos son los siguientes:

class AX3DuplicateRol extends RunBase { 
 UserGroupInfo _UserGroupInfo;
SysGroup idgroup;
Name name;
DialogField dgroup, dname;
}

// Se le pasa como parámetro el grupo de usuarios que se desea duplicar
void new(Args args)
{

super();

if (args.record())
{
_UserGroupInfo = args.record();
}

}

//Pide como parámetros el grupo nuevo que se crea y la descripción
public Object dialog(DialogRunbase dialog, boolean forceOnClient)
{

;

dialog = super(dialog, forceOnClient);
dialog.caption("Duplicar Role");
dgroup = dialog.addField(TypeId(SysGroup));
dname = dialog.addField(TypeId(Name));

return dialog;

}

//El método run crea el grupo nuevo y copia los premisos del grupo que ha copiado.
public void run()
{
ACCESSRIGHTSLIST _ACCESSRIGHTSLIST,_ACCESSRIGHTSLIST2;

UserGroupInfo UserGroupInfo2;

ttsbegin;

select UserGroupInfo2

where UserGroupInfo2.id == idgroup;

if(! UserGroupInfo2)
{
UserGroupInfo2.clear();
UserGroupInfo2.id = idgroup;
UserGroupInfo2.name = name;
UserGroupInfo2.insert();
}

while select _ACCESSRIGHTSLIST
where _ACCESSRIGHTSLIST.groupId == _UserGroupInfo.Id
{
_ACCESSRIGHTSLIST2.data(_ACCESSRIGHTSLIST);
_ACCESSRIGHTSLIST2.groupId = idgroup;
_ACCESSRIGHTSLIST2.insert();
}

ttscommit;
}
 

image

Espero que con esta utilidad de duplicar grupos, partiendo de un grupo duplicado sea menos tedioso la configuración de los permisos.

Visitas: 65

Etiquetas: 2009, ax, de, duplicate, dynamics, groups, grupos, permisos, roles, sysusergroupinfo, Más...usuario

Comentario por Jaime Morales Gonzalez Moro el marzo 9, 2011 a las 4:43pm

Seguridad a nivel de registro

Esta seguridad proporciona, que cada grupo de usuarios vea unos datos dentro de una tabla que otros grupos no pueden ver.

 

Un ejemplo es la imposibilidad de ver las cuentas del plan contable del grupo 6 y 7 para un grupo de usuarios determinado, o ciertos clientes, o ciertos proveedores, etc.

 

Cuando se entra en el formulario de seguridad a nivel de registro y se crea un nuevo registro aparece un asistente, que guía paso a paso para configurar dicha seguridad en un grupo de usuarios.

 

Así, se debe configurar el grupo de usuarios que se configura, las tablas que se van a restringir, y los registros que se podrán ver en la tabla seleccionada.

 

La forma de indicar que registros se van a ver y cuáles no, es muy sencilla, dado que el sistema muestra el típico formulario de selección que aparece en todo el sistema, para que se seleccionen aquellos registros que se quieren ver. Por lo tanto, el grupo de usuarios no puede ver los registros que no se hayan seleccionado

 

Serán los Key-user los que realicen esta restricción a los usuarios.

 

 

 

 

 

 

Menú/Administración / Configurar / Seguridad / Seguridad a nivel de registro

Comentario por Alfonso San Jose Castro el mayo 26, 2011 a las 4:45am

Excelente aporte. Agiliza cantidades la tarea de configuracion de los permisos.  Gracias.

Comentar

¡Necesitas ser un miembro de El Rincón Dynamics para añadir comentarios!

Participar en El Rincón Dynamics

© 2012   Creado por Antonio Gilabert.

Emblemas  |  Reportar un problema  |  Términos de servicio