Comportamiento del Import
La operación puede implicar:
•Importar la definición del formulario.
•Importar el directorio y otros objetos incluidos en el export.
En el ambiente destino, se pueden presentar diferentes situaciones:
•El formulario no existe.
•El formulario existe y está vacío.
•El formulario existe y tiene datos.
El comportamiento del “import” es como se describe a continuación:
Ambiente Destino Contenido del Import |
El formulario no existe o tiene estado borrador |
El formulario existe y no tiene datos |
El formulario existe y tiene datos |
Definición del formulario |
Se crea el formulario y queda en estado borrador |
Se actualiza la definición de desarrollo del formulario y queda en estado modificado |
Se realizan validaciones para ver si es posible realizar el import con datos. Se actualiza la definición de desarrollo del formulario y queda en estado modificado |
Definición del formulario y otros objetos (tablas auxiliares, reglas) |
Se validan los elementos y se crea el formulario |
Se validan los elementos y se sobrescribe la definición |
Se realizan validaciones del formulario y sus objetos relacionados para ver si es posible realizar el import con datos. |
Si la validación de los objetos importados con el formulario falla, se aborta toda la operación de “import”. Es decir, si una tabla auxiliar es importada con el formulario y dispara un error de validación, el “import” se cancela, más allá que el formulario no posea errores de validación.
Para permitir el import deben cumplirse las validaciones de todos los objetos incluidos en el import.
Si alguno de los objetos a importar da error al importar se desahacen todos los cambios.
Las definiciones que se importan actualizan desarrollo y requieren su publicación manual.
Validaciones
Para el “import” de una definición de formulario digital, si el mismo existe en el ambiente se verificará lo siguiente:
Si el formulario no tiene datos se valida:
•Que no se elimine un campo que se use en reglas embebidas, ser parámetro de reglas catalogadas, ser parte de un flujo, ser atributo de entidades relacionadas, ni campo asociado a agente, ni definir la duración de una actividad o un proceso.
•Que no se modifique el tipo de dato de un campo que se use en reglas embebidas, ser parámetro de reglas catalogadas, ser parte de un flujo, ser atributo de entidades relacionadas, ni campo asociado a agente, ni definir la duración de una actividad o un proceso.
•Que no se cambie el campo identificador que se use en reglas embebidas, ser parámetro de reglas catalogadas, ser parte de un flujo, ser atributo de entidades relacionadas, ni campo asociado a agente, ni definir la duración de una actividad o un proceso.
Si el formulario tiene datos se valida:
•Que no se elimine un campo que tenga datos o se use en reglas embebidas, ser parámetro de reglas catalogadas, ser parte de un flujo, ser atributo de entidades relacionadas, ni campo asociado a agente, ni definir la duración de una actividad o un proceso.
•Que no se modifique el tipo de dato de un campo que tenga datos o que se use en reglas embebidas, ser parámetro de reglas catalogadas, ser parte de un flujo, ser atributo de entidades relacionadas, ni campo asociado a agente, ni definir la duración de una actividad o un proceso.
•Que no se cambie el campo identificador que tenga datos o que se use en reglas embebidas, ser parámetro de reglas catalogadas, ser parte de un flujo, ser atributo de entidades relacionadas, ni campo asociado a agente, ni definir la duración de una actividad o un proceso.
•Modificar el campo para que sea grupo
•Modificar el campo para que sea iterativo
•Cambiar el tipo de control
•Agregar campo a clave primaria
Para cada uno de los objetos relacionados se ejecutan las mismas validaciones detalladas para cada uno.
