Mostrar Mensajes

Esta sección te permite ver todos los mensajes hechos por este usuario, recuerda que solo puedes ver los mensajes en áreas en donde tu tienes acceso.


Mensajes - richard

Páginas: [1] 2 3 ... 173
1
Toba - Desarrollo / Re: template responsive en toba
« : Hoy a las 10:34:18 am »
Hola Leo,
ahora como lo implemento en mis proyectos? lo que hice fue copiar el contexto_ejecucion.php del toba referencia  en mi proyecto. Luego desde el toba editor Conf/Extensión del núcleo/Contexto de Ejecución/ Archivo subclase coloque el contexto ejecución.

pero me sigue arrojando el error
Código: [Seleccionar]
Class 'referencia_factory' not found
La clase a la que hace referencia es propia del proyecto toba_referencia... es parte de un ejemplo de como crear un manejador de salida propio, respetando las interfaces necesarias.
De paso tambien se observa como usar otro manejador como fallback para lo que el nuestro propio no implementa.
Si dejas las lineas pertenecientes al manejador_boostrap unicamente deberia salir con fritas.

Saludos

2
Toba - Desarrollo / Re:Extender usuario
« : junio 24, 2019, 10:46:23 am »
Hola Tomas,
En donde le digo al proyecto que la clase de usuario es esta nueva que yo defini???

eso lo indicas en la configuracion general del proyecto (via toba_editor) en la pestaña de extension del nucleo.

Saludos

3
Toba - Desarrollo / Re:Perfil funcional para API REST
« : junio 24, 2019, 10:33:35 am »
Hola Ramiro,
Hola gente, hoy escribo para consultar: ¿Existe alguna forma de determinar qué servicios web puede consumir cierto usuario?
En ppio no, porque no hay una asociacion entre usuarios y servicios web.
Si tuvieras esa asociacion en algun lugar, podrias llegar a armar algo generando una subclase del proveedor_autorizacion (tal como encontraste en el post de Maxi).

Citar
Amplio: Resulta que utilizando el servidor_usuarios.ini podemos determinar los usuarios que pueden acceder a los recursos REST. El tema está en cómo restringir ciertos usuarios (el caso más práctico para ejemplificar sería: evitar que pueda hacer cualquier tipo de POST). ¿Me explico?

Si lo que necesitas es restringir que haga una operacion puntual, necesitas mas que un perfil funcional... porque el usuario tiene acceso al recurso,  el tema es que no puede acceder a todas las operaciones del recurso... no necesitas solo asociar ruta/usuario.. sino que ademas debes tener las operaciones que puede solicitar.

Si hay subrecursos la cosa se complica un poco mas, tenes que extraer los parametros de lo que te llega sin romper la ruta en cuestion.. porque vas a hacer la busqueda con ella.
Es mas a nivel de operacion casi el chequeo, donde hay que verificar si el usuario tiene derecho de uso o no.

Saludos

4
Hola Marcelo,

joya.. cualquier cosa, ya sabes.

Saludos

5
Hola Jorge,
Si, en produccion y en todas las operaciones.

te hago un pedido, te fijarias en los permisos de los directorios 'metadatos_compilados' respecto de apache o el grupo que usa apache?.
Por lo que vi en los logs puede venir por ahi quizas.

De paso te consulto, que version de PHP tenes?.

Saludos

6
Toba - Desarrollo / Re: template responsive en toba
« : junio 19, 2019, 09:43:56 am »
Hola Leo
pero al tratar de ingresar al proyeccto me arroja el siguiente
Código: [Seleccionar]
Class 'SIU\ManejadorSalidaBootstrap\bootstrap_factory' not found
nose si estoy haciendo bien. o estoy totalmente errado je

no estas mal, probablemente lo que te falte es agregar el paquete siu/manejador-salida-bootstrap al composer.json

Saludos

7
Toba - Desarrollo / Re:Agregar libreria a composer
« : junio 19, 2019, 09:40:42 am »
Hola Leo,
1) Quiero agregar una libreria de 3ro. agregue al packages en composer.lock este package.json. pero al actualizar composer me arroja el siguiente error.


Si agregas paquetes tenes que colocarlos en composer.json, el archivo lock solo indica las versiones que deben/estan instaladas.
Por otro lado, estimo que estas queriendo agregar un paquete JS... en cuyo caso te conviene instalarlo via Yarn en la seccion post-install / post-update.

Tene en cuenta que segun la version de Yarn que tengas, puede que te encuentres con un bug en el cual al especificar la carpeta destino no te baja todos los paquetes, fijate que Toba primero agrega los paquetes que necesita y luego invoca nuevamente a Yarn para que instale todo de una.

Saludos

8
Hola Marcelo,

arranco por el final:
Citar
Ayer probé de hardcodearle el path a la linea y actualizó la aplicación, pero no se si es lo que se debe hacer. :):):)

el tema es el siguiente, tenes que hacer la transicion desde el formato viejo sin composer al nuevo.. una vez hecha esa transicion, el instalador como viene te va a funcionar sin problemas.. pero para dar ese salto algo vas a tener que tocar.

         Te cuento que efectivamente usábamos el instalador web (empaquetado).

y si tenemos las aplicaciones instaladas con la estructura que escrbiste:
       - Aplicacion
       - Instalacion
       - Toba
Bien, la cosa es un poco mas simple entonces.. una opcion podria ser convertir esa estructura (luego de un backup) de la siguiente forma:

 - Aplicacion
     - Aplicacion/instalacion
     - Aplicacion/vendor/siu-toba/framework (aca copiar el contenido de la carpeta Toba)

Que es mas o menos lo que el instalador esta esperando.
Tambien existe un archivo .sh (el cual carga el entorno) que deberia ser copiado a la raiz del proyecto con el nombre 'entorno_toba.env' y sus valores ajustados para representar la nueva estructura.

Con eso, el instalador deberia ir sin problemas sin tener que tocar el codigo.
De todas maneras, como te decia antes... la cuestion es dar el salto, si ya lo hiciste .. funciono bien y te dejo todo en orden (con la estructura como te digo arriba, usuarios, etc), segui a partir de ahi...  no le des mas vueltas.

Si haria una prueba extra con el otro mecanismo (offline) por si hay que hacer futuras migraciones asi de otros proyectos, al menos sabes que tenes un procedimiento que funciona.

Saludos

9
Hola Marcelo,

            Ahora bien. Estoy teniendo un problema al querer actualizar una aplicación desarrollada con toba 2.5. En desarrollo lo había migrado ya a la versión 3.2
bien, en produccion no deberia ser tan distinto... salvo que el metodo de deployment varie mucho entre desarrollo y produccion.
Contame un poco mas como es que tenias estructurado el proyecto en la version 2.5 en prod.

Citar
            Corrí el comando ./bin/instalador proyecto_actualizar -d /usr/local/unpsjb/sea

           El instalador hace todos los chequeos, pero llega hasta un error que dice:
           [ ERROR ] El parámetro de entorno TOBA_DIR de la instalación anterior no corresponde con la ruta ''
Si, el instalador esta asumiendo ciertas locaciones debido al uso de composer... si venis de un deployment manual o de un paquete que no usaba composer hay que meter un poco de garfio para que vaya bien.

Citar
        Si no entendí mal la estructura del proyecto en producción no tiene ese directorio $dir_toba = realpath($dir_instalacion."/../vendor/siu-toba/framework");
        Estará faltando algo que debo setear?
Este es el tema, cuando usas composer naturalmente el framework queda ahi adentro.. pero en 2.5 la estructura de directorios primeramente estaba invertida (con  Toba por fuera) y si es un deployment  manual, mas complicado aun. Por eso te pedi que me cuentes mas de como esta, asi te puedo guiar mejor con los pasos a llevar adelante.

Si usaban el instalador web, te deberia haber quedado una estructura con 3 carpetas:

- Aplicacion
- Instalacion
- Toba

Si era manual, deberias tener la de Toba con todo adentro.

Saludos

10
Hola Pablo,

esta mal la URL que lleva a github, desgraciadamente ya no tengo posibilidad de editar dicho contenido el cual esta en modo read-only hace ya mas de un año.

De todas maneras, si vas a la pagina de Toba en Github podes bajar el release que quieras.

Saludos

11
Toba - Instalación / Re:Instalacion toba 3.2 - problemas con arai
« : junio 06, 2019, 10:32:26 am »
Hola Pablo,

el problema es la version de PHP en ppio y como consecuencia de ello la version de Halite.

Si te fijas en el composer.json de arai-cli, vas a ver que para dev esta requiriendo la version 1.6.0 de Halite... esa es la version que deberias estar poniendo en tu .json .

El problema con esa version es que requiere de una version especifica de sodium, que se puede instalar hasta PHP 7.1... mi  consejo seria :

 -  downgrade a PHP 7.1.30
 -  reinstall de sodium
 - agregar halite 1.6.0 a composer.json y  composer update

Con eso deberias tener solucionado el tema de halite para generar la key, igual creo que en esa version de cli podes elegir el backend por defecto que usa, seleccionate SODIUM.

Saludos

12
Toba - Desarrollo / Re:PHPunit - Test de unidad.
« : junio 05, 2019, 11:52:42 am »
Hola Ramiro,

si te fijas en esta misma seccion se fueron abriendo hilos sobre testing en Toba.
Por ejemplo: Testing con Selenium
o Testear proyectos toba

Si queres podemos ver alguna particularidad que tenga el proyecto, de todas maneras la idea original se sigue manteniendo.
Por otra parte, por que no usar Toba 3.2 directamente?, que los retiene en la rama 3.1?

Saludos

13
Hola Marcelo,
             Lo que no encuentro es como sería el proceso para pasar a producción en otro equipo de la red.
             Se copia el proyecto al servidor de producción y luego se corre ./bin/instalador proyecto:instalar (o actualizar según corresponda)?
exacto, bajas el proyecto donde debas.. configuras las variables en el archivo de entorno y despues corres alguno de los comandos que mencionas (segun debas).

Saludos

14
Hola Graciela,
1. Delete/borrado del contenido de todas las tablas en donde el usuario define la estructura de accesos de los usuarios, en el orden de la integridad referencial .
 Se copia a continuación parte del log del motor postgres. Se detecta un primer error: ejecuta cada sentencia DELETE dos veces para algunas tablas, innecesariamente.
Es verdad.. se trata de un bug que aparentemente esta desde 2010, gracias por observarlo.

Citar
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.

Citar
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.

Citar
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.

Citar
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.

Citar
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.

Citar
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


15
Toba - Desarrollo / Re:Migrar proyecto verison 2.7.13 a 3.2.2
« : mayo 31, 2019, 11:17:45 am »
Hola Nicolas,
Cuales serían los pasos correctos para personalizar el manejador_salida_boostrap?
en el caso del manejador de salida, no existe el concepto de "personalizacion"... lo que si podes hacer es crear tu propio manejador (parcial si queres) y usar el esquema de carga para que use el manejador bootstrap de fallback.

En toba_referencia hay un ejemplo de justamente eso... se crea un manejador parcial que cambia algunas cosas de la salida y utiliza como fallback el manejador que haya sido cargado previamente.

Hay algunas clases en ese esquema que son obligatorias (*_config ,* _factory, etc).. pero las que pertenecen a los componentes son individuales, podes hacer la clase para el cuadro pero no el resto de los componentes, lo unico a tener en cuenta es que la clase tiene que implementar la interface para la misma , la idea es que no heredes de otro manejador para no crear acoplamientos innecesarios.

Citar
Es decir, tras descomentar las lineas referidas a la instanciación extendida de boostrap en el contexto_ejecucion que debo hacer para modificar un componente y como debo regenerar el autoload del proyecto para que tome ese cambio?

Eso depende como lo quieras llevar adelante, si mantenes el manejador como un paquete aparte que se instala por composer... vas a tener que hacer algo similar a lo que se hace hoy con el manejador_bootstrap.

Si lo mantenes dentro del codigo del proyecto, lo vas desarrollando y vas cargando las clases via autoload. Para actualizarlo solo tenes que usar el comando toba proyecto autoload -p nombreProyecto y con eso te lo actualiza.

Citar
Por ultimo, que pasa cuando le manejador base se actualice? que debo hacer para incorporar esos cambios a mi extension?
La idea es que cada manejador sea independiente, asi que mientras no tengas cambios en la interface (que los puede y va a haber) no tendrias mucho drama, si te puede pasar que usando otro manejador como fallback al modificarse el html que emite tengas que ajustar el tuyo... pero es lo mismo que te pasaria si cambio el marcado de toba_ei_cuadro_salida_html y tenes una extension de algun metodo puntual.

Una opcion para no depender de eso, es que implementes todo el manejador en su completitud... entonces el marcado que sale es siempre el que vos hiciste, salvo que como te decia en algun momento cambie la interface y tengas que hacer ajustes al encabezado o uso de algun metodo.

Saludos

Páginas: [1] 2 3 ... 173