Sí, tenemos una personalización que básicamente implica la gestión de una entidad nueva cuya relación con el Guaraní es la tabla sga_propuestas. Tenemos la duda de si vamos a poder crear o no los gatillos para esta nueva entidad si las tablas están en un esquema nuevo. Saludos!

Gracias por las prontas respuestas chicos. Cual creen de las dos alternativas es la mejor?
Yo me inclino más por crear un esquema nuevo 'negocio_pers' y ocupar allí las tablas nuevas. Ahora, que pasa si en el mismo esquema tengo tablas extendidas y tablas nuevas independientes? Quedaría algo como:

negocio_pers
---- sga_comisiones_unq
---- unq_sga_tabla_independiente

O, tal vez, así:

negocio_pers
---- sga_comisiones_unq
---- sga_tabla_independiente_unq

Qué dicen, cuál les parece más limpia?

Saludos

Buenas. Siguiendo con el mismo tema. Estábamos pensando que nombres ponerles a las nuevas tablas que tengamos que crear. En principio la idea sería ponerlas en un esquema nuevo llamado guarani_pers. Después en cuanto a los prefijos queríamos usar los mismos que el Guaraní (sga, mdp, etc), pero nos surgía la duda del significado de cada uno. Lo busqué en la documentación pero no tuve demasiada suerte. Lo tienen documentado en algún lado que puedan compartir? Gracias!

Buenas! Acudo nuevamente al querido foro ya que tengo una pequeña duda sobre personalizaciones.
Queremos, antes de empezar con las nuevas personalizaciones, crear algo así como un documento de convenciones a la hora de nombrar los nuevos ítems, ci, cn, clases y demás componentes que aparezcan. Lo más parecido que encontré hasta ahora es este artículo http://portalguarani.siu.edu.ar/trac/Portal-G3/wiki/NotasTecnicas/ejemplopersonalbasic

Si bien entiendo parcialmente los estándares que propone, no me queda claro si este sistema de sufijos se aplica solo a ítems clonados y clases heredadas o si se aplica también a personalizaciones nuevas que no tienen nada que ver con componentes de Guaraní ya existentes.

Para resumir, la convención sería:
Nombre operaciones: Nueva operación - UNQ
Nombre CI,CN: Nuevo controlador de interfaz - UNQ
Clase CI,CN: ci_nuevo_controlador_interfaz_unq.php
Nombre del resto de los componentes: pantalla, cuadro, filtro, form
Clases de extensión del resto de los componentes: pantalla_nueva_unq.php, cuadro_nuevo_unq.php, form_nuevo_unq.php

Cualquier adición o corrección a estos estándares será bienvenida, gracias!

Bueno, lo probé borrando la base de datos y funciona. Gracias

Hola, disculpen la demora. La exportación a preinscripción la realicé después del rechazo. Por lo tanto, según lo que me están contando, debería sincronizarse ese rechazo y la propuesta debería volver a estar disponible para el aspirante. En cuanto al caché del APC, me tirá un error. Pero de todas formas reinicie el servicio y el problema sigue ahí. Avísenme de cualquier información adicional que les pueda llegar a pasar. Saludos!

Hola, tenía una duda con respecto al sistema de pre-inscripción. Supongamos que un aspirante se inscribe en una carrera. Y del lado de gestión se lo termina rechazando. Al tiempo, si el aspirante intenta reinscribirse, en el Sistema de inscripción sigue figurando la inscripción y no es posible inscribirse nuevamente. Esto sucede por más que se esté en otro periodo de inscripción. Mi pregunta es: esto funciona así? La inscripción por carrera es única? Saludos!

En guaraní parece solucionarse sacandole el static a la función get_descripcion en lib/toba/php/modelo/lib/testing_unitario/toba_test.php
No sé si esto entraría en conflicto con los tests creados para otros proyectos de Toba. Saludos