Auditoria previa y final

Esta guia describe el bloque vigente de v3.0 para auditoria de candidatos y auditoria final de resultados. El contenido fue contrastado contra la UI administrativa de auditores y pre-reportes, las paginas tokenizadas /token/audit*, el dashboard interno de revision /review, el dominio Auditor/AuditorCandidateDecision y la logica EJB que persiste decisiones, notifica y habilita revision.

Ubicacion en el flujo

  • La gestion administrativa de auditores vive en /admin/election/auditors y la edicion puntual en /admin/election/auditors/edit.
  • El seguimiento interno previo usa tambien /admin/election/pre-reports, donde existe una matriz de verificaciones por nominacion/candidato y por auditor.
  • La experiencia tokenizada del auditor se divide en tres paginas: /token/audit (dashboard), /token/audit/candidate (detalle del candidato) y /token/audit/result (auditoria final de resultados).
  • La revision interna de votos para administracion usa /review y depende del switch de eleccion revisionRequest mas la habilitacion explicita de todos los auditores comisionados.

Actores y modelo operativo

  • El sistema distingue entre auditor y auditor comisionado. Ambos pueden existir en la eleccion, pero las decisiones tokenizadas de auditoria las cargan solo los comisionados.
  • Cada auditor guarda name, mail, reminderFrequency, flag commissioner, flag agreedConformity, flag revisionAvailable y un resultToken propio.
  • Las decisiones por candidato viven en AuditorCandidateDecision y hoy se separan en dos etapas: PRE_VERIFICATION y FINAL_VERIFICATION.
  • El modelo sigue manteniendo columnas legacy (decisionStatus, decisionDate, preapprovedDate, approvedDate) para compatibilidad, pero la operativa nueva consume primero los campos separados de predecision y decision final.

Alta y mantenimiento de auditores

  • La pantalla administrativa de auditores solo opera sobre elecciones abiertas. Si la eleccion ya esta cerrada, el dashboard redirige a error de eleccion cerrada.
  • El alta exige nombre, email valido y frecuencia de recordatorio. El checkbox Commissioner define si ese auditor podra decidir y confirmar revision/conformidad.
  • La validacion remota bloquea duplicados de auditor para la eleccion actual.
  • El listado administrativo muestra nombre, email, si es comisionado, si ya dio conformidad final y un resumen de cantidad de verificaciones previas/finales cargadas por cada comisionado.
  • Desde esa lista se puede abrir el link tokenizado del auditor, editarlo, eliminarlo y enviar recordatorio manual. El boton de recordatorio solo se expone para auditores comisionados.
  • Marcar como terminada y seguir persiste auditorsSet=true. Skip y Back vuelven a los modulos previos sin marcar completitud.

Seguimiento interno previo

  • El pre-reporte administrativo incluye una matriz de auditoria por nominacion/candidato y por auditor.
  • Cada auditor se desdobla en dos columnas: 1ra verificacion y Final.
  • La matriz muestra estado y fecha cuando existe; si no hay reaccion, deja Sin primera verificacion o Sin verificacion final.
  • El armado de esa matriz ya contempla compatibilidad hacia atras: si una decision vieja no tiene el split nuevo, intenta reconstruir la etapa correcta desde decisionStatus y las fechas milestone heredadas.
  • En el mismo pre-reporte tambien se expone el estado operativo del link /token/audit/result segun la bandera manual de auditoria y el calendario N_18_PERIODO_CE_AUDIT.

Acceso tokenizado a auditoria de candidatos

  • El acceso del auditor se valida con resultToken. Si el token no corresponde a un auditor valido, la pagina responde 404.
  • El dashboard /token/audit requiere ademas que la eleccion tenga auditorLinkAvailable=true.
  • La auditoria de candidatos queda habilitada desde N_1_SINGLE_CALL_FOR_CANDIDATES_PUBLISHED en adelante, sin fecha de cierre propia.
  • Las fichas de candidato visibles para auditoria tokenizada se limitan a candidatos en PRECOMPLETE, COMPLETE, CONFIRMED_AND_PUBLISHED o REJECTED.
  • El dashboard decide la accion principal segun estado y reaccion previa del auditor actual: primera verificacion para PRECOMPLETE sin reaccion previa, verificacion final para COMPLETE sin reaccion final, o solo ver detalle en el resto de los casos.

Que ve el auditor al revisar un candidato

  • La pagina /token/audit/candidate muestra datos de nominacion, resumen de tareas y tarjetas de completitud para perfil, paises, incompatibilidades, declaraciones, preguntas estatutarias/no estatutarias, apoyos, organizaciones, training y evaluacion.
  • Ese detalle ya consume directamente las respuestas y declaraciones documentadas en la guia anterior, por lo que la auditoria usa informacion real del checklist del candidato y no una vista paralela inventada.
  • Las decisiones solo pueden cargarlas auditores comisionados. Un auditor no comisionado puede entrar con token, pero no obtiene formularios editables para decidir.
  • Los comentarios de auditoria son opcionales, usan asistencia de IA en la UI y el backend los sanea/normaliza con limite efectivo de 4000 caracteres.

Decision previa y decision final

  • La decision previa aplica cuando el candidato esta en PRECOMPLETE. Las unicas opciones validas son PREAPPROVED y REJECTED.
  • La decision final aplica cuando el candidato esta en COMPLETE. Las unicas opciones validas son APPROVED y REJECTED.
  • El backend deriva automaticamente la etapa desde el estado actual del candidato cuando la decision entra por la pagina tokenizada. No acepta usar estados fuera de etapa.
  • La ventana operativa de decision previa/final es la union de N_7_PERIODO_CANDIDATE_FORMS_VERIFICATION y N_8_PERIODO_EVALUATIONS_VALIDATION.
  • La UI muestra como fecha limite de primera reaccion el fin de N_7 (o N_6 como fallback si falta ese fin) y como fecha limite final el maximo entre los cierres de N_7 y N_8.
  • Si el candidato ya quedo en CONFIRMED_AND_PUBLISHED o REJECTED, la tarjeta de decision final puede seguir visible para consulta, pero deja de ser editable.
  • Cuando la decision entra por token y no existia fila previa para ese auditor/candidato, el backend crea el registro faltante.
  • Una decision tokenizada REJECTED o APPROVED dispara correo al remitente de la eleccion; PREAPPROVED no dispara ese correo de aprobacion.

Edicion administrativa de decisiones

  • La edicion administrativa del auditor agrega una tarjeta de auditor decisions solo para comisionados.
  • Esa pantalla permite corregir manualmente estados y comentarios por candidato, pero solo sobre etapas que ya tengan decision existente. No crea filas nuevas de decision.
  • La edicion administrativa respeta las mismas combinaciones validas por etapa: PREAPPROVED/REJECTED para pre-verificacion y APPROVED/REJECTED para verificacion final.
  • Ese ajuste manual es mas quirurgico que la carga tokenizada: actualiza el estado de etapa seleccionado, pero no notifica al remitente de la eleccion.

Auditoria final de resultados

  • La pagina /token/audit/result usa el mismo resultToken, pero su acceso esta restringido a la ventana N_18_PERIODO_CE_AUDIT.
  • Si N_18 todavia no empezo, si ya termino o si auditorLinkAvailable=false, el acceso queda bloqueado.
  • Cuando la revision interna no fue solicitada, la pagina final muestra tres bloques: resultados publicos, codigos de candidatos e informacion adicional para auditoria.
  • La informacion adicional expone el maximo de votos posibles y el detalle agregado de porcentajes, habilitados, participantes, peso y total por fila de resultados.
  • Solo un auditor comisionado que todavia no haya confirmado conformidad ve el panel de Agree Conformity. Al confirmar, el sistema marca agreedConformity=true y encola el template AUDITOR_AGREEMENT.

Solicitud de revision y acceso interno a votos

  • La eleccion puede habilitar administrativamente revisionRequest desde configuracion. Ese switch no abre por si solo la revision: solo habilita el circuito para que los comisionados la autoricen.
  • Cuando revisionRequest=true, el dashboard tokenizado del auditor muestra un panel para habilitar revision si el auditor es comisionado y todavia no la autorizo.
  • Al confirmar esa accion, el sistema marca revisionAvailable=true, encola el template AUDITOR_REVISION y registra actividad ELECTION_REVISION_YES.
  • Con revisionRequest=true, la pagina /token/audit/result deja de mostrar el bloque normal de resultados/conformidad y el proceso pasa al dashboard interno /review.
  • El link administrativo a /review aparece cuando la eleccion tiene revisionRequest=true, pero la tabla de votos solo se habilita cuando todos los auditores comisionados tienen revisionAvailable=true.
  • Si todavia falta algun comisionado, /review muestra el listado de auditores y avisa Faltan auditores por permitir acceso a esta seccion, sin exponer el detalle de votos.
  • Cuando la revision queda activa, /review expone el listado completo de votos con identificadores de voto, candidato, codigo, fecha, IP y, cuando existe, el detalle del UserVoter asociado.

Recordatorios y trazabilidad

  • Cada auditor guarda reminderFrequency, que se usa en el encabezado tokenizado y en la infraestructura de recordatorios.
  • Administracion puede enviar un recordatorio manual a un auditor comisionado; la accion encola un mail AUDITOR_REMINDER y deja actividad administrativa.
  • Las altas, ediciones, bajas, recordatorios, decisiones y habilitaciones de revision dejan trazas en actividad, por lo que el flujo no depende solo del estado visible en UI.

Bloques relacionados

  • Candidaturas y nominaciones: el flujo base de estados del candidato esta documentado en esta guia.
  • Preguntas, declaraciones y comunidad: el contenido que luego consumen las tarjetas de auditoria del candidato esta documentado en esta guia.
  • Votacion y links publicos: la experiencia publica y los links tokenizados que siguen despues de auditoria y revision estan documentados en esta guia.

Fuentes contrastadas

ElectionAuditorsDashboard, AddAuditorPanel, AuditorsListPanel, EditAuditorDashboard, PreElectionReportsPanel, AuditPublicDashboardPage, AuditPublicCandidateDetailPage, AuditPublicResultsPage, AuditorRevisionPanel, AuditorConformityPanel, MoreInformationForAuditPanel, ReviewDashboard, ReviewAuditorsListPanel, ReviewVotesListPanel, AuditorValidator, Auditor, AuditorCandidateDecision, AuditorCandidateDecisionStatus, AuditorCandidateDecisionStage, ElectionsManagerEJBBean, ElectionsVoterEJBBean, MailsSendingEJBBean y ElectionsManagerApp.properties.xml.