Hotfix - General - Añadir relación entre actividades y personas desde subpanel

[PaulaaSTIC]

Descripción

Los cambios realizados en el PR https://github.com/SinergiaTIC/SinergiaCRM-SuiteCRM/pull/849 provocan el issue #444.

Problemas identificados:

Los cambios realizados en el PR provocaban que, al crear relaciones desde los subpaneles, la información de la relación no se actualizara correctamente.

1. Error en el campo flex-relate del subpanel de actividades:
   • Ocurría al modificar una relación desde el subpanel de actividades vinculado a un registro de persona.
   • Por las condiciones actuales en el código, se asignaba $new_rel_id='', lo que impedía la creación de la relación entre la reunión y la persona.

Solución propuesta

Se modificó la función

SinergiaCRM/data/SugarBean.php

Lines 2866 to 2878 in 41e7eb1

	if (!empty($new_rel_id)
	&& ( // Relationships with an ID in the _ida field of the relationship different from the parent record
	(!empty($this->{$new_rel_link}) && is_string($this->{$new_rel_link}) && $new_rel_id != $this->{$new_rel_link})
	// Special relationships like member_accounts where the parent_id is not equal to the ID of the parent record
	|| (empty($this->{$new_rel_link}) && !empty($this->parent_id) && $new_rel_id !=$this->parent_id)
	)
	) {
	$new_rel_id = ''; // Assign the empty value to this variable, in the same way as when creating the record from the edit view
	}
	// END STIC_Custom
	return array($new_rel_id, $new_rel_link);
	}

para ajustar las condiciones. En particular:

• Se asegura que $new_rel_id se asigna únicamente cuando las condiciones lo requieren:

  if (!is_null($this->{$new_rel_link})) {
      // Asignar new_rel_id según condiciones necesarias
  }

Esta modificación evita asignaciones incorrectas de $new_rel_id y garantiza que las relaciones se creen o actualicen correctamente.

Pruebas

Escenarios cubiertos:

Subpanel de actividades

1. Ir al módulo de personas.
2. Abrir el subpanel de Actividades de cualquier persona.
3. Crear una nueva reunión.
4. En el campo "Relacionado con", seleccionar un registro de otro módulo.
5. Guardar la reunión.
6. Verificar que la reunión queda asociada a la persona en la que se ha creado.

Personas 1-N Relación persona

1. Crear dos personas.
2. Ir a una de ellas y crear una relación con persona desde el subpanel.
3. Desde el subpanel, editar la relación con persona y cambiar varios campos, incluida la persona.
4. Comprobar que se han cambiado la relación.
   Probar en la creación desde el subpanel:
5. Desde una persona ir al subpanel relacion persona y crear una nueva, seleccionar una persona distinta a la origen.
6. Comprobar que la relación se ha creado pero no aparece en el subpanel.

Organizaciones 1-N Organizaciones miembro

Probar en la edición desde el subpanel:

1. Ir a una organización ir al subpanel De "Organizaciones miembro" Seleccionar una organización, editar el registro y seleccionar otra.
2. Comprobar que se han cambiado la relación.
   Probar en la creación desde el subpanel:
3. Selecccionar crear una nueva, en la creación seleccionar una organización distinta a la origen.
4. Comprobar que la relación se ha creado pero no aparece en el subpanel.

Probar que se mantienen las comprobaciones realizadas en el PR original (PR #849).

Información adicional

Los comportamientos descritos en los escenarios "Personas 1-N Relaciones persona" y "Organizaciones 1-N Organizaciones miembro" también se reproducen en SA.

En la resolución de este PR, se ha identificado un caso de error relacionado con las relaciones personalizadas 1-N de un módulo consigo mismo.

Esta información se ha documentado en otro issue y queda pendiente de análisis: SinergiaCRM Issue #506.

[github-actions]

Actions executed at: 2024-12-19 08:16:59.

[enricsinergia]

(A)probado

[ManuSinergiaCRM]

La línea de código que se está comentando solucionaba la incidencia para relaciones especiales como member_accounts donde parent_id no es igual al ID del registro principal y ahora vuelve a ocurrir el error.

Se propone investigar y averiguar si se puede añadir alguna condición más que permita solucionar ambas incidencias.

Si no es sencillo, y por lo que recuerdo no lo será ya que la función set_relationship_info() tenía complejidad, una opción alternativa y sencilla podría ser quitar la opción de Editar en los subpaneles de aquellas relaciones especiales como member_accounts

Paula, si lo consideras, podemos comentarlo :)

Como reproducir la incidencia

1. Crear dos organizaciones.
2. Ir a una de ellas y seleccionar a la otra en el subpanel de Organizaciones miembro
3. Desde el mismo subpanel, editar el registro y cambiar varios campos, incluido el campo Miembro de
4. Comprobar que en la organización se han actualizado los campos modificados excepto el de Miembro de

[PaulaaSTIC]

La línea de código que se está comentando solucionaba la incidencia para relaciones especiales como member_accounts donde parent_id no es igual al ID del registro principal y ahora vuelve a ocurrir el error.

Se propone investigar y averiguar si se puede añadir alguna condición más que permita solucionar ambas incidencias.

Si no es sencillo, y por lo que recuerdo no lo será ya que la función set_relationship_info() tenía complejidad, una opción alternativa y sencilla podría ser quitar la opción de Editar en los subpaneles de aquellas relaciones especiales como member_accounts

Paula, si lo consideras, podemos comentarlo :)

Como reproducir la incidencia

1. Crear dos organizaciones.
2. Ir a una de ellas y seleccionar a la otra en el subpanel de Organizaciones miembro
3. Desde el mismo subpanel, editar el registro y cambiar varios campos, incluido el campo Miembro de
4. Comprobar que en la organización se han actualizado los campos modificados excepto el de Miembro de

El error mencionado ocurría cuando el subpanel, y por lo tanto la nueva relación, correspondía a un registro del mismo módulo que el módulo padre. Se ha añadido una comprobación específica para este tipo de casos.

[ManuSinergiaCRM]

(A)probado

Se observa que la condición aportada en este PR amplia la cobertura de la condición que sustituye para gestionar correctamente registros que tienen una relación con el registro que contiene al subpanel (registro padre) además de un campo posiblemente relacionado (por ej: registros de llamadas, reuniones o notas), de forma que el registro indicado en el campo posiblemente relacionado no pierda la información por indicar un ID diferente al ID del registro padre.

La solución ha funcionado correctamente para los casos de uso probados, incluyendo registros con una relacion 1-N personalizada que relaciona a un módulo consigo mismo.

[enricsinergia]

(A)probado

Probado con reuniones y llamadas.
Creación desde subpanel, desde edición, cambiar persona apuntada, cambiar la organización....
También se ha probado con Subvenciones para las relaciones N:M que se pauntaban en el PR anterior.

[ManuSinergiaCRM]

Encontrado un caso de uso erróneo ya que $this->{$new_rel_link} llega a NULL

Como reproducirlo

1. Desde la vista de detalle de una organización (O1), crear una organización nueva desde el subpanel de Organizaciones Miembro e indicar en el campo Miembro de una organización distinta a O1
2. Comprobar que la nueva organización es miembro de O1 aunque se indicó otra.

Al editar esa misma organización desde el subpanel de Organizaciones miembro de O1 y cambiar el valor del campo Miembro de $this->{$new_rel_link} es igual a '' (cadena vacía) y al no ser NULL sí funciona correctamente

[PaulaaSTIC]

Encontrado un caso de uso erróneo ya que $this->{$new_rel_link} llega a NULL

Como reproducirlo

1. Desde la vista de detalle de una organización (O1), crear una organización nueva desde el subpanel de Organizaciones Miembro e indicar en el campo Miembro de una organización distinta a O1
2. Comprobar que la nueva organización es miembro de O1 aunque se indicó otra.

Al editar esa misma organización desde el subpanel de Organizaciones miembro de O1 y cambiar el valor del campo Miembro de $this->{$new_rel_link} es igual a '' (cadena vacía) y al no ser NULL sí funciona correctamente

Se ha modificado la consulta para añadir este tipo de excepciones.

[ManuSinergiaCRM]

(A)probado

Probado con los diferentes casos de uso descritos en el PR y en el PR que complementa

[enricsinergia]

(A)provado