Operacion Toba Usuarios exportada - no copia todos los php

Buen dia

Trabajando con SIU-Toba Versión 3.2.18, al crear una operacion con el “wizard” por medio de la opcion “Importar operación” a partir del Proyecto: toba usuarios, Item: Mantenimiento de usuarios, todo funciona bien, excepto que no se copia el archivo: “gestion_arai_usuarios.php” que tuve que copiar manualmente al ver el error.

También sería interesante que en los llamados en “consultas_instancia.php” a través de "toba::db(‘’)->consultar($sql)" se conviertan en Ej: toba::db(‘usuarios’)->consultar($sql), o sea que tengan una base de datos que no sea la prederminada sino una nombrada, con cualquier nombre, en todo caso se crea la fuente de datos con el nombre que tenga la clase, pero que no lo busque en la fuente de datos predeterminada del proyecto.

Es un lujo, y no es mucho trabajo cambiar la clase, pero si se puede hacer sería más práctico clonar la operación de usuarios en los proyectos.
Y ya que estoy pidiendo , en la lista de proyectos de la clase, si no es “toba_usuarios” el proyecto actual, que muestre solo usuarios de dicho proyecto.

Algo asi:

	static function get_lista_proyectos()
	{
              /// inicio modificacion 
               $proyecto = toba_proyecto::get_id();
		if ( $proyecto !== 'toba_usuarios')
			return array(array('proyecto'=>$proyecto));
           /// fin modificacion

		$sql = "SELECT proyecto FROM apex_proyecto WHERE proyecto <> 'toba' ORDER BY proyecto;";
		return toba::db('usuarios')->consultar($sql);
		
	}

“No se si he sido claro” dijo el “Negro Fontanarrosa”, cualquier cosa me preguntan …

Saludos

Buen dia Oscar,

esto es porque lo que se importa es todo lo que esta referenciado por metadatos, no se hace un analisis del codigo para rastrear todo archivo que este involucrado… eso implicaria no solo identificar correctamente las clases que se invocan en codigo, sino tambien replicarlas de manera inteligente para no repetir codigo que es general a ambos proyectos, el nivel de esfuerzo requerido para lograr eso… sobrepasa ampliamente el beneficio.

También sería interesante que en[b] los llamados en "consultas_instancia.php" a través de "toba::db('')[/b]->consultar($sql)" se conviertan en[b] Ej: toba::db('usuarios')->consultar($sql)[/b], o sea [b]que tengan una base de datos[/b] que no sea la prederminada sino una [b]nombrada[/b], con cualquier nombre, en todo caso se crea la fuente de datos con el nombre que tenga la clase, pero que no lo busque en la fuente de datos predeterminada del proyecto.

Esto puede hacerse sin mucho drama, tengo que ver bien como esta registrandose actualmente en bases.ini para no pifiarle al identificador nomas.

Es un lujo, y no es mucho trabajo cambiar la clase, pero si se puede hacer sería más práctico clonar la operación de usuarios en los proyectos.
Es practico y no, porque dicha operacion muchas veces tiene actualizaciones que una vez clonada nunca se trasladan... atento a esto.
Y ya que estoy pidiendo , en la lista de proyectos de la clase, si no es "toba_usuarios" el proyecto actual, que muestre solo usuarios de dicho proyecto. Algo asi:
	static function get_lista_proyectos()
	{
              /// inicio modificacion 
               $proyecto = toba_proyecto::get_id();
		if ( $proyecto !== 'toba_usuarios')
			return array(array('proyecto'=>$proyecto));
           /// fin modificacion

		$sql = "SELECT proyecto FROM apex_proyecto WHERE proyecto <> 'toba' ORDER BY proyecto;";
		return toba::db('usuarios')->consultar($sql);
		
	}

“No se si he sido claro” dijo el “Negro Fontanarrosa”, cualquier cosa me preguntan …

Aca si ya me perdi, esto seria en los filtros de toba_usuarios?

Saludos

esto es porque lo que se importa es todo lo que esta referenciado por metadatos, no se hace un analisis del codigo para rastrear todo archivo que este involucrado... eso implicaria no solo identificar correctamente las clases que se invocan en codigo, sino tambien replicarlas de manera inteligente para no repetir codigo que es general a ambos proyectos, el nivel de esfuerzo requerido para lograr eso.. sobrepasa ampliamente el beneficio.

No se puede vincular a los metadatos la clase en cuestión ? (gestion_arai_usuarios.php)
Si es más costo que beneficio, habría que dejar documentado el caso y si es posible avisar al momento de la importación si es factible.

Aca si ya me perdi, esto seria en los filtros de toba_usuarios?

Es en la clase de consultas “consultas_instancia.php” y afecta a la lista de los proyectos en toda la operación, lo que pretendo con esto es que solo se puedan ver o editar usuarios del proyecto actual, quizás falte hacer alguna otra cosa …

Hola Oscar,

el tema es si agrega algo, para el caso en cuestion esa clase es el equivalente de una clase de negocio en Pilaga, G3, etc… tener que declarar todas las clases de negocio que puede llegar a alcanzar una operacion es un laburo grande para el que desarrolla, que ademas debe ser mantenido en el tiempo ya que sino deja de servir.

Todo eso suponiendo ademas que existiera forma, la cual actualmente no esta… seria equivalente a seguir incluyendo los require_once de todas las clases usadas (incluso de manera transitiva) en el inicio del CI / CN.
Lo que se transformo en el pasado en innumerables errores por eliminaciones que afectaban alguna extension, justamente se creo el mecanismo de autoload para dejar eso de lado.

Hemos tenido charlas en el pasado sobre un esquema similar intra proyectos y siempre llegamos a lo mismo, suena lindo pero es inmantenible en el tiempo y entonces pierde sentido tenerlo… es como un modelo de BD que no tiene relacion con la estructura real porque es mas sencillo tirar el ALTER TABLE que pegar toda la vuelta, o simplemente porque alguien lo olvido.

Respecto del mensaje, podria agregar algo que indicara que se debe revisar la necesidad de copiar archivos extra… pero aun deberias ir a mirar al codigo cuales son.

Es en la clase de consultas "consultas_instancia.php" y afecta a la lista de los proyectos en toda la operación, lo que pretendo con esto es que solo se puedan ver o editar usuarios del proyecto actual, quizás falte hacer alguna otra cosa ...

Los usuarios/cuentas son de la instancia… el proyecto solo les asigna permisos de acceso, fijate que tenes el filtro de pertenencia para obtener solo aquellos asociados a cierto proyecto.

Saludos

Repasando el tema para tratar de explicarlo mejor.

Cada vez que quiero personalizar el manejo de los usuarios de un proyecto, clono la operación “Usuarios” desde toba_usuarios.

Después de clonar, tengo que tocar el código para que me muestre sólo los usuarios que pertenecen al proyecto y solo dicho proyecto:

1 - Modificar las consultas y que en toba_usuarios hacen referencia a la bbdd predeterminada con “toba::db(‘’)->consultar($sql)” y eso no es correcto, entonces le pongo la fuente que creé para conectame a toba_usuarios, supongamos “toba::db(‘usuarios’)->consultar($sql)”

2-En consultas_instancia.php agrego dos líneas de código para que no vea otros proyectos más que el suyo:

class consultas_instancia
{
	static function get_lista_proyectos()
	{
		$proyecto = toba_proyecto::get_id();
// inicion personalizacion 
		if ( $proyecto !== 'toba_usuarios')
			return array(array('proyecto'=>$proyecto));
/// fin personalizacion 
		$sql = "SELECT proyecto FROM apex_proyecto WHERE proyecto <> 'toba' ORDER BY proyecto;";
		return toba::db('usuarios')->consultar($sql);
		
	}

3 - en ci_navegacion.php también con un par de líneas no permito que cambien la opcion de “pertenencia” del filtro de proyecto, entonces junto con lo anterior queda obligador a ver/modifcar los usuarios que “pertenecen” su “proyecto”

	function conf__filtro($componente)
	{
		if (isset($this->s__filtro)) {
			$componente->set_datos($this->s__filtro);
		} 

	/// inicio modificacion
		$proyecto = toba_proyecto::get_id();
		if ( $proyecto !== 'toba_usuarios')
			$this->dep('filtro')->ef('pertenencia')->set_solo_lectura(true);
    /// fin modificacion
	}
	

Creo que si esas líneas estuvieran en el código nos facilitarían las personalizaciones de la operación y no afectarían al proyecto toba_usuarios.
Fijate si es correcto lo que digo y se lo pueden poner en el código base de toba…
Con respecto a la actualización de la operación, sería bueno que esté destacada del resto de las actualizaciones, en un apartado o algo así, y si no habrá que revisar cada vez que se actualiza el entorno siu-toba…
Creo que eso es lo más importante, quedo a la espera …
Saludos y gracias!!!

Hola Oscar,

Estoy trabajando esto para que queden las consultas con un id de fuente fijo.

2-[b]En consultas_instancia.php agrego dos líneas[/b] de código para que no vea otros proyectos más que el suyo: 3 - [b]en ci_navegacion.php[/b] también con un par de líneas no permito que cambien la opcion de "pertenencia" del filtro de proyecto, entonces junto con lo anterior queda obligador a ver/modifcar los usuarios que "pertenecen" su "proyecto"

Me parece que te complicaste mucho, poner el campo en solo_lectura no esta mal para dar un feedback visual… pero no es necesario que modifiques las SQL.
Con modificar el siguiente metodo obtenes el mismo resultado:


function evt__filtro__filtrar($datos)
{
        $datos['proyecto] = ID_PROYECTO;
        $datos['pertenencia'] = 'P';        //Quizas esto seria mejor pasarlo a una constante
	$this->s__filtro = $datos;
}

Creo que si esas líneas estuvieran en el código nos facilitarían las personalizaciones de la operación y no afectarían al proyecto toba_usuarios. Fijate si es correcto lo que digo y se lo pueden poner en el código base de toba... Con respecto a la actualización de la operación, sería bueno que esté destacada del resto de las actualizaciones, en un apartado o algo así, y si no habrá que revisar cada vez que se actualiza el entorno siu-toba...

Como bien decis es parte de una personalizacion, incluir casos particulares dentro de un metodo que va a “cobrar vida” cuando se corra en otro proyecto no me cierra por ningun lado… cuestiones particulares de ese estilo se incluyeron para cuando corre toba_editor… y son una peste.

Como personalizacion, estan perfectas… son condiciones particulares que necesitas vos por el motivo que sea, sabes que estan y el por que de su existencia… no le puedo trasladar eso a otro proyecto que la importo hace tiempo para no tener que cambiar la URL nomas.

Respecto de la actualizacion… calculo que puedo meter una especie de seccion en el changelog para que se resalte que es necesaria una actualizacion, lo tomo.

Saludos

Estoy trabajando esto para que queden las consultas con un id de fuente fijo.
Buenísimo.
Con modificar el siguiente metodo obtenes el mismo resultado:

Código: [Seleccionar]
function evt__filtro__filtrar($datos)
{
$datos['proyecto] = ID_PROYECTO;
$datos[‘pertenencia’] = ‘P’; //Quizas esto seria mejor pasarlo a una constante
$this->s__filtro = $datos;
}

Si, es cierto, pero lo puse en la consulta para que tenga efecto en todo el proyecto y no solo en el formularios que estaba viendo yo, por las dudas tenga otros accesos a los proyectos.

Bueno Ricardo, gracias por el aguante !!
Sigo revisando el hilo cada tanto para ver si hay novedades.
Abrazo!!!