Clases del administrador

Introducción

Sólo los usuarios de BD con perfil administrador pueden modificar el modelo de datos; tanto las clases que componen la base y sus relaciones, como los campos, y eventos que tiene cada cada clase. Además tiene todas las herramientas para hacer operaciones masivas sobre la BD e incluso un conjunto de ellas dentro de los proyectos del cliente.

Las siguientes clases son utilizadas por el perfil habitual de usuarios de una clase (experto) e incluso perfiles de técnico, operador o visualización con menos permisos, pero ninguno de ellos puede cambiar los datos que se describen, ni crear conceptos de estas clases, sólo utilizarlos.

  • Carpetas.- Para organizar la información en distintos niveles jerárquicos, muestran en su persiana Descomposición el contenido ordenado como deseemos.
  • Búsquedas.- Realizan una búsqueda entre todos los conceptos de la BD y la muestran como si fuese el contenido de una carpeta, pero cada vez que entramos se realiza la búsqueda en tiempo real.
  • Procedimientos.- Programas en lenguaje javascript estándar, apoyados sobre las APIs de programación que ofrece la aplicación, para  programar tanto informes como búsquedas complejas y herramientas de cualquier tipo. Con Ingrid se ofrecen más de 270 que también sirven de ejemplo para programar los nuestros.
  • Imágenes y archivos adjuntos.- Almacenan toda la información de cualquier archivo externo de cualquier formato, relacionado con BD. Estos conceptos que contienen información del tamaño en KB, dimensiones, nombre, vista reducida y otros de cualquier archivos de imagen JPG, PNG, o de documento PDF, XLS, DOC o cualquier otro multimedia o de cualquier tipo, se pueden asociar en al persiana de Imágenes de los conceptos.
  • Mapas base.- Fondos ortofotográficos, WMS, TMS de fuentes liibres o de pago, que podemos incorporar en los proyectos al usar información geográfica, además de los propuestos habitualmente (Google Maps, Microsoft Bing, OpenStreetMaps...). 
  • Directorios.- Representan un acceso a los directorios en el espacios del servidor de Ingrid para cada proyecto, donde podemos gestionar nuestros archivos en remoto como si se tratara del explorador de archivos de nuestra máquina local.
  • Usuarios.- Cada usuario de acceso a BD con su perfil de permisos, sólo los administradores de BD pueden verlos y gestionarlos.
  • Bajas.- Para archivar los elementos de cualquier clase que queramos hacer desaparecer de nuestro proyecto, pero no podemos eliminar porque tienen relaciones con otros conceptos (presupuestos, informes, tareas realizadas, inventario...)

Clase Carpetas

Permiten organizar los contenidos de la BD por apartados y establecer los puntos de entrada de cada perfil de usuarios. En el caso de personalizar los iconos (con la opción correspondiente del menú contextual) se recomienda poner iconos de 32 pixels para los grandes apartados y sólo a primer o segundo nivel. En principio sólo de deben personalizar los iconos de carpetas, cambiar los de otras clases de conceptos, da lugar a confusión.

Mediante clic con el botón izquierdo del ratón en su icono, se navega a los conceptos relacionados explícitamente, "colgados" o "contenidos" bajo una carpeta. Se vuelve al nivel superior con clic derecho del ratón en cualquier parte de la página. En dispositivos móviles, al no existir clic derecho, se puede hacer manteniendo apretado dos segundos en el borde de la pantalla, o la cabecera, entre logos.

En la parte superior de la página (sobre el Código y Resumen del concepto), siempre se muestra el camino recorrido navegando por el árbol de carpetas. Además cada paso del camino es un vínculo que nos lleva directamente a ese nivel.

NOTA: al copiar y pegar estos conceptos entre diferentes BBDD, no se pegan sus referencias a imágenes relacionados, otros conceptos, etc.

Persiana Carpeta

Primero se muestran los campos comunes a todos los conceptos: Resumen o nombre, Descripción y Observaciones del concepto.

La sección Propiedades, es de funcionamiento común también a los conceptos de clase Búsqueda y Procedimiento. Para CADA CONCEPTO INDIVIDUAL, se puede definir:

- Clase contenido define las columnas de defecto que se van a mostrar en la lista de la persiana Contenido (las que se recuperan también con la opción Presenta defecto del menú contextual de la cabecera de lista). Cuando hay definida una Clase contenido, se muestra el icono de esa clase al lado del icono de la carpeta. Esta opción sustituye la vista de defecto del contenido de la carpeta, que se toma del primer elemento de la lista, es decir, si NO hay Clase contenido y el primer elemento relacionado en la lista es una Persona, mostrará la vista de defecto de personas y si es un Grupo de trabajo, la de los grupos de trabajo.

A continuación, la presentación de Propiedades descritas detalladamente en la sección Clases, persianas comunes > Persiana clase > Propiedades: es decir, si se presenta la persiana de Imágenes, y qué es lo que muestra, así como un campo con opciones para indicar qué información ver en la persiana del mapa (Georreferencias).

Por último los campos Particulares definidos en la clase Carpeta, si los tiene.

Persiana Contenido de la carpeta

Aparece una lista de conceptos con los que se ha relacionado 'colgándolos' explícitamente como descomposición de esta carpeta y en el orden actual.

En el campo _Id se pueden teclear códigos para relacionar una lista de conceptos. Esta relación puede estar en múltiples carpetas y otros objetos de BD.

Tecleando texto en el campo Resumen, se busca esa cadena en los resúmenes de BD, pudiéndose así, insertar en al lista conceptos por su nombre.

Teniendo seleccionada una celda cualquiera:

Pulsando CONTROL+INSERT, se pueden introducir líneas en blanco como separadores de los elementos de la lista o para teclear nuevas relaciones de conceptos.

Pulsando CONTROL + SUPR, se "descuelga" o elimina esa relación en la carpeta actual, (el concepto, no).

En el campo Comentario, se pueden hacer aclaraciones, tanto en líneas vacías de separadores, como en líneas que tiene relacionado un concepto. En el caso de líneas vacías, el comentario se reproduce en color verde en el campo Resumen, para tenerlo más visible. Además si se teclea un apóstrofe ( ' ) delante del texto en el Resumen, en vez de realizar una búsqueda, se modifican las Observaciones de esa línea.

Clase Búsquedas

Al hacer clic en su icono, se muestra una lista de conceptos resultado de una búsqueda en el motor de BD mongoDB. La lista no es una relación explícita de conceptos relacionados con o "colgados" del concepto (como en el caso de los conceptos de clase Carpeta), sino una lista de conceptos buscados por un criterio.

En el campo Búsqueda asociada se soporta un lenguaje abreviado de búsquedas que incluye también hacer llamadas directas de búsqueda en el motor de BD mongoDb. El resultado de la búsqueda se muestra en al persiana Resultado. Se puede ver la especificación del lenguaje de búsqueda en:

Anexo: sintaxis de Búsquedas en mongoDB y reducidas

Persiana Búsqueda

Primero se muestran los campos comunes a todos los conceptos: Resumen o nombre, Descripción y Observaciones del concepto.

La sección Propiedades, es de funcionamiento común también a los conceptos de clase Carpeta y Procedimiento. Para CADA CONCEPTO INDIVIDUAL, se puede definir:

Clase resultado en búsquedas indica el formato de columnas de los conceptos mostrados como resultado, ya que pueden ser de muchas clases y la primera línea no siempre es la más significativa.

A continuación, la presentación de Propiedades descritas detalladamente en la sección Clases, persianas comunes > Persiana clase > Propiedades: es decir, si se presenta la persiana de Imágenes, y qué es lo que muestra, así como un campo con opciones para indicar qué información ver en la persiana de Georreferencias.

Por último los campos Particulares definidos en la clase Búsqueda, si los tiene.

Clase Procedimientos

Los conceptos de esta clase (código .pro) permiten a los usuarios de perfil administrador programar en la aplicación, apoyados por un entorno de desarrollo estándar. Estos programas pueden realizar acciones en el cliente y/o en el servidor, utilizando las funciones publicadas por este.

Estas acciones pueden ser operaciones sobre la BD, como búsquedas que muestran una lista de conceptos en pantalla, generar informes en formato html (para imprimir a formato PDF desde el navegador), imprimir o importar y exportar archivos, operar con los archivos del directorio de la BD en el servidor, manejar datos de varias bases...

En el tema API de programación en javascript se encuentra la documentación de las funciones que se pueden utilizar.

Tenemos un amplio Catálogo de informes y procedimientos incluidos con la aplicación.

Base de ejemplo: test-informes, para ver y probar piezas de código didácticas.

Base test-campos, para ver y probar el uso de parámetros de los procedimientos.

 

La programación tiene que ser asíncrona tanto en los accesos a BD, como en otros procesos (por ejemplo, lectura/grabación de archivos) en los que no se puede garantizar el tiempo de respuesta, y ni siquiera si habrá respuesta.

En la BD ingrid-comun, hay una biblioteca de informes que se pueden usar desde cualquier proyecto como si estuviesen en ella, de 4 formas distintas:

  • Desde la pestaña de Menú > Procedimientos
  • Con una referencia especial que consiste en crear un concepto de clase procedimiento (.pro) y poner el mismo nombre que el informe en el comun, con el _id acabado en ".comun", como: pro.con1.comun
  • En algunas clases, aparecen automáticamente informes contextuales a esa clase de nuestra BD
  • Haciendo una llamada a ellos en un procedimiento de nuestra BD, para incluir su código javascript (por ejemplo librerías para programadores)

Además se pueden ocultar los procedimientos contextuales del comun en las bases, creando uno vacío con el mismo nombre, como por ejemplo (pro.con1), poniéndole en la base que es contextual (de la clase 'con' en este caso) y dejando el resumen en blanco.

Los usuarios no administradores, sólo ven una persiana con los parámetros que se pueden modificar y un botón Procesa para ejecutar el script. El resto de las opciones a continuación sólo las utilizan los administradores.

Persiana Procedimiento

Dentro de persiana Procedimiento > Procedimiento. Esta sección tiene los campos que definen el comportamiento de un procedimiento o informe programado en javascript.

En el menú contextual al pie de cualquier página , se muestran los informes asociados a esa clase y sus clases superiores, mediante el campo accesible sólo para administradores, Clase asociada. Por ejemplo, en un documento de clase factura, se mostrarán:
· Informes individuales (no múltiples) de la propia base para las clases fac, doc y con
· Informes individuales (no múltiples) comunes de la aplicación para las clases fac, doc y con

Además de los informes de la propia base asociados a la clase del concepto actual mediante el campo Clase asociada, se muestran todos los de la base ingrid-comun que estén asociados a la clase, a sus clases ascendientes. El código de procedimiento en la pista (tip) se muestra con un sufijo  ".comun" detrás, que indica que se ejecutan como si estuviesen en la base actual, y sobre los datos de la base actual, pero con el programa javascript leído de la base ingrid-comun.

Además, cuando en la persiana geomapa de cualquier página de conceptos, multi-seleccionamos una o varias entidades geográficas (bloques, polígonos, líneas...), EN EL MENÚ CONTEXTUAL de la propia persiana Georreferencias se muestran los informes contextuales a las clases seleccionadas, a sus clase ascendientes y los asociados a la clave 'geol'.

Hay otras claves que no son realmente clases, e indican que qué listas o persianas se mostrará un procedimiento, cuando tenemos una selección o multiselección:
con: cualquier concepto
linl: seleccionando línea/s de desglose de documentos
conl: seleccionando conceptos en el resultado de una búsqueda (de clase bus o pro)
desl: seleccionando conceptos en listas de descomposiciones de otros conceptos
geol: seleccionando elementos geográficos en la persiana de georreferencias

 

Descripción de modificadores de comportamiento Contextual:

Múltiple indica que admite no sólo un identificador actual seleccionado, sino una lista de ellos (sean de la misma clase o no), y por tanto, se mostrará  de forma contextual, también con una lista de conceptos de los indicados como clase. En la base test-informes, tenemos un ejemplo en pro.con2 · Listado de conceptos.

Importante indica que el procedimiento en vez de mostrarse en menús contextuales, se convierte en un botón al pie de la página de la ficha de concepto. Por tanto no es combinable con el modificador Múltiple.

OJO! El modificador Importante (nn en fichas) es incompatible con Múltiple, ya que se lanzaría sobre una multiselección en una lista o geomapa, que no tenemos en la ficha; y por otro lado los Múltiple no se muestran en la selección de un solo un solo concepto.

Rojo simplemente rotula el botón (si es Importante) o la aparición en menús, con el color rojo de editable, y además de ocultarse cuando el proyecto no está en edición, documenta que realiza modificaciones en la BD o sus archivos.

Autoprocesa indica que se ejecute automáticamente, sin tener que pulsar el botón Procesa. Esto es cómodo para scripts de búsqueda, o procedimientos de cálculo, por ejemplo. Al entrar es el modo normal y Sin interface, se ejecuta sin siquiera saltar a la página del procedimiento,

 

Para administradores: Personalización de parámetros de los informes

Se dispone de varios informes que son una recopilación de varios que se suelen imprimir juntos, para poder presentarlos como un único report con portada y una única paginación. Estos scripts tienen como parámetros casillas para seleccionar qué informes queremos lanzar en cada momento. Por ejemplo, Todos los informes de presupuesto, Todos los informes de certificación, etc.

Hay 3 formas de configurar el formato y presentación del conjunto de informes que se incluyen en estos informes globales:

1. La más sencilla. Modificar en esta misma persiana, la orientación de página, colores o si queremos que aparezca el nº de página o la fecha en el encabezado, pero afectará por igual a todos los informes del paquete basados en los parámetros generales.

2. Si queremos modificar el contenido (que salgan precios de letra o no, formato ancho o estrecho de columnas, etc. sólo en alguno de los informes del paquete, hacemos una copia del informe comun en nuestra base y modificamos las variables con las que se llama algún informe. Por ejemplo, en la línea 33 del que lanza Todos los Presupuestos y mediciones, tenemos:

function(cb1){ if (!vals.cdp1a) return cb1(); procesaInforme ("pro.pre.cdp1", {conaux:1}, cb1); },

Podemos quitar que se ejecute el de cuadro de precios 1 sin tener en cuanta auxiliares en clases cambiando conaux:0, o bien añadir connum:0 o conprelet:0 para que se imprima sólo con números de orden y sin precios en letra. 

3. El control más detallado: Copiar el informe comun que queremos modificar en nuestra base y modificar (tras copiarlo también) el informe que ejecuta todos para que llame al nuestro particular.

Definición de Parámetros

En cada concepto de esta clase, a la manera de la definición de campos, se puede definir en el modelos de datos una lista ordenada de campos que sirven para introducir datos variables en la ejecución de cada script. Se pueden usar muchos de los tipos de campos disponibles en la definición de clases: enteros, reales, texto, referencias a conceptos (incluso a múltiples en el mismo campo), a rótulos especificando qué clase y campo queremos ver como opciones, booleanos, archivos con directorio, desplegable con selección de opciones, y algunos otros...

Además, los informes contextuales incluyen por defecto el parámetro 'con', y el parámetro 'bus' en los informes múltiples, que hacen referencia al concepto actual o a la multi-selección de conceptos, con los el que se ha lanzado el informe.

En la esquina superior derecha de la persiana Parámetros (donde se introducen los valores deseados), pueden aparecer varios botones:

  • Pulsando el conmutador Presenta opciones avanzadas, cambia inmediatamente de estado a  Oculta opciones avanzadas, y muestra los parámetros que en la definición del informe se han considerado de menos uso, o para usuarios más avanzados, o bien secundarios. Este estado se guarda sólo para la
  • El botón Pone parámetros por defecto, carga los valores puestos en cada parámetro, en su campo Valor de defecto. Además, si es la primera vez que se entra en el informe y no hay memoria de los datos introducidos en los parámetros, se ponen inicialmente los valores de defecto.
  • El botón Configuraciones de parámetros, permite almacenar un conjunto de valores para los parámetros con un nombre, para recargarlos cuando se desee. Al hacer clic en él, la información que veremos dependerá de si es:
    · Un informe de la aplicación (con el código terminado en .comun). En este caso, podemos ver dos partes: en la superior las configuraciones pre-grabadas en el informe de la aplicación en color negro y las destinadas sólo a la base actual en color verde, y en la inferior la lista de las particulares que hemos grabado nosotros..
    · Un informe en nuestro proyecto. En este caso sólo tenemos la lista de las configuraciones grabadas por nosotros.

    Situando el cursor sobre el nombre de cada configuración, veremos los valores que contiene. Cada configuración pone valores a todos los parámetros, es decir, los que no están definidos, se ponen como cero, vacío, nulo, cadena vacía... según el tipo.

    Bajo la lista de configuraciones, si las hay, y sólo SI EL PROYECTO ESTÁ EN EDICIÓN y tenemos perfil administrador, aparecen opciones en el color naranja de edición para: Grabar todos los valores actuales con un nombre, Eliminar una de las configuraciones (sólo si hay alguna), o Regrabar una configuración existente, con los valores actuales.

Definición de programa

En esta persiana se puede editar el código javascript (ECMAscript estándar) usando todas las funciones de todas las librerías del cliente web. Puede ver información avanzada de programación y el entorno de desarrollo en el Anexo Procedimientos javascript.

Para depurar el código javascript tanto de eventos como de procedimientos, recomendamos el entorno de desarrollo completísimo y de uso libre Visual Studio Code,  que permite puntos de parada, examen de variables y funciones paso a paso, etc.

En la esquina superior derecha de la persianas de edición de código javascript tenemos el botón Graba 'procedimiento.htm', que permite guardar el contenido del programa actual en un archivo con el nombre del procedimiento en el directorio que deseemos. Se trata de una página independiente que se conecta a la BD con las credenciales actuales y se ejecuta como si fuese un cliente muy ligero, para probar el informe o procedimiento que estamos programando, contra la BD actual (o la que pongamos si cambiamos el parámetro).

Datos de entrada a los informes contextuales (para administradores)

La lógica de ejecución de los informes contextuales es la más compleja de explicar por la potencia y flexibilidad que permite.

Cuando seleccionamos conceptos en una lista, en los menús contextuales de la lista (casillas) y también en el menú contextual a pie de página, se pueden mostrar informes contextuales a las clases de los conceptos seleccionados; esto pasa:
· En los conceptos relacionados bajo una carpeta
· En la lista de conceptos encontrados en una búsqueda (clase .bus o procedimiento .pro)
· En las listas de datos de un concepto (recursos de tareas, líneas de detalle de documentos, consumos, personas de un grupo de trabajo...)
· En la selección de una o varias georreferencias en una persiana de mapas

Además, estos procedimientos pueden comportarse de varias formas  al saltar a ellos, según los campos de comportamiento de los contextuales:
· si se Autoprocesa al entrar, no habrá que pulsar ningún botón, esto es interesante para herramientas asociadas a conceptos que no requieren parámetros, por ejemplo
· si se Autoprocesa Sin interface, se ejecutará el código javascript sin pasar a la página del procedimiento
· si es Importante, aparecerá como un botón al pie, en vez de en el menú contextual de la ficha (o al pie de la página de búsqueda si es un informa Múltiple)
· si es Rojo se mostrará en ese color para indicar que realiza modificaciones y además se ocultará si no estamos en Modo Edición

 

Estos procedimientos se ejecutan, digamos así, en 3 niveles:

1. En la variable objeto pro.contextual2 llegan:
    - de la ventana las variables: doc, doc2, docs (conjuntos de los objetos concepto de doc2), docl (lista de _id de todas las referencias del documento página actual
    - de la selección de conceptos: pad, que es el _id padre (la página concepto actual), inca si es una selección en el mapa, las listas dl, rl y sl con los _id de los conceptos multiseleccionados (puede ser un array de 1 elemento), las relaciones de los seleccionados y los objetos concepto seleccionados, y OPCIONALMENTE; si es una sola selección, las variables d, r y s con el _id, los datos de relación y el propio concepto completo. 

2. Luego entran los parámetros vals.* (si tiene). No es obligatorio, ya que si no hay ninguno, se pone un botón automático 'Procesa'

3. Variables del procedimiento (pro.*). Para los casos sencillos no hace falta programar a la entrada con el parámetro 'inicia' asignaciones de variables, pero esto aumenta la potencia de los que podemos hacer:

 

Clase Imágenes y otros archivos adjuntos

Cada concepto de esta clase. representa un archivo externo a la BD que habitualmente se van a relacionar con conceptos de BD de otras clases; por ejemplo asociaremos fotos, gráficos, o documentación en formato pdf a conceptos de clase bin, tareas, inspecciones...

Aunque habitualmente se trata de archivos imágenes con alguna de las extensiones admitidas y visibles por los navegadores, (JPG, GIF, PNG) o archivos documentales (como PDF, XLS, DOC), se puede crear un concepto de esta clase y asociarlo a cualquier concepto, sea del tipo que sea. Los reconocibles, además, tendrán una visualización según el tipo; los que no lo son, se pueden descargar al equipo o dispositivo móvil local.

Esta clase de conceptos permite tener un vínculo directo a los archivos de dos formas:

- un archivo en los directorios del proyecto, en el servidor (con caminos relativos al directorio raíz de cada proyecto)

- una referencia absoluta a una url de internet dentro de nuestro mismo proyecto o no. Ejemplos:

https://ingrid9.ingra.es/bases/test-graficos/alta/a.jpg
https://bases.ingra.es/test-graficos/alta/a.jpg

Editando el campo Archivo local o web (alta), se especifica el destino a abrir y se puede aplicar Abrir en pestaña nueva. Con este modificador marcado, el contenido a visualizar se abre al entrar en al ficha en otra pestaña del navegador en vez de en la persiana de vista previa.

La ventana de propiedades de esta clase, permite realizar búsquedas por todos los datos de un gráfico: dimensiones en pixeles, en tamaño de archivo, nombre, código, ámbito de protección, fechas de creación, eliminación, modificación...

 

Si se trata de fotografías/imágenes:

Cada imagen tiene al menos 1 y hasta 3 versiones, en diferentes formatos y tamaños. Al insertar una imagen en BD siempre se crean automáticamente estas versiones, cuando es necesario. El administrador y el experto pueden gestionarlas en la persiana Globales de la definición de clase.

Como mínimo, una imagen si no es muy grande, se almacena en el directorio de proyecto del servidor \ima\alta con la resolución con la que se ha subido al servidor, y se genera una versión reducida, almacenada en el directorio \ima\media) que sirve para las diapositivas de listas o para una vista previa rápida. Los tamaños de ambas vistas reducidas los establecen los administradores (pulsando modo admin) en: Menú >  Configuración > Imágenes

Si al subir la imagen, se excede el tamaño Dimensión máxima de Alta resolución, se guarda la original subida en el directorio \ima\original. Esta versión archivada se puede visualizar en el BD con un botón que muestra en una pestaña diferente esa máxima resolución.

Al arrastrar un gráfico nuevo sobre el panel de imágenes de un concepto de clase imagen (sólo se admiten del mismo tipo de archivo), se reemplaza el contenido de la imagen, manteniendo todas las referencias en la BD.

Si la imagen tiene información EXIF que contenga ubicación GPS (aunque tenga EXIF puede que en la cámara se haya bloqueado esta información), al importarla, se crea automáticamente la referencia geográfica.

 

En otros tipos de archivos:

Al hacer clic sobre el concepto, se abre una vista previa del contenido como como si seleccionamos el archivo en un concepto de tipo directorio.

Se admiten vínculos a todo tipo de archivos, pero los únicos visualizables son los que puede visualizar el navegador como texto: TXT, CSV, CSS, JS, JSON. GEOJSON, HTM, los de imágenes o documentos: JPG, GIF, PNG, JPEG, PDF y algunos que visualiza especialmente nuestra aplicación: IGRA (gráficas estadísticas, IGPS (trazados de posiciones geográficas), y BODY (textos ricos html sin estructura de página, sólo con el contenido textual del body, al que se aplican los estilos de la aplicación).

 

Si es un archivo .BODY:

La diferencia de visualización entre un archivo HTM o HTML y uno BODY, es:

 - en páginas web, los estilos están en la página y tiene un visualizador de una altura fijado (si la página es más larga, aparece un control de scroll vertical)

- en documentos .BODY, los estilos son los mismos de la aplicación, los textos visualizan mejor las tabulaciones, y el visor muestra todo el texto: el único scroll vertical es el de la página de Ingrid.

En  la zona superior derecha de la persiana de vista previa, para archivos de tipo texto (los primeros enumerados en el párrafo anterior, y la extensión BODY):

El botón Editar, permite a los administradores y expertos de perfil g1, editar en el servidor el propio archivo de texto al que se hace referencia, y al volver a pulsar el botón, dejarlo grabado.

El botón Presenta como texto, muestra en otra pestaña el contenido real del archivo de texto (distinto por ejemplo, cuando es un archivo HTML).

Persiana de la vista previa de la imagen

Si se presenta en la persiana el mensaje ERROR: Formato no soportado, por no ser visualizable con ninguna de las librerías, en el lado derecho de la persiana tenemos el botón Descarga para poder visualizarlo en nuestro equipo.

En la cabecera de la persiana, en color azul a la izquierda se muestra en nombre del archivo enlazado (que puede ser distinto que el código del concepto gráfico en BD, en algunos casos) y a su derecha puede tener uno o dos bloques con ancho x alto (tamaño KB o MB). Si hay uno, son los datos de la imagen de alta resolución, si hay otro detrás, son los datos de la imagen original.

A la derecha en la cabecera, están los botones:

· alta / media, que alternan la vista entre ambas resoluciones.
· alta/ original, sólo si se ha reducido la versión en alta, para poder mostrarla
· Presenta en ventana independiente, que abre el archivo de media, alta u original que se esté viendo actualmente
· Descarga, el tamaño presentado actualmente.

Persiana Globales

En la página de la clase, la configuración global la pueden modificar los administradores si están en modo Admin, desde Menú > Configuración > Imágenes

 

Límites de la librería gráfica sharp

La librería gráfica sharp es más potente y rápida en todas las funciones que soporta (por ejemplo, convertir TIF a PNG u otro formato), por esos siempre se utiliza para todas las funciones que se pueda. Donde no alcanza, se utiliza la librería ImageMagic.

Si se intentan procesar archivos mayores que una resolución total de 268 Mpx (valor de defecto de la librería), se devuelve un error y se sigue procesando el resto, por ejemplo esto admite imágenes de  29.000 x 5.000 puntos ó 7.000 x 18.000

En algún caso, estando dentro del tamaño permitido, se muestra un aviso o error de manipulación de archivos debido a la compresión, sub-formatos... se deben procesar estas imágenes  antes de importarlas, con alguna aplicación de edición de imágenes.

Rendimiento y API de utilización: http://sharp.dimens.io/en/stable/performance/

 

Procedimientos con herramientas en ingrid-comun

Menú > Procedimientos Comunes > Imágenes y gráficas > Chequea gráficos (gra.chequea)

 

Herramientas avanzadas para administradores

Cuando se asocian entre 50.000 y 100.000 archivos externos en una BD y sobre todo cuando es una base documental con archivos de mucho tamaño, como imágenes de 50-100MB o más, se debe seguir en el servidor una estrategia para archivar las imágenes en archivos .zip (ocupan lo mismo, pero son decenas de miles de archivos menos de los que hacer copia de seguridad).

El servidor de archivos gestiona los archivos comprimidos en formato .zip (preferiblemente sin compresión para facilitar la velocidad de acceso) de forma transparente como si se encontraran en la carpeta de \alta y \media. Basta con poner el mismo nombre al .zip que al directorio que tiene al mismo nivel.

Clase Mapas base

Almacenan la información necesaria para seleccionar distintas coberturas de fondos (ortofotos, WMS...) en el menú de Capas base de la persiana de Georreferencias.

En la base ingrid-comun, en al carpeta car.map.comun, está la configuración de la aplicación donde se indican como bases activas las que se ofrecen por defecto en el menú de bases de cualquier persiana de mapas, y su ordenación. Además, si hay alguna definición de mapas en al base actual, aparecerán en primera posición.

En la aplicación hay un catalogo de 180 fondos de muestra, incluyendo históricos de diversas épocas, mundiales, de España, particulares de Comunidades Autónomas... pero se pueden encontrar muchísimos más.

La parametrización es el código Javascript y url que permite conectar a la librería leaflet con la fuente de mapas. Ejemplo del  HERE_normalDay de Nokia:

Clase Directorios

Los conceptos de esta clase, permiten acceder a un directorio dentro del servidor, donde almacenar y gestionar todo tipo de archivos externos al motor de BD.

A partir de la carpeta raíz asociada a cada BD, los administradores pueden crear otros conceptos de tipo directorio que abran subdirectorios de ese.

Se admiten todo tipo de archivos. El control tiene un visualizador de los archivos soportados por el navegador: PDF, fotos JPG, GIF y PNG, TXT, aunque también se soportan los archivos de formato propio de Ingrid: gráficas estadísticas .IGRA, archivos de posición geográfica .IGPS,

Además, los archivos de formato geográfico INCA, DXI y GEOJSON, se pueden editar en el control de mapa que se muestra como "vista previa" y regrabar las modificaciones directamente en el servidor sin descargar y volver a subir archivos, al igual que se hace con los archivos de texto en formato TXT, JSON, BODY (html particular de Ingrid) que se pueden editar directamente con el botón de la zona superior derecha de la persiana de visualización;

Interface

El administrador tiene el botón Calcula nº y tamaño de archivos por directorio, para recorrer los datos en un momento dado y acumularlos. Este cálculo no se hace en tiempo real porque sería muy costoso hacerlo constantemente para miles de archivos/directorios. Sólo se calcula el nº de archivos y tamaño total de las carpetas, de los archivos no se ofrece ninguna información más que el nombre cuando son más de 200.

El tamaño máximo en MB de archivos a subir al servidor está limitado por la definición de la clase Imágenes.

El tamaño máximo de los archivos visualizables al bajar del servidor (geográficos, de texto, o los propios de Ingrid como inca, dxi, igra, igps...) está limitado a 10 MB por motivos prácticos. Pero al seleccionarlos, siempre se pueden descargar en el tiempo que sea necesario.

El menú contextual permite subir archivos al directorio del servidor (Copia archivos locales) igual que haciendo drag&drop, si se está en edición, sobre el recuadro de la lista de archivos y directorios.

Con una multi-selección de líneas en las casillas que hay en la columna del menú contextual, se pueden realizar operaciones de copia, movimiento y eliminación de archivos, NO de directorios. Se pueden renombrar archivos y directorios cambiando directamente la columna Nombre.

Con CONTROL+clic se seleccionan líneas individuales, con [Mayúsculas+clic] se selecciona en bloque todas desde la seleccionada más cercana, al estilo habitual de Windows. Si se aplican a líneas seleccionadas, se invierte la selección.

Al hacer clic en el icono de cada línea, se presenta o descarga (si no hay visualización) el contenido del archivo.

 

Se puede ordenar por cualquier columna y se guarda el criterio de orden para la próxima vez que entremos en cualquier directorio.

Los iconos a la derecha del todo, permiten, respectivamente, descargar / visualizar en una ventana independiente.
Al descargar el archivo, cada navegador interpreta el comando de descarga a su modo y para tipos de archivos visualizables como CSV, texto, fotos... , suelen visualizarlo en vez de descargarlo. Al mostrarlo en una pestaña independiente del navegador, si no es visualizable, se descargará.

Los directorios no se pueden descargar.

Clase Usuarios

Base de ejemplo: test-permisos

Representan cada usuario de BD, que permite el acceso a  la misma, con distintos niveles de permisos. Los niveles de permisos también son de clase usu.

Una vez abierta la base con nombre de usuario y contraseña, el acceso a los datos del propio usuario están en el enlace con su nombre de la esquina superior derecha de la página. Los usuarios NO administradores sólo tienen acceso a su usuario, y sólo a la función de cambiar su contraseña, EXCEPTO los usuarios del grupo invitados (g4), que ni siquiera pueden cambiarla.

Cada usuario, al estar asociado a un grupo de permisos, entra en el concepto carpeta que ese grupo de permisos o el propio usuario en particular, tenga definido en el campo Raiz.

Usuarios administradores

En el enlace de su usuario, tienen el panel completo de todos los usuarios que pueden gestionar creando, eliminando y modificando: la contraseña, el grupo de usuarios, el grupo de trabajo asociado, y los que se explican a continuación:

Mantenimiento: Grupo de trabajo

El Grupo de trabajo asociado a un usuario filtra las Tareas que puede ver: sólo las asignadas a ese grupo o las que no tienen asignado grupo de trabajo. 

Grupos de usuarios (perfiles)

IMPORTANTE: el grupo con código 'admin' no tiene ninguna restricción, y se ignoran si se le aplican. No se debe redefinir, existe internamente. Al grupo de expertos g1 TAMPOCO se le pueden aplicar restricciones. El permiso usu=- (dar a algún grupo el permiso sobre gestión de usuarios), no tiene ningún efecto, ya que para gestionar los usuarios debe ser administrador y además le interface siempre muestra el usuario del actual, no ese panel.

Son conceptos de clase usuario que definen características comunes para aplicar a un mismo perfil de usuarios. No tienen contraseña (nadie va a acceder con ellos) y en cambio los usuarios con contraseña apuntan a estos perfiles en el campo Grupo. Lo normal es que también tangan definido campo Raíz, que indica el código de una carpeta de la BD que se mostrará como punto de entrada de la base a todos los usuarios de ese Grupo. En cambio los usuarios de acceso (con clave) no suelen tener carpeta Raíz particular.

También puede haber (aunque no es habitual) varios niveles de grupos de usuarios en los que se heredan de unos a otros las restricciones.

Existen 4 grupos con nombres y restricciones predefinidas, con códigos: g1, g2, g3, g4. Sus permisos se definen más adelante.

 

Grupo comodín de usuarios

Se puede definir un grupo con el código de una clase (por ejemplo usu.entpro para entidades propietarios), para poder utilizar los cientos de conceptos entidad que ya tenemos en BD, de forma que sean los usuarios de acceso con el login.

Lo primero es establecer en el apartado Menú > Configuración > Características> Clase de usuarios, el código de la clase que queremos utilizar. Luego, si definimos un grupo usu.ent, en la clase hay que definir un campo pwd0 (password inicial) y un pwd que sustituirá el campo usu.pwd.

Además se tiene en cuenta el ámbito del propio concepto entidad en este caso, para filtrar todos los conceptos con ese ámbito, como si estuviera definido en usu.amb.

En cada concepto de esa clase hay que introducir la clave inicial, que se copiará también al campo clave. En cuanto un usuario acceda con su nombre de usuario (código de entidad) y esa clave, y la modifique, se eliminará la clave inicial, lo que también nos permite un control de qué usuarios la han cambiado ya.

En la base ingrid-comun hay un procedimiento de ejemplo para poner a cada concepto de una clase un ámbito automático secuencial y a todos sus conceptos relacionados ponerle el mismo, de forma que independicemos el inventario para cada usuario.

 

Restricciones de acceso a clases de BD

En el campo Restricciones, se pueden especificar en formato <codigoClase>= -|D|C|E|L  (Destrucción, Creación, Edición, Lectura) una lista de restricciones (no permisos) separadas por espacios en blanco .
- Hay 3 <código_clase> con un código especial:
  CLA: los conceptos de definición de clases: los de código que comienza con un punto y NO usuarios (.car, .dir, .pro...)
  CON: todos los demás conceptos que no son clases
  USU: sólo los conceptos usuario y grupos de usuarios (.usu)

- El tipo de restricción sólo es una que incluye JERARQUIZADAS las anteriores en cascada, por ejemplo: C restringe o impide la Creación de conceptos de una clase, pero también la Destrucción (eliminar), que es la que está a la izquierda en ese orden. L es el más restrictivo, e impide la Lectura (acceso) y por tanto, cualquier otra operación: Edición (modificación), Creación y Destrucción.

- El guión (-) significa no aplicar ninguna restricción DCEL. Básicamente sirve para anular restricciones ya impuestas o heredadas, por ejemplo: con:E car:- significa permisos completos a carpetas, a pesar de habérselos quitado a todas las clases de conceptos (con).
- El orden importa y se APILA de izquierda a derecha con las restricciones de defecto del grupo más a la izquierda y las del usuario a su derecha, pero se EJECUTAN o EVALÚAN de derecha a izquierda, por lo que:  con:E car:C da permiso de Destrucción a las carpetas, pero car:C con:E no tiene sentido, porque primero quita todos los permisos de modificación a todos los conceptos y ya no se examinan más condiciones. En el campo Restricciones acumuladas (o efectivas) se limpian las condiciones sin sentido para mejorar la legibilidad.
- En las 5 clases generales de organización cla, car, bus, pro, dir, las restricciones tienen algunos matices:
   C impide crear conceptos de esas clases, Y editar sus datos (el camino de los directorios, la consulta de las búsquedas, el código o resumen de las carpetas, el programa javascript o la definición de parámetros de los procedimientos...)
   E impide la ejecución de procedimientos, modificar el contenido de los directorios (insertar, eliminar, renombrar), y editar en columnas los datos de las listas resultado de carpetas y búsquedas
   L impide el acceso completo a esas clases y su información relacionada.

Ejemplo: tra:L bin:E esp:D

que significa:
1º No puede Destruir (borrar) espacios (ni sus subclases, ya que las restricciones de clase se heredan), pero sí Crearlos y Editarlos.
2º No puede Editar bins, ni ninguna de sus subclases, y por tanto, tampoco Crear ni Destruir.
3º No puede Crear ni Destruir grupos de trabajo, ni modificar su nombre, o forma de presentación, sólo visualizar.

El cuadro de grupos predefinidos es:

Cod Nombre        Restricciones acumuladas (predefinidas)
g0 (admin)
g1 (experto)
g2 (jefe)          cla:E car:E bus:E dir:E pro:E
g3 (técnico)       cla:E con:E
g4 (consulta)      cla:E con:E dir:L pro:L

Además:

- Todos los usuarios no administradores tienen la restricción no editable usu:L para que sólo puedan ver el suyo. Dárselo no tiene sentido porque no pueden acceder al panel de usuarios.

- Se aplican unas restricciones básicas de defecto de la aplicación, que son visibles en el campo Restricciones acumuladas), y sirven para no tener que definirlas siempre, pero el administrador (que no tiene) puede cambiarlas.

- No sólo se puede restringir por clases (más las especiales CLA y CON), también con unos campos especiales, para que cierto usuario o grupo no tenga acceso a: Imágenes, Mapas, al botón de edición...

Los grupos admin y experto (g1) tienen características especiales, como que el primero no filtra la búsquedas o que ciertas pestañas están reservadas a cada uno. admin es el gestor del continente de BD: modelo de relaciones, clases, campos... y el experto g1) es el administrador del contenido: búsquedas y reemplazos masivos, acceso a todas las clases...

El resto de usuarios a partir del g2 -incluido-, tienen ocultos: el campo de búsqueda en lenguaje natural, la pestaña de clases y la navegación por la estructura de clases, para que no tengan un acceso global a toda la información de la base.

Permisos por ámbitos

Cada usuario tiene 3 campos para gestionar la compartimentación de la información dentro de una BD: El campo Ámbito, Ámbito inicial y Ámbito final (no incluido).

El ámbito es un número entero que asociado a un usuario, hace que sólo pueda ver los conceptos de BD que tengan ese mismo ámbito y los que no tengan especificado ninguno. También indica qué ámbito se pone a todos los conceptos que crea ese usuario.

El campo de inicial y final, permite establecer un rango para que un usuario pueda ver y editar la información de varios ámbitos.

Ejemplo: si un usuario tiene ámbito nº 100 y otro 101 (habitualmente dos contratas separadas para un servicio), el primero no podrá ni siquiera ver los bienes de inventario, espacios, carpetas, etc. marcado con el ámbito 101, y viceversa. En cambio un usuario sin nº de ámbito, con inicial=100 y final=102 (habitualmente los técnicos del ayuntamiento que han solicitado el servicio), podrá ver y/o editar (en función de sus restricciones), la información de ambos ámbitos, y además los conceptos que cree ese usuario (como avisos, por ejemplo) al no tener ámbito, serán visibles por ambas contratas.

Clase Bajas de conceptos

Esta clase sirve para almacenar en el proyecto los conceptos que queremos tratar como bajas o eliminación de información SIN BORRAR la información de BD, que siempre es conflictiva, sobre todo por las referencia sa ese concepto desde otros conceptos de BD.

Si borramos completamente un registro de cualquier clase al que otros conceptos hacen referencia, esas referencias se quedaría huérfanas, nulas. Para no perder información, se deben recodificar de manera que permanezcan como histórico en la BD pero apartados de las búsquedas habituales.

El prefijo de la clase se coloca delante de cualquier otro de clase. Por ejemplo, bin.001 pasaría al identificador: baja.bin.001 manteniendo toda su información y además mostrándola con el formato de página como si la clase fuese bin. La ventaja es que abriendo la ficha podemos ver incluso al georreferencia, pero si hacemos un mapa de bins no saldrá, ya que ahora es de otra clase.

La gestión de bajas se realiza desde el menú contextual de cualquier descomposición de carpeta, con la opción Dar de baja tras seleccionar la línea. Al cambiarlo de clase, cambia el identificador en todas sus referencias en otros conceptos, igual que cualquier otra recodificación. Un concepto dado de baja puede darse de alta de nuevo, recuperando su formato de clase, quitándole el prefijo "baja."

Los conceptos de baja tienen un campo fecbaja con la fecha y hora en que se realizó el cambio de clase, y que permite hacer búsquedas.

Extender las clases existentes

Las clases, que son los módulos de información básicos del modelo de datos de Ingrid, se pueden ampliar incluyendo archivos de código Javascript en la página de inicio de la aplicación (index.htm), en el mismo sitio donde se incluye la librería con toda la definición de clases estándar de Ingrid.

Un archivo fuente de definición de clases, se debe llamar Ingrid.abc.js siendo abc 3 letras minúsculas correspondientes al código de clase en la aplicación. Cada modulo puede incluir:

- Los Campos requeridos en la clase (no definidos en BD, sino fijados en el código de funcionalidad de la clase).

- Controles específicos, puede incluir las piezas de funcionalidad que se incluyen de forma estándar en los conceptos (persiana de imágenes, de mapa, de listas de relaciones, visores...)

- Eventos que actúen en tiempo real sobre campos de nuestra clase.

- Documentación de ayuda en línea de uso de los controles o descripción de la funcionalidad de la clase:

Por ejemplo, el campo de Frecuencia de las Operaciones, está definido como:

{cod:'profre', abr:'Frecuencias', res:'Programación de frecuencias', tip:'t1', ayuda:'1', fijo:1},

con lo que abre la página de esa clase (Ingrid.ope.htm) saltando al marcador con el nombre del campo: PROFRE.

Se puede definir un botón para una persiana como la de medidas de operaciones, que salte a una página y un marcador, como:

contenedor.botonAyuda("clase.ope#medidas");

Los códigos de clases no deben coincidir con ninguna de las estándar de Ingrid, claro. Se puede ver cuáles son en la pestaña que muestra las de la base ingrid-comun: Base > Clases comunes

En el código html de la página de inicio de la aplicación, tiene que contener algo como:

Las 3 primeras líneas ya existen en la página de inicio de la aplicación, y hacen referencia a las librerías generales de la aplicación en los servidores de Ingra. La siguiente, apuntaría a nuestro nuevo archivo fuente con una url absoluta, que incluirá los campos del modelo de datos de esa clase, las funciones que se ejecutarán, eventos...