98 lines
5.3 KiB
Markdown
98 lines
5.3 KiB
Markdown
# DH Inspección Android · release final de campo 0.19.0
|
|
|
|
## Candidata vigente
|
|
|
|
- Fase funcional: **Flujo final de campo · Inspección → Acta → Hallazgos → Firma**.
|
|
- `versionName`: **0.19.0**.
|
|
- `versionCode`: **28**.
|
|
- Application ID release: `com.korexlabs.dhinspeccion`.
|
|
- Application ID debug/QA: `com.korexlabs.dhinspeccion.debug`.
|
|
- API: `https://dhv2.korexlabs.com/api/v3/`.
|
|
|
|
La variante debug es independiente de la app productiva y puede instalarse para QA/presentación sin sobrescribir una instalación release histórica.
|
|
|
|
## Procedimiento operativo validado
|
|
|
|
La APK 0.19.0 fija como recorrido principal de campo:
|
|
|
|
1. **Iniciar Inspección**. Al iniciarla se habilitan Actas, Hallazgos e Inventario de campo.
|
|
2. **Crear o abrir un Acta**. Puede haber varias Actas dentro de una misma Inspección, pero sólo una puede permanecer en elaboración al mismo tiempo.
|
|
3. **Agregar Hallazgos** sobre una Instalación o Subinstalación seleccionada.
|
|
4. Si el elemento ya existe, se lo selecciona desde el Inventario del Área/Yacimiento de la Inspección.
|
|
5. Si no existe, se da de alta desde campo sin abandonar el Acta.
|
|
6. Un elemento nuevo debe completar **GPS + fotografía** antes de poder recibir Hallazgos.
|
|
7. Al terminar el contenido del Acta se usa **Cerrar Acta y dejar pendiente de firma**. Desde ese momento el contenido queda inmutable y el estado visible es **Pendiente de firma**.
|
|
8. La firma del Inspector y la manifestación/firma o negativa de la empresa completan el Acta, que pasa a **Firmada y cerrada**.
|
|
9. La Inspección sólo puede cerrarse cuando todas sus Actas no canceladas están firmadas y cerradas.
|
|
|
|
La nomenclatura técnica interna de API (`DRAFT`, `LOCKED`, `SEALED`, etc.) no se muestra al inspector: la interfaz usa textos operativos en castellano.
|
|
|
|
## Alta de Instalaciones y Subinstalaciones
|
|
|
|
El alta móvil queda alineada con el Dashboard y con las validaciones del servidor.
|
|
|
|
### Instalación
|
|
|
|
- contexto territorial: Yacimiento/Área de la Inspección;
|
|
- clasificación técnica compatible;
|
|
- **Nombre técnico** obligatorio;
|
|
- Nombre habitual opcional;
|
|
- Descripción opcional;
|
|
- atributos técnicos definidos por el tipo; sólo los marcados como obligatorios bloquean el guardado;
|
|
- código DH generado por el sistema cuando corresponde;
|
|
- GPS de la tablet;
|
|
- fotografía obligatoria antes de crear Hallazgos.
|
|
|
|
### Subinstalación
|
|
|
|
Además de lo anterior requiere elegir primero la **Instalación padre**. El buscador consulta mientras se escribe y cada resultado es seleccionable tocando la tarjeta.
|
|
|
|
La clasificación y los atributos se obtienen dinámicamente desde el mismo catálogo administrado por el Dashboard; la APK no mantiene listas técnicas paralelas.
|
|
|
|
## Actas y firma
|
|
|
|
La terminología visible se simplifica:
|
|
|
|
- `DRAFT` → **En elaboración**;
|
|
- `LOCKED` → **Pendiente de firma**;
|
|
- `SEALED` → **Firmada y cerrada**.
|
|
|
|
Cerrar el contenido no cierra automáticamente la Inspección y tampoco obliga a terminar la firma en ese instante: puede continuarse con otra Acta. Una vez cerrado el contenido, el Acta es inmutable.
|
|
|
|
Después de la firma/cierre definitivo se mantiene el circuito documental existente: PDF del Acta e informe INF editable (DOCX) para oficina.
|
|
|
|
## Castellano e identidad visual
|
|
|
|
Se revisaron las pantallas activas de campo para evitar exponer estados y opciones internas en inglés. Entre otros cambios: Pasaporte/Otro en documentos, estados de Inspección/Acta/Hallazgo en castellano, Correo electrónico, Huella de integridad y terminología de cierre orientada al usuario.
|
|
|
|
La pantalla de ingreso y el desbloqueo biométrico utilizan la identidad visual de Mendoza ya incorporada al proyecto.
|
|
|
|
## Barrera obligatoria
|
|
|
|
Todo cambio Android o de API que pueda afectar al cliente móvil debe pasar `Android CI / RC`:
|
|
|
|
1. validación de identidad, HTTPS y políticas básicas del manifest;
|
|
2. Android lint;
|
|
3. pruebas unitarias Android reales, con verificación de que exista al menos una prueba ejecutada;
|
|
4. `assembleDebug`;
|
|
5. `assembleRelease` para comprobar que la variante productiva compile;
|
|
6. empaquetado del APK debug con SHA-256 y metadata de commit/versionado.
|
|
|
|
Además, `DH V2 CI` debe mantener verdes API, WEB y contrato Docker/migraciones antes de promover cambios que afecten al servidor.
|
|
|
|
## Firma release
|
|
|
|
La clave histórica de firma **no se versiona ni se reemplaza**. La CI compila la variante release para detectar roturas, pero una APK productiva que deba actualizar `com.korexlabs.dhinspeccion` tiene que firmarse con la clave histórica.
|
|
|
|
No se debe crear una clave nueva para resolver una falta de acceso: eso rompería la continuidad de actualización de tablets que ya tengan una versión firmada con la clave anterior.
|
|
|
|
## Criterio de distribución
|
|
|
|
Antes de distribuir una APK productiva:
|
|
|
|
- todas las barreras de CI del SHA exacto deben estar verdes;
|
|
- comprobar certificado/huella de firma contra la versión histórica si se distribuirá como actualización productiva;
|
|
- realizar actualización sobre al menos una tablet con la versión productiva anterior cuando corresponda;
|
|
- ejecutar smoke funcional: ingreso, iniciar Inspección, crear Acta, seleccionar/crear Instalación o Subinstalación, GPS/foto, Hallazgo, cerrar Acta → Pendiente de firma, firma/manifestación, cierre de Acta y cierre de Inspección;
|
|
- registrar el SHA Git y SHA-256 de la APK distribuida.
|