Hola,
En la operación “Otorgar Equivalencias”, luego de completar todos los datos, no permite guardar la equivalencia. No se habilitan los botones de “finalizar” y volver, mientras que los de “aceptar” y “cancelar” de cargar equivalencias tampoco funcionan. Ni se permite cambiar entre “Datos principales” y “cargar equivalencias” Mandé GDS (Nº13346), y me dijeron que lo consultara por acá
Saludos
Hola Romina,
Es correcto que mientras se edita una equivalencia no se puedan presionar los botones “Volver” y “Finalizar” ni cambiar de solapa. Los botones “Cancelar” y “Aceptar” están habilitados pero no tienen ningún efecto? Verificaron que no haya errores JavaScript?
Saludos, Florencia.
Hola,
seguimos mirando, y encontramos que al seleccionar la nota parece romperse JavaScript. El error está relacionado con el componente …operaciones/_lib/cuadro_seleccion_multiple.php (No personalizado). Más especificamente, parece fallar al querer validar el ef_combo:
ef_combo.prototype.validar = function () {
if (! ef.prototype.validar.call(this)) {
return false;
}
var valor = this.get_estado();
if (this._obligatorio &&
this.input().type != 'hidden' && ---> Acá falla
(valor == apex_ef_no_seteado || this.input().options.length === 0 ||
valor === null)) {
this._error = 'es obligatorio.';
return false;
}
return true;
};
Tambien les adjunto un pantallazo del error
Hola Romina,
en qué versión del sistema están trabajando? Cuál es el estado del componente ‘form_actividad’, correspondiente al componente ei_formulario con identificador: 34000203 (Otorgar Equivalencia/editor/edicion_equivalencia)? Verificá si han personalizado estos ef’s, ya que en la imagen que adjuntás el campo Nota, que te está trayendo problemas, aparece como un ef de tipo combo y en la versión original del sistema es un ef editable. Posiblemente también tengas alguna clase que esté redefiniendo el comportamiento javascript del formulario.
Saludos,
Gabriela.
Hola,
efectivamente es un combo personalizado, que trae las notas de una consulta. Estamos intentando ver porque falla. Todavía no encontramos el error. Cualquier cosa, nos volvemos a contactar, para ver si nos pueden dar una mano. Lo que sí intentamos hacer, es volver al estado sin personalizar. Cambiamos la fuente de datos del componente, exportamos los cambios en nuestra local y regeneramos. Pensamos que con esto sería suficiente, pero el combo siguió quedando. ¿De que manera se puede volver a la versión sin pers. para ese componente?
Saludos
Hola Romina,
si lo que quieren es volver al estado original del metadato, con sólo cambiar la fuente del componente no alcanza. Deberían modificar los ef’s que hayan cambiado, la clase php de la que extienden si es una personalizada…etc. Las opciones serían:
. Que modifiquen manualmente el metadato, conservando los cambios que desean y deshaciendo los que no, comparándolo con el componente originalmente incluído en la versión. En este caso sí es correcto que exporten y regeneren, como hicieron antes.
. Si desean revertir todos los cambios pueden hacer un ‘update to revision’ de ese archivo de metadato únicamente. Por lo que veo en su rama del colab, la primer revisión en la que ustedes introdujeron cambios en los metadatos es en [2057], con lo cual alcanzaría con volver a la revisión anterior, ejecutando el comando: svn update -r 2056 [path_copia_local]/metadatos/componentes/toba_ei_formulario/dump_34000203.sql
En este caso, luego de esta acción deben ejecutar un regenerar del proyecto (guarani proyecto regenerar), y luego seguir trabajando con normalidad.
(Podrían pisar el archivo con la copia existente en metadatos_originales, pero esto no les conservaría la historia svn del mismo, y además les van a quedar cambios locales hasta el próximo commit innecesariamente).
Saludos,
Gabriela.