search

SinergiaTIC / SinergiaCRM

SinergiaCRM is an open source CRM for non-profits based on SuiteCRM
https://www.sinergiacrm.org
GNU Affero General Public License v3.0
20 stars 2 forks source link

Incidencia - Grupos de Seguridad - No se permite editar un registro a pesar de que el rol indica que sí #55

Open enricsinergia opened 8 months ago

enricsinergia commented 8 months ago

Descripción del problema A raíz del issue #51 se ha detectado que, en algunos casos, a pesar de que el rol indica que un usuario puede modificar registros de su propio grupo de seguridad, el sistema no le deja.

Cómo reproducir el problema

  1. Configuramos el permiso "strict rights" en la configuración de grupos de seguridad
  2. Creamos 2 usuarios no admin (u1 y u2)
  3. Creamos un ROL que indique en todos los apartados posibles "Grupo" (R!)
  4. Creamos un Grupo de Seguridad (SG1)
  5. Con el usuario u1 creamos una Persona P1 que herede el SG1.
  6. Accedemos con el usuario u2 y comprobamos que P1 nos aparece en la lista pero no podemos editarlo ni ver el detalle

Comportamiento esperado No habiendo un rol ligado al grupo que diga lo contrario, debería cumplirse lo que dice el rol y permitirse la edición y visualización de los registros ligados al grupo de seguridad del usuario

enricsinergia commented 7 months ago

En modules/SecurityGroups/SecurityGroup:php, función groupHasAccess (138) se crea una sql para comprobar si el usuario puede editar o visualizar un registro. Al construir esta sql, si $sugar_config['securitysuite_strict_rights'] está a true, se añade una parte que obliga a que el rol añadido a través del grupo de seguridad tenga permiso para realizar la acción (visualizar detalle o editar). El problema se produce cuando no hay rol asignado a través del grupo, si no que se confía en el rol genérico asignado al usuario. No se encuentra ningún grupo que venga a través del grupo y por tanto se determina que no puede realizar la acción.

Hay que decidir si: 1) Se cambia este comportamiento descrito para que en caso que no haya rol procedente del grupo (o éste no establezca nada para el módulo y acción), se compruebe el permiso que determinan los roles del usuario. 2) Si no se quiere tocar este punto, habría que tocar el punto dónde se comprueba el permiso para listar, ya que ahí parece que sí se está aplicando el rol genérico (es decir, el comportamiento atual es incoherente) 3) No se toca nada y se abre issue/foro a SA

enricsinergia commented 7 months ago

https://community.suitecrm.com/t/strict-rights-check-makes-generic-roles-useless-and-generates-inconsistencies/91620

enricsinergia commented 7 months ago

Pasados unos cuantos días sin mensaje de SA, o avanzamos con una propuesta de resolución (yo cogería el punto 1 que me parece la más coherente) o bien abrimos issue a SA en lugar de quedarnos en el foro... aunque no sé si ahí responden mejor.

AlbertoSTIC commented 2 months ago

Creo que apostaría también por la opción 1.

@juanSTIC ¿Qué opinas sobre este Issue?