85 lines
5.5 KiB
Markdown
85 lines
5.5 KiB
Markdown
# DH Inspección Android · release de campo 0.19.0
|
|
|
|
## Candidata vigente
|
|
|
|
- Fase funcional: **Campo final / Inspección → Acta → Inventario → 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 de campo validado
|
|
|
|
1. La inspección se **planifica y asigna desde el tablero web**. La APK no crea inspecciones nuevas.
|
|
2. En la tablet el inspector abre una inspección asignada y, al llegar al lugar, pulsa **Iniciar inspección**.
|
|
3. Con la inspección en curso se crea o selecciona el **Acta** de trabajo. Sólo puede existir un Acta en borrador a la vez; una inspección puede contener varias Actas sucesivas.
|
|
4. Los **Hallazgos** se registran exclusivamente sobre **Instalaciones o Subinstalaciones**.
|
|
5. Si el elemento ya existe, se busca y selecciona desde Inventario de campo.
|
|
6. Si no existe, se da de alta desde la APK siguiendo la misma estructura que el tablero:
|
|
- Instalación dentro del Yacimiento de la inspección;
|
|
- Subinstalación dentro de una Instalación seleccionada;
|
|
- nombre técnico / identificación obligatorio;
|
|
- Código DH de campo autogenerado por el servidor;
|
|
- nombre habitual opcional;
|
|
- descripción y observaciones de alta opcionales;
|
|
- clasificación técnica obligatoria cuando el tipo la requiera;
|
|
- atributos técnicos dinámicos obligatorios según la configuración del tipo;
|
|
- Área y Operadora heredadas de la inspección planificada;
|
|
- ubicación del dispositivo y fotografía obligatorias antes de habilitar Hallazgos.
|
|
7. Sobre el elemento se selecciona un Hallazgo del catálogo contextual o **OTROS** cuando corresponda; se registra descripción, gravedad y evidencia fotográfica si aplica.
|
|
8. Al terminar el contenido se pulsa **Cerrar Acta y dejar pendiente de firma**. El contenido y los Hallazgos quedan inmutables y el estado visible pasa a **Pendiente de firma**.
|
|
9. Se registran las firmas y la manifestación de la empresa. La ausencia por sí sola no modifica el contenido cerrado: el Acta permanece pendiente hasta resolver el circuito de firma/manifestación conforme a la regla vigente.
|
|
10. Una vez resuelta la firma, el Acta queda **Firmada e inmutable**. La inspección sólo puede cerrarse cuando todas sus Actas no canceladas estén finalizadas.
|
|
|
|
## Castellano y presentación
|
|
|
|
La navegación operativa de la APK se presenta en castellano. Los valores técnicos que la API conserva internamente (`DRAFT`, `LOCKED`, `SEALED`, `PLANNED`, etc.) no se muestran al inspector; se traducen a **Borrador**, **Pendiente de firma**, **Firmada**, **Planificada**, **En curso**, etc.
|
|
|
|
También se incorporó la marca oficial de Mendoza provista para esta release en las pantallas de acceso y desbloqueo biométrico.
|
|
|
|
## Integridad del alta de Inventario
|
|
|
|
El alta móvil no duplica los formularios administrativos del tablero. Conserva los datos necesarios para que el registro tenga identidad y trazabilidad en campo, mientras que los datos administrativos que ya vienen determinados por la inspección (Área y Operadora) se heredan automáticamente.
|
|
|
|
El servidor continúa siendo la autoridad para:
|
|
|
|
- generar el Código DH `CAM-*` cuando el alta nace en campo;
|
|
- validar la jerarquía Yacimiento → Instalación → Subinstalación;
|
|
- exigir la familia/clasificación técnica compatible;
|
|
- validar atributos dinámicos configurados en el tablero;
|
|
- registrar ubicación de creación;
|
|
- impedir crear Hallazgos sobre un alta de campo que todavía no tenga ubicación y fotografía;
|
|
- conservar la trazabilidad si el alta provisional se fusiona posteriormente con un registro existente.
|
|
|
|
## 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. unit tests Android reales, incluyendo contratos del procedimiento final;
|
|
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 incorporar la release a `main`.
|
|
|
|
## Firma release
|
|
|
|
La clave histórica de firma **no se versiona ni se reemplaza**. La CI compila la variante release para detectar roturas, pero la APK productiva final debe firmarse con la clave histórica antes de instalarse como actualización de `com.korexlabs.dhinspeccion`.
|
|
|
|
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;
|
|
- realizar actualización sobre al menos una tablet con la versión productiva anterior;
|
|
- ejecutar smoke funcional contra producción: ingreso, abrir inspección asignada, iniciar inspección, crear Acta, buscar Instalación/Subinstalación, alta de campo, ubicación/foto, Hallazgo, cerrar Acta a pendiente de firma, firma/finalización y cierre de inspección;
|
|
- registrar el SHA Git y SHA-256 de la APK distribuida.
|