Hola Graciela,
Es verdad… se trata de un bug que aparentemente esta desde 2010, gracias por observarlo.
La lógica de inserción del instalador/actualizador cambia para las siguientes tablas, en donde por cada registro de apex_usuario_grupo_acc, que representa a un perfil funcional, inserta los ítems relacionados en apex_usuario_grupo_acc_item, los miembros (membresía) en apex_usuario_grupo_acc_miembros, si es que existen y en apex_grupo_acc_restriccion_funcional las restricciones asociadas, si es que existen, todo en ese orden.
No hay ningún cambio en la lógica, se intenta insertar los registros preservando la integridad referencial en lo posible, que los triggers no estén desactivados permite ademas que se vayan reportando los errores con la mayor granularidad posible.
Para ello ordena los registros de la tabla apex_usuario_grupo_acc por la columna “usuario_grupo_acc”.Pero de existir miembros, todos ellos son a su vez perfiles funcionales, por lo que lo más lógico sería primero insertar todos los perfiles funcionales, sus ítems si los tiene y sus restricciones si las tiene, y luego, en último lugar, los miembros. Esta es la secuencia de inserción que tienen las tablas según el comportamiento de la aplicación y esa misma secuencia debería respetar el instalador/actualizador. (Es decir, no se puede agregar un miembro a un perfil, si éste todavía no fue dado de alta como perfil). Adoptar un criterio que revierte la integridad referencial, es lo que da orígen a errores.
No estas teniendo en cuenta un pequeño detalle, en la aplicación la secuencia de creación/actualización la generas vos via el criterio humano, no creas los perfiles en el orden incorrecto porque existe una de dos posibilidades:
- El perfil ya existe, en cuyo caso no hay problema asignas la membresia y listo
- El perfil no existe, en cuyo caso cancelas la asignación y vas a darlo de alta, para luego volver y asignarlo.
Es decir, toda la operatoria se realiza desde el punto de vista del perfil miembro… no desde el padre.
Durante la regeneración el procesamiento de los archivos es secuencial, no hay lógica para determinar si el perfil es miembro o no de otro y al ser contenido estático no se puede distinguir que fila se debe “retrasar” en la ejecución.
Ante ese problema (que se puede dar en cualquier tabla relacionada en realidad) la regeneración tiene dos opciones:
- Reportar el error inmediatamente y seguir adelante hasta completarse (dejándote para arreglar el problema). Comportamiento habitual
- Esperar hasta el final de la transacción, abortar y dejarte con la responsabilidad de arreglar el problema y volver a repetir todo el proceso (cuantas veces sea necesario). Situación que se transito en su momento.
Ahora, como la solución del problema (durante una actualización en producción) puede ser tan simple como ir y editar una linea (quitar un item/rf), es que se decidió dejar los perfiles autocontenidos en archivos individuales, de forma de tener que tocar lo menos posible… y saber que todo lo que esta allí esta relacionado (en un volumen de datos manejable), la alternativa planteada implica un archivo con todos los perfiles, otro con todas los items de perfiles, otro con la relación de membresias, etc… con lo cual ante un problema, necesitas tener abiertos múltiples archivos de un tamaño mayor y hacer la conexión lógica entre los datos manualmente.
Nos vemos obligados a establecer y controlar un orden forzado, por fuera, que no sería necesario, dado que esto le agrega a la definición de perfiles desde la aplicación una complejidad extra, porque hay que estar recordando en el momento de efectuar las altas, qué prefijo colocar, dependiendo de qué se trata, dado que desde la aplicación esa columna no se puede consultar ni se muestra en ninguna pantalla.
El orden al que haces mención emana de la forma en que se procesan los archivos xml al momento de regenerar, como se trata de un orden alfabético se les sugirió que incorporen dicho criterio en la creación de los ids. Si es cierto que el cuadro que lista los perfiles podría tener la columna ID como parte del mismo, de manera de poder visualizar de manera mas sencilla lo que se tiene.
Además esto le quita flexibilidad, porque de tener que incorporar otro tipo de combinatoria, posiblemente habría que redefinir el orden. Adjuntamos un ejemplo donde forzamos el orden, pero consideramos que no es la solución, dado que estamos trabajando constantemente con los perfiles, y esto implica tener que llevar un control por fuera de la aplicación.
Aquí el único requerimiento es de orden alfabético… nadie dice que los identificadores no puedan tener X o Y forma, si que la estructura este ordenada.
Si incorporas otra combinatoria con una estructura aparte, no tiene porque influirte en lo que ya tenes y si tiene lazos, necesariamente vas a tener que reordenar porque cambiaste la convención para nombrar las cosas.
Dicho esto, con un par de sentencias SQL por perfil rearmas toda la estructura.
Como le mencionamos a Emiliano Jaureguiber, "no estamos solicitando una mejora, sino la corrección de un error".
Lo que para ustedes es un error… para mi es una decisión de diseño que se tomo en su momento por factores X, me gusta?..no del todo, de haber estado hubiera hecho otra cosa… pero entiendo que dentro de lo que se planteo es una solución de compromiso. Cambiar eso hoy impacta todos los sistemas del SIU y los propios de las instituciones, sin contar instalaciones.
Pasar de editar un perfil autocontenido a editar múltiples archivos y tener que tocarlos todos en el peor de los casos, no es lindo… te tomo que solo seria ante un problema… pero en medio de una actualización es cuando mas se queja la gente y mas urgencia les agarra. No es lo mismo sacarle 4 hojas a una rama … que tener que decidir que 4 hojas hay que sacar de entre todo el árbol.
Obviamente no conocemos el código específicamente, pero esta corrección implicaría algo sencillo. Sería insertar todos los registros en apex_usuario_grupo_acc de una sola vez. No se si queda claro que no se trata de un orden, es lógica. Integridad referencial básica." El nos sugirió ingresar el tema por el foro.
Luego de 10 años de uso nada es sencillo creeme, aun así… para poder llevar adelante eso, hay que modificar la exportación de esos datos en primer lugar para cambiar como se separan en xml y quedaríamos en lo que te planteaba antes. Esto solo saldría en una nueva versión de segundo dígito, con lo cual tampoco te llegaría instantáneamente.
Lo ideal seria tirar todo al diablo… las membresias hoy no son estrictamente necesarias ya (cada usr puede tener múltiples PF asociados) pero incluso se podría separar mejor y la división entre desarrollo/producción (precursora de todos los males), tendría que recibir la muerte que nunca tuvo pero siempre mereció (deshonrosa por supuesto), los perfiles deberían ser de la instalación y no del proyecto.
No es que no se hayan considerado alternativas, solo que muchas serian volver al lugar del cual se pidió salir en su momento.
Otras implican cambios que tienen mas impacto en los usuarios que los males que resuelven.
Y la que le pondría solución final a este y otros problemas… me granjearia el apodo K-19.
Saludos
Richard