Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 89 commits into from
Jan 18, 2024

Conversation

juanSTIC
Copy link
Collaborator

@juanSTIC juanSTIC commented Jan 2, 2024

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

Copy link

github-actions bot commented Jan 2, 2024

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

@juanSTIC juanSTIC marked this pull request as ready for review January 3, 2024 08:13
@juanSTIC juanSTIC linked an issue Jan 5, 2024 that may be closed by this pull request
@juanSTIC
Copy link
Collaborator Author

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

* @param string $userId The user's ID.
* @return array An associative array of groups with their IDs and names.
*/
public static function getSticUserSecurityGroups($userId)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 enricsinergia self-requested a review January 17, 2024 17:44
enricsinergia
enricsinergia previously approved these changes Jan 17, 2024
Copy link
Collaborator

@enricsinergia enricsinergia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(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

jalbaiges
jalbaiges previously approved these changes Jan 17, 2024
Copy link
Collaborator

@AlbertoSTIC AlbertoSTIC left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(A)probado

Copy link
Collaborator

@enricsinergia enricsinergia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(A)provado

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

@AlbertoSTIC AlbertoSTIC merged commit 5bf66c4 into develop Jan 18, 2024
1 check passed
@AlbertoSTIC AlbertoSTIC deleted the feature/CustomSecurityGroups branch January 18, 2024 09:04
@juanSTIC juanSTIC restored the feature/CustomSecurityGroups branch January 23, 2024 10:25
PaulaaSTIC pushed a commit that referenced this pull request Feb 26, 2024
# This is the 1st commit message:

Fix salesagility#10364 - Adding now option in Datetime fields

# This is the commit message #2:

Fix salesagility#10364 - Adding now option in Datetime fields

# This is the commit message #3:

Fix salesagility#10364 - Adding now option in Datetime fields

# This is the commit message #4:

Fix salesagility#10364 - Adding now option in Datetime fields

# This is the commit message #5:

Fix salesagility#10364 - Adding now option in Datetime fields

# This is the commit message #6:

Fix salesagility#10364 - Adding now option in Datetime fields

# This is the commit message #7:

Fix salesagility#10364 - Adding now option in Datetime fields

# This is the commit message #8:

Fix salesagility#10364 - Adding now option in Datetime fields

# This is the commit message #9:

Fix salesagility#10364 - Adding now option in Datetime fields
PaulaaSTIC added a commit that referenced this pull request Apr 12, 2024
# This is the 1st commit message:

Sidebar changes

# This is the commit message #2:

Remove setting

# This is the commit message #3:

Fix setting sidebar

# This is the commit message #4:

Fix sidebar dark mode
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Nueva funcionalidad - Grupos de seguridad - Herencia custom por módulo
4 participants