Anexo BBDD de test para administradores

Estas bases sirven como test de funcionalidad y de capacidades del programa, NO PARA DEMOSTRACIONES COMERCIALES.

Se pueden manejar SIN edición. Todas tienen un usuario EXPERTO g1 'ingrid' con clave 'ingrid' (con el que entra por defecto), que permite probar diversas funcionalidades. En algunas bases, al pie de la página inicial hay una serie de botones que permiten cambiar entre usuarios con distintos perfiles.

Índice de bases de test

 test-campos ejemplos de programación JS, de utilización del API de Ingrid y de herramientas útiles para hacer otros scripts como: acceso a urls, conexión con programas nodeJS, autofirma, programación para trabajar con XLS, XLSX, PDF, códigos QR... utilidades de Telegram, ejemplos de búsquedas, informes contextuales, acceso a webservices de Ingrid y de otros, procedimientos de mapas, auditorías de logs de la aplicación, parámetros dependientes en informes, restricciones en perfiles de usuarios, inclusión de código de otros procedimientos JS, programar búsquedas sensibles a cada usuario, y accesos a otras bases que tienen ejemplos de programación.

 test-campos ejemplo de todos los tipos de campos y sus utilización, también parámetros de informes, uso de los campos en medidas de operaciones/tareas, campos de traza para hitos, campos en formularios de búsqueda y restricción de permisos por campos.

 test-clases pruebas de jerarquía de clase, definición de campos y cuenta de valores de campos en los documentos (docn). También de análisis de campos que no están dados de alta en las clases y de cuenta cuando se redefinen campos.

 test-documentos flujo de documentos. almacenes y recursos con trazabilidad, pasando por todas las clases, con el ejemplo más complejo: contrato de proveedor-solicitud de oferta-oferta recibida-recepción de oferta de venta-envío de oferta a cliente-pedido de cliente-pedido a proveedor-albarán recibido-factura recibida-albarán emitido-factura emitida.

 test-eventos flujo y programación de eventos sobre campos cuando se leen, graban, y cuando se eliminan y crean conceptos. Ejemplo de aplicación para flujo de creación de diversas clases secuenciales como aviso:-incidencia-tarea correctiva en diversas fases.

 test-flujo otras pruebas de flujo aviso-incidencia-orden de trabajo-certificación.

 test-graficos manejo y visualización de archivos externos vinculados de todas las extensiones (gráficas,, geográficas, documentales), y cómo se visualizan archivos externos en conceptos de tipo Directorio.

 test-indices prueba de búsqueda de texto en diversos campos y cómo se valoran las referencias y puntuaciones en el ranking de búsqueda.

 test-infantiles herramientas para el mantenimiento preventivo con tareas para inspección y mantenimiento de Áreas infantiles.

 test-informes programación de funciones básicas, conexión con telegram... piezas de código de documentan usos concretos, como el apartado de informes comunes > DEMOS y documentación.

 test-mapas representación de todas las formas de iconos, imágenes vectoriales, así como su representación en el mapa, y de todas las primitivas de dibujo (polilíneas, curvas, textos, recuadros, elipses, bloques). Representaciones gráficas (campo Icono) y herramientas de mapa.

 test-movil pruebas de trabajo contra las apps de tareas y avisos offline móviles ingridAvisos, ingridTareas y otras.

 test-parques prueba de 2 contratas con información separada, grupos de trabajo, y plan preventivo. Caso de mantenimiento de inventario geográfico amplio.

 test-permisos pruebas de restricción de información con ámbitos y por perfiles.

 test-referencias pruebas de campos de tipo referencia (selección, clasificación y enlace a conceptos), así como el cambio de tipo entre ellos.

 test-tareas pruebas de todos los tipos de mantenimiento preventivo con operaciones ligadas, de ruta (incluso a varios niveles).

Guiones para realizar los tests

test-campos

- campos.001 - editar los campos, ref y clasif, con el icono y tecleando y tecleando máscaras
- pro.001 - introducir datos
- tarpre.esp.01.ope.001.0001 - cambiar todos los tipos de medidas y comprobar rango de incidencia y requerido
- aviA.01 - deshacer toda la traza de campos con hitos T1-T5 y re-hacerla
- tarcor.03 - deshacer y rehacer el flujo de correctivo
- dir.01 - navegación, descarga, clic en icono para visualización
- car.MAN - recorrer las 5 tarcor. para ver si sus estados son correctos

test-clases

campos:
fecha1 en con y doc
fecha2 en doc y fac
fecha3 en fac y ped

Campo nuevo no creado xxx, en ped y fac

clasificación rot1 en fac con valores asignados en 3 fac (desde con, doc o fac debe contarlos)

- Analizar desde con, desde doc y desde fac

test-documentos

En la propia base, ya que hay un guión para trazabilidad, otro para almacenes...

test-eventos

Documentación de programación de eventos en la documentación de Ingrid: ayuda8.ingra.es

Acceso a información de otros docs mongo referencias lejanas (que no están ni en doc2)
Cuando se quieren presentar en una ficha datos de otros conceptos (instintivamente programando un evento de lectura en un campo virtual $) pero es un dato que no se encuentra en la información leída por la ficha (doc2), se puede crear un campo real en la ficha, de sólo lectura, que será mantenido automáticamente por un evento de grabación cuando cambia el campo, porque los eventos de grabación sí son asíncronos, con cb(), y se puede realizar una búsqueda cualquiera en ellos.
Además la grabación del campo que dispara el evento grabaría a la vez el dato, con lo que no penaliza. El evento se lanza desde interface, por tanto si hacemos un script que rellene el dato original, tiene que rellenar el secundario.
Ejemplo en test-eventos > clase .inc > evento binGraba
En la definición de eventos de la clase se ve que al cambiar bin, se graba la calle del bin CON SU RESUMEN, que no está en doc (inc) ni en doc2 (cuyo doc.docs son los documentos referencia de la incidencia, como la calle espcal, el bin y el usu). El problema es que el resumen de espcal no está en doc2, pero se puede buscar este dato o cualquier otro más lejano en el evento de grabación.

Flujo de múltiples hitos con múltiples clases
La clase MN es un esquema de avisos y tareas TIPO 2 como el necesario en BD Fuenlabrada.

Premisas de funcionamiento y definición tareas tipo 2:
- Cada bloque de hitos o campos de cada perfil, son independientes: no usan (como mucho, visualizan) datos de los anteriores.
- Hay una sola cadena enlazada de objetos de varias clases, pero se pueden hacer flujos de distintas clases, por ejemplo: A-B-C-D ó A-B-F-D. No hay dobles enlaces a siguiente o anterior.
- Cada objeto enlazado se cierra con feccer, en cada momento sólo el último está abierto.
- No se va a guardar estado global de la tarea, que es como una variable global a todas las etapas, cada fase es independiente en campos, no comparten ninguno.
- Pendiente pensar (para este caso concreto de Fuenlabrada) un sistema mejor con un cuadro de partidas de 2 precios (coste/venta) en vez de 2 cuadros

Dos perfiles: u5 (ayto) y u6 (contrata)
66 estados, querían que cambiara el color de icono por clasificación

E1 (usu u5)
campos aviso
A. opciones:
1. No procede -> cambia a E2 (improcedente)
2. Derivar, un campo y enviar mail al organismo competente (policía, canal...) -> cambia a E3 (derivada)
3. Enviar a contrata ->
se crea una tarcor asociada al aviso
ccambia a E4 (enviada a contrata)

E4 (usu u6)
B. ecini, de trabajo -> cambia a E5 (iniciada)
C. completa el parte con 2 relaciones de materiales (consumos):
coste propio de producción (sólo lo ve u6)
coste imputado a ayto
CCampo Total calculado, con importe de coste ayto, refrescado al introducir líneas
feccer, fecha cierre del parte -> cambia a E6 (terminada)

(*) antes de este paso, en SSR, por ejemplo, tienen otros flujos de inspección de trabajos realizados, aceptación de presupuesto... con varios actores más
E6 (usu u5)
D. opciones:
1. Conformidad, fecha de conforme -> cambia a E7 (conforme) y finaliza
2. Rechazar -> motivos y fecha de rechazo -> cambia a E5 y permite acceder a u6 para rectificarla

--------------------------------------------------------------------------------
Otros proyectos similares: Granada incidencias

Otra casuística interesante (Arganda): entran muchísimos avisos por distintos medios (varias operadoras, policía, técnicos de parques...) dan de alta avisos y el primer paso es crear incidencia o asociarle una existente, para lo que tienen en aviso una persiana con las incidencias que coinciden en calle, por fechas. Las incidencias generan tareas.

test-graficos

Por orden de prioridad, desde el directorio \ima\importa:
· arrastrar imagen sobre el concepto de prueba \car.pen > bin.a
· arrastrar un PDF
· arrastrar PDF de tamaño >10MB (superior al límite) : debe dar error
· eliminar una imagen desde lista del panel gráfico
· abrir un gra e importar otra imagen sobre él para reemplazarlo con el mismo código
· probar funciones de rotar imagen, comprueba metadatos, recrea metadatos

- car.01 - entrar en persiana gráficos y ver que los 8 primeros tienen diapo visible
- ir.tiposArchivos - seleccionar todos para ver si los que pone visibles, lo son en la persiana inferior
- bus.02 - casi los mismos archivos del directorio, como referencias locales. Probar alguno de los visibles
- car.03 - probar alguno para ver que referencia remota funciona igual que local
- car.04 - gra.test2.jpg > ver que no da error al usar las funciones de comprobar metadatos y las otras
-- gra.test3.jpg > menú contextual > ver contenido EXIF

- dir.referChrVis - probar que son visualizables en IE
- arc.pruebaGraficos - como documentación para programación. Al usuario no le afecta esa visualización de iframes o divs

test-indices

peso en cabecera: res=10 tex=3. Buscando en búsqueda en LN ‘barco’:
- debe aparecer el primero car.3 con relevancia 15, por doble aparición, car.5 como sinónimo ‘barca’, car.2 por aparición en tex, via.1 como referencia al plural res=’barcos’
- car.6 ‘barquitos’ no aparece como sinónimo

test-informes

Tablas de datos y gráficas estadísticas:
- pro.dia, pro.param - uso de parámetros y diálogos
- car.LIB - cómo incluir código de otros scripts con 2 métodos
- car.EJE - recorrer los ejemplos para ver impresión htm, pdf...
- pro.incN - con un parámetro que es la selección de varios avisos, se devuelven los multi-seleccionados

-car.AUD La traza de modificaciones en la base está activada, cada cambio se registra en el archivo de proyecto \log\AAAA-MM.log
Desde el informe comun se puede consultar:
· cambios de usuario ‘luis’
· filtrando periodo inicial= <blanco> final= 7/2/23 (se muestra 1 día)
· filtrando por orden ‘grabaConceptos’ (muestra 3 del día 9-feb)
·· campo modificado can y valor=10 (muestra 2)

- car.USU Informes de varias subclases con restricciones para que aparezcan contextuales a distintos perfiles. Las restricciones están en la definición de perfiles. Probar con perfiles u2 y u3, con y sin edición los informes que se ven en el menú contextual de un bin.

- car.EVE. Pruebas de Eventos:
1. crear un nuevo concepto inc.x y eliminarlo: se muestran EN EL LOG dos mensajes, uno en el evento elimina() y otro en el eliminado()
2. Modificar las observaciones de inc.1: se lanza un evento que es interrumpido por un mensaje y no se ejecuta el resto del evento
3. Procesar un cierre técnico (feccie1) en inc.1: se interrumpe el flujo tras el campo traza feccie1. El campo con tamaño=2 oculta los campos siguientes
4. Procesar un envío en inc.1: se muestran los campos siguientes en el flujo

test-mapas

- car.[blo, ima,...] - recorrer las 5 para ver que se visualizan ok
- car.[LP, CO...] - ver el mapa, editar nuevos geos de cada tipo, modificar el tipo de geos de líneas a bloques y viceversa
- recorrer toda la barra de conmutadores y botones de edición
- LP.islas - invertir alguna y lanzar procedimiento procesa islas
- bin.22 - comprobar alineaciones con rótulo:
- car.geo - navegar por las estructuras de espacios y ver la superposición y transparencia
- cambiar algún color y transparencia, oculta/mostrar activar/desactivar capas
- menú contextual - vista defecto, 2 volcados, en tablet tomar posición GPS, imprime (lanzar todos), grabar foto, buscar calle, abrir ayuda

test-movil

- Probar primero con el de desarrollo para funcionamiento de la app y comunicaciones con BD online (sin service worker que sólo funciona en localhost o con https). Tiene que estar online.
Ahora los campos se actualizan en tiempo real porque los lee cada vez que se conecta a BD.

https://<DNS_servidor>/movil/ingridtareas/indexdesarrollador.htm
Todos los indexDesarrollador.htm tienen:
ingra.debug=1; // no lanza sw.js ni manifest.json
ingra.trace=0; // modo traza por defecto
Si le pongo:
app.servidor="<DNS_servidor>"
Utiliza servidor y cliente de desarrollo. Con fuentes de móvil de la app PERO OJO! LIBRERÍA INGRA DE ingrid8.

- Luego probar con cliente de i1 y luego en producción.

PRUEBAS DE MOVILIDAD OFFLINE
FUNCIONALIDAD:
- Un grupo de trabajo por cada dispositivo offline. Estos grupos no pueden trabajar a la vez con alguna conexión online
- Sin ámbitos
- Con almacenes para materiales

Pruebas 9/02/18 PRODUCCIÓN:
- https://ingridtareas.ingra.es
- Acceso con base = test-movil la máquina https://ingrid9.ingra.es/ es opcional) y usuario u2/u2 asociado a grupo TR2 > sincronizar tareas pendientes

- 1 tarea de cada tipología en carpeta car.tarpre1
-- Filtro de jefe de mantenimiento: (ya se hace por cada grupo asociado al usuario que accede)

Pruebas a 20/06/16:
-Traslado de tar pendientes un mes para el u2 (TR2):
4 tarpre (no pasan: 2 cerradas y 4 programadas en más de 1 mes)
2 tarcor (no pasan: 1 cerrada y 1 de otro grupo)
-per: hay 2 personas de TR2 para imputar en consumos
-mat: 2 materiales de binasc (no pasan: 2 de otros bins)

test-referencias

- ejemplos de campos múltiples de tipo @ > y S, al comienzo de clase .campos de test-campos

- hijoB.01 - tiene valor en 4 campos de referencia, apuntando con los 4 al mismo padreB.01. Cada uno se muestra en persiana referencias como se indica en el punto siguiente, según su modo de visualización/edición (hay en .hijoB 4 campos, el primero no visible:0 y el resto en orden; visible no editable (excepto para usuarios G1 y admin):1, editable:2 e insertable:3).

- padreB.01 > 4 listas de relaciones al mismo hijo hijoB.02 en ellas y 3 listas de referencias que apuntan desde el hijoB.01

- hijoB.02 - debe mostrar 3 listas de referencias: la r0 no , porque no es visible, la r1 no es editable, la r2 no es insertable y la r3 sí es insertable

- En .car está el campo desl >> con modificador r2 para demostrar cómo se puede modificar el valor por defecto de que las carpetas ocultan las referencias a relaciones

- En el campo # hijoB.rot1, en ficha y en listas debe mostrar el icono (tiene formato 1234).

test-tareas

- car.OPE - operaciones ligadas con 2 patrones de tiempo y elementos con descomposición (seguidores-inversores)
1. eliminar tareas de las 4 primeras operaciones y procesar operación comprobando que la programación es correcta
2. comprobar calendario de las operaciones

- car.OPE >ope.bincua-S - eliminar tareas > procesar operación para crear las de los 3 bins. Probar:
1. cierre sin realizar con medidas y consumos (no debe permitir cerrar con medidas, sí con consumos)
2. cierre con incidencias automática y manual
3. poner medidas de defecto habiendo rellenado ya valores en alguna (debe avisar de sobre-escritura)
4. cerrar varias seguidas y entrar en cualquiera de las cerradas (no debe tener botón de eliminar)
5. Ir eliminando desde la tarea abierta de cualquier bin hasta la primera (la primera no debe tener botón de eliminar)

- car.OPE >ope.rutA - eliminar tareas y comprobar que se generan de las 3 medidas para todos los bins

- car.PRO - programación en el tiempo
1. lanzar sobre cada operación 'Presenta siguientes programaciones' para comprobar si son correctas con su descripción

- car.TRA - filtro por usuarios y grupos de trabajo
1. entrar con usuarios usu.u2 y luego usu.u3 en las clases .tarpre .tarcor para comprobar que un grupo (GT2) no ve las tareas del otro (GT3) y viceversa, sin usar ámbitos
2. comprobar que usu.u3 entra en la carpeta car.G3 (copia de car.G2) aunque su grupo tiene carpeta car.G2
3. Entrar en la tarea de ejemplo de medidas (ope.xEJE) y asignarle el grupo tra.TR2. En línea de consumos poner máscara "todos" (.), sólo debe ofrecer usu.u2 y usu.u2b que son de ese grupo.

- car.G1 y car.G2 - perfiles para jefe y técnico
1. entrar con usu.u1 y comprobar las búsquedas, observar el estado de tareas pendientes de programar

-- ope.xEJE - documentación de todos los tipos de medidas

· car.INF1 : ro.tar.mesorg.comun > config ‘test-tareas2016’ : Hay en operación seg-6M con fecpro entre ago y nov de 2016: 6 tareas en agosto con el doble de consumo que lo previsto en ope (1/2 hora), 7 tareas en sep con el mismo consumo, 1 en oct con 0,5 y 1 en nov con 2h (esta con feccer en dic).
AAdemás 2 correctivas, con ope.COR-1 con fecpro y feccer el 1/9/16 con diferentes espacios

Había una prueba en g1 de bloqueo de permisos con: cla:E bus:E car:E dir:E pro:E D:E G:E R:E, no sé para qué
· car.CAL : pro.calendario.comun > Modo presenta tareas virtuales > fecha por meses jun/2020 > Árbol pro grupos de trabajo: se ven 1 correctiva, 18 prev pendientes ese mes y 374 virtuales que se repetirán ese mes, pero abiertas en fechas anteriores

Si desplegamos este mes por días, vemos correctamente todas las virtuales a lo largo de los días y el día 1, la correctiva, 17 preventivos abiertos y 1 virtual. Desplegando los bins del grupo de trabajo tra.TR2 en el árbol, los totales por día también se ven ok el día 1 (19 tareas).

ingrid-produc

Test de gestor de cluster bases.json
ok:
- crear nueva base
- eliminar base de su motor (incluyendo directorio)
- abrir base de otra máquina : no permite
- hacer y recuperar copia de seguridad
- no hay renombre base (se copia y elimina anterior)
- actualizar ingrid-* y test-* de cluster producción
- si hay bson más moderno, al acceder a la base, lo monta, importando sobre la BD que haya
- al abrir motor, crea en bases.json todas las que tiene montadas en él. Las fusiona ok con las de otra máquina con la que se haga lo mismo
- cada máquina del cluster abre el ingrid-comun montada en su motor
- abrir una base no montada en una máquina la monta en esa y actualiza bases.json
- interface de motor cronos > base montada en motor luis > doble clic > se abre con cliente en máquina cronos y servidor+base en máquina luis

pendiente a 2023:
- editar observaciones desde interface
- base montada en otra máquina: gestionar que no esté montada en más de una