Skip to content

GitLab

Open
Created by Juan Jose Lopez@jjlopezMaintainer2 of 13 tasks completed2/13 tasks
Report abuse

Hacer opcionales fases del proceso desatendido en modo Debug

🎯 Summary

Para realizar un proceso desatendido, hay que ejecutar inevitablemente todo el proceso desatendido, que en el caso más largo implica:

  • Escanear el anverso de un documento.
  • Hacer un video de detección de hologramas de un documento.
  • Escanear el anverso de un documento.
  • Leer un OTP.
  • Hacer la detección facial.
  • Hacer el liveness.
  • Hacer un movimiento aleatorio.

Este proceso es bastante largo, principalmente para hacer pruebas durante el desarrollo para una de las últimas fases del proceso (por ejemplo, en MOBBSCAN-5961 para añadir el movimiento aleatorio).

Analizar si sería viable, en modo Debug / Desarrollo, hacer opcionales ciertas fases localmente.

  • No tiene sentido que el backend tenga que soportar un modo de uso que no se va a ofertar a los clientes, así que podríamos simular esto nosotros mandando automáticamente un espécimen en las fases que se quieran saltar.

🤔 Type

  • ✨ New feature
  • 🐛 Bug fix
  • 👷 Technical debt
  • ☢️ Breaking change (it breaks backward compatibility)
  • 📚 Requires a change in the docs

⚙️ Configuration

Workspace branch: [feature/MOBBSCAN-6079]

Related MRs:

⚗️ Solution

Añadido un botón de "Saltar" / "Skip" en la parte superior derecha del vista por defecto del proceso desatendido. Este botón solo se muestra en modo Debug, y al pulsarlo, pasa a la siguiente fase del proceso.

🔬 Tests

  • Comprobar que el proyecto compila en Debug.
  • Comprobar que se muestra el botón de "Saltar" / "Skip" al iniciar el proceso desatendido.
  • Comprobar que se pueden saltar todas las fases del proceso desatendido.
  • Comprobar que el proyecto compila en Release.
  • Comprobar que no se muestra el botón de "Saltar" / "Skip" al usar la versión MobbScan_UnattendedPlugin compilada para Release.

🧐 Checklist:

  • The code follow the project guidelines.
  • The changes have been tested locally.
  • The code has internal docs.
  • Docs are updated (README, public docs, etc.)
  • Some tests have been added to check that the changes work as expected (unit, integration or e2e tests ...)
  • Unit tests are running without errors.
  • Other dependant changes have already been merged.
  • Changelog updated (if it applies)
Edited by Juan Jose Lopez