Feature - Grupos de seguridad - Reglas de herencia por módulo

[juanSTIC]

Visión General

Se ha añadido una funcionalidad que permite una gestión avanzada y personalizada de las reglas de herencia de Grupos de Seguridad en SuiteCRM. Esta se enfoca en la activación selectiva de reglas específicas para diferentes módulos, brindando mayor flexibilidad y control sobre la aplicación de los Grupos de Seguridad en diversos contextos del sistema. La configuración de esta funcionalidad se lleva a cabo a través del módulo de nueva creación Reglas de Grupos de Seguridad (stic_Security_Groups_Rules), ofreciendo opciones detalladas como la herencia de grupos de seguridad basada en usuarios asignados, creadores del registro o registros padre, y la exclusión de ciertos grupos de seguridad. Esta herramienta permite a las administradoras y administradores definir con precisión cómo se heredan y aplican los Grupos de Seguridad en todo el sistema.

Este PR aborda únicamente aspectos de los Grupos de Seguridad relacionados con la herencia, dejando otras posibles mejoras para desarrollos futuros.

Activación de la Funcionalidad

• La funcionalidad completa del módulo se activa o desactiva mediante la configuración Habilitar reglas personalizadas de herencia de Grupos de Seguridad por módulos disponible en Admin > Configuración de Grupos de Seguridad.
• Si esta configuración no está activa, es posible modificar las Reglas de Herencia Personalizadas por módulos, pero no se aplicarán.

Configuración de Reglas de Herencia Personalizadas

Se realizan mediante la vista de lista y/o edición del nuevo módulo. Los campos son los siguientes:

• name: Nombre del módulo de configuración. Identifica la configuración específica para un módulo.
• active: Campo tipo checkbox que indica si las reglas personalizadas de herencia deben aplicarse o no al módulo del registro. Si no está activado, se aplicarán las reglas globales definidas en la configuración de Grupos de Seguridad; en caso contrario, se aplicarán las reglas personalizadas de este módulo.
• inherit_assigned: Define si se heredan los Grupos de Seguridad del usuario asignado al registro.
• inherit_creator: Habilita la herencia de los Grupos de Seguridad del usuario que creó el registro.
• inherit_parent: Establece si se deben heredar los Grupos de Seguridad de todos los registros padre. Este campo se desactiva automáticamente si se ha especificado algún módulo en el campo inherit_from_modules.
• inherit_from_modules: Campo de selección múltiple que determina de qué módulos y mediante qué relación específica se deben heredar los Grupos de Seguridad del registro de destino. En este campo están disponibles como opciones las relaciones 1:1 o 1:n, y los campos relacionados (relate) del módulo.
• non_inherit_from_security_groups: Campo de selección múltiple para especificar qué Grupos de Seguridad no deben ser heredados por el registro. Los Grupos de Seguridad indicados aquí no se heredarán, aunque formen parte de los grupos del usuario creador, usuario asignado o de cualquiera de los registros padre.

Detalles Relevantes

• Reglas de Herencia Custom y Estándar:

  • Las reglas de herencia custom por módulo tienen prioridad sobre las reglas de herencia estándar de los Grupos de Seguridad aplicables a todos los módulos.
  • Si un grupo de seguridad tiene marcada la propiedad No heredable, esto se respeta al aplicar las Reglas personalizadas por módulo.
  • Los Grupos de Seguridad indicados en el apartado global Grupo por defecto para nuevos registros para un módulo específico, serán añadidos al crear un nuevo registro (no es lo mismo que heredados), independientemente de que el propio GS esté indicado como No heredable, (es el funcionamiento propio de SuiteCRM) o aunque esté entre los Grupos de Seguridad No heredables en el nuevo módulo.

• Vista de Lista de Reglas Personalizadas:

  • Se ha creado una vista de lista custom que muestra exclusivamente los módulos habilitados en el Menú.
  • Los registros en este módulo se crean automáticamente si no existen al cargar la vista, por lo que si se añade un nuevo módulo custom, este aparecerá automáticamente con el estado y el resto de opciones desactivadas. No se permite la creación de nuevos registros manualmente.
  • En la vista de lista solo se mantienen las opciones de Actualización masiva y eliminar. Al eliminar registros, estos se regeneran de inmediato.
  • Si la configuración Habilitar reglas personalizadas de herencia de Grupos de Seguridad por módulos está deshabilitada, se muestra un mensaje de advertencia en las vistas de lista y de edición, indicando que, aunque haya reglas definidas, no se aplicarán hasta que se active la funcionalidad.

• Acceso y Vista del Módulo:

  • El acceso a la vista de lista del módulo está disponible en el menú "Configuración de Grupos de Seguridad" como un nuevo icono.

• Proceso de Aplicación de Reglas:

  • Si hay una regla activa (active=true) para el módulo actual, se aplicarán las reglas de herencia indicadas en el registro; en caso contrario, se aplicará la configuración global de herencia de Grupos de seguridad.
  • Se ha modificado la función inherit() en el fichero del core modules/SecurityGroups/SecurityGroup.php para verificar si está activada la funcionalidad y si hay una regla definida para el módulo en el que se está guardando el registro. En caso afirmativo, aplica las reglas de herencia correspondientes al módulo, omitiendo las reglas generales; en caso contrario, ejecuta las reglas generales.

Pruebas a Realizar

1. Verificación de Activación de Funcionalidad:

   • Comprobar que, al activar la configuración Habilitar reglas personalizadas de herencia de Grupos de Seguridad por módulos en Admin > Configuración de Grupos de Seguridad, la funcionalidad se habilita correctamente.
   • Verificar que, con la funcionalidad desactivada, las Reglas de Herencia Personalizadas no se aplican, aunque siguen siendo modificables.

2. Pruebas de Configuración de Reglas de Herencia Personalizadas:

   • Crear diversas configuraciones en el módulo Grupos de Seguridad - Configuración Avanzada con diferentes combinaciones de reglas (herencia asignada, creador, registros padre, exclusión de ciertos grupos, etc.).
   • Comprobar que las configuraciones guardadas se aplican de acuerdo con las especificaciones establecidas.

3. Validación de Prioridad de Reglas Custom sobre Estándar:

   • Establecer reglas de herencia custom y estándar contradictorias y verificar que las reglas custom tienen prioridad.

4. Revisión de la Funcionalidad de No Heredables:

   • Asignar la propiedad No heredable a un grupo de seguridad y comprobar que se respeta esta configuración en las Reglas personalizadas por módulo.

5. Verificación de la Asignación de Grupos por Defecto a Nuevos Registros:

   • Asignar grupos de seguridad a un módulo directamente mediante la opción de Grupos por Defecto para nuevos registros, y comprobar que estos grupos se asignan correctamente, independientemente de que estén definidos como Grupos no Heredables en el propio grupo de seguridad o que figuren en la lista de Grupos no Heredables en el nuevo módulo.

6. Comprobación de la Vista de Lista de Reglas Personalizadas:

   • Acceder a la vista de lista custom y confirmar que muestra todos los módulos habilitados.
   • Verificar que, al deshabilitar la funcionalidad, aparece el mensaje de advertencia correspondiente en las vistas de lista y edición.
   • Crear un nuevo módulo custom desde el constructor (o importar uno existente) y verificar que aparece automáticamente en la vista de lista.
   • Eliminar uno, varios o todos los registros y verificar que se crean nuevamente con todos los campos (excepto el nombre) vacíos.

7. Testeo del Proceso de Aplicación de Reglas:

   • Crear nuevos registros en diferentes módulos y verificar que se aplican correctamente las reglas de herencia definidas.
   • Crear nuevos registros mediante importación y verificar que se aplican igualmente las reglas definidas.
   • Crear registros desde subpaneles comprobando que las reglas se aplican adecuadamente.
   • Probar expresamente la herencia del registro padre desde relaciones 1:n, n:n y campos relacionados

NOTA: sin que afecte en nada a la funcionalidad descrita, se aprovecha el PR para eliminar restos de 3 módulos que llegaron de manera errónea a SinergiaCRM hace tiempo: SharedSecurityRules, SharedSecurityRulesActions y SharedSecurityRulesConditions

[github-actions]

Actions executed at: 2024-01-18 09:04:34.

[juanSTIC]

nherit from all parent records", no funciona correctamente.
Pasos:

Ahora sí que funciona correctamente la herencia de registro Padre cuando se selcciona algún módulo, pero en el caso de seleccionar la opción de "Inherit from all parent records", no funciona correctamente. Pasos: 1- Activar la regla "Inherit from all parent records" para el módulo Documentos sin ninguna otra modificación. 2- Desde una Persona crear un Documento, este no hereda los grupos de la Persona.

Corregido

[enricsinergia]

Cambiaría el nombre de esta función y un poco la SQL. Le llamaría getSticUserInheritableSecurityGroups y no devolvería ningún grupo no heradable (sea por la relación grupo-usuario o en la propia definición del grupo). El nombre actual induce a error (no habla de que sólo devuelve heredables y la explicación y la SQL no acaban de encajar al 100%: la descripción dice que se excluyen los no heredables, pero la SQL sólo excluye los no heradables según la relación usuario-grupo). Y para nota, haría lo que comentamos: un flag que me diga si quiero todos o sólo los no heredables pensando en el futuro, pero ahora no es necesario.

[enricsinergia]

(A)provado

Aparte de lo comentado sobre la función getSticUserSecurityGroups (tema menor), todo parece OK.
Pruebas realizadas:

• Relaciones 1:n, N:1, M:N, 1:1
• Creación directa y desde subpanel
• Creación de compromiso y pago con distintas reglas de herencia
• Creación pago vía batch
• Creación vía Workflow
• Distintas herencias separadas y en combinación con grupos disyuntos y coincidentes
• Grupos no heredables, no heredables para usuario (presente y no presente en otras herencias), grupos prohibidos según la regla
• Múltiples relaciones con el mismo módulo

Anteriormente:

• Creación vía API
• Creación vía Importación
• Merge de registros

[AlbertoSTIC]

(A)probado

[enricsinergia]

(A)provado

(Comprobado que los métodos se invocan correctamente ;-) )