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 en edición modificando o destruyendo cualquier dato, ya que se restablecen cada 2 horas. Todas tienen un usuario ADMINISTRADOR ingrid con clave ingrid (con el que entra por defecto), que permite probar cualquier funcionalidad. 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 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-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 controladas 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://cronos.ingra.es:8420/movil/ingridtareas/indexdesarrollador.htm
Todos los ndexDesarrrollador.htm tienen:
ingra.debug=1; // no lanza
sw.js ni manifest.json
ingra.trace=0; // modo traza por defecto
SSi
le pongo:
app.servidor="https://cronos.ingra.es:8420"
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://i.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 sep-2017
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:
- editar observaciones desde interface
- base
montada en otra máquina: gestionar que no esté montada en más de una