Candidaturas, nominaciones y apoyos

Esta guia describe el bloque vigente de candidaturas en v3.0: alta manual desde admin, nominacion desde organizaciones, aceptacion o rechazo por la persona nominada, flujo de apoyos y publicacion final de candidaturas. El contenido fue contrastado contra la UI administrativa y publica, el dominio Candidate/Nomination/SupportNomination, la logica EJB y las restricciones reales del flujo tokenizado.

Ubicacion en el flujo

  • La pantalla administrativa de candidatos esta montada en /admin/election/candidates.
  • En el wizard de gestion vuelve a Tareas y continua hacia Auditores.
  • El flujo publico asociado usa tres familias de links: /token/organization/do-nomination para nominar, una pantalla de condiciones/aceptacion resuelta por acceptNominationToken junto con /token/nomination/tasks para completar la candidatura, y /token/nomination/support para responder apoyos.
  • Si la eleccion esta cerrada, la UI administrativa deriva a Eleccion cerrada y no permite edicion.

Modelo operativo del bloque

  • Una Nomination pertenece a una eleccion y a una organizacion. Puede o no tener un Candidate asociado. Cuando la persona nominada acepta, el backend crea ese candidato y lo vincula en relacion uno a uno.
  • Los apoyos se modelan como SupportNomination asociados a una nominacion. Pueden venir de otra organizacion o de un contacto manual sin organizacion asociada.
  • El sistema maneja dos tipos de candidato: NORMAL y ABSTENTION. La abstencion no nace desde una nominacion: se agrega manualmente desde admin.
  • Los estados de nominacion que hoy existen en el modelo son PROPOSED, ACCEPTED_BY_CANDIDATE, REJECTED_BY_CANDIDATE, INVALID y APPROVED. El flujo publico actual genera directamente PROPOSED, ACCEPTED_BY_CANDIDATE y REJECTED_BY_CANDIDATE; INVALID y APPROVED quedan para tratamientos posteriores del proceso.
  • Los estados de apoyo son PROPOSED, ACCEPTED, REJECTED, APPROVED e INVALID. La pagina publica de apoyo solo permite decidir ACCEPTED o REJECTED.
  • Los estados de candidato son INCOMPLETE, PRECOMPLETE, COMPLETE, CONFIRMED_AND_PUBLISHED y REJECTED. La pantalla administrativa de estado expone todos los enums y el backend no valida transiciones de negocio entre estados: acepta cualquier cambio directo mientras el valor nuevo sea distinto del actual.
  • Solo los candidatos en CONFIRMED_AND_PUBLISHED entran en la boleta publica y en los listados publicos de candidatos. La opcion de abstencion creada desde admin nace directamente en ese estado.

Alta manual y edicion administrativa

  • El alta manual inline permite cargar Nombre, Email, Frecuencia de recordatorio, Biografia en espanol, Link publico en espanol, LinkedIn y Foto.
  • Nombre es obligatorio y tiene maximo de 255 caracteres. Email es obligatorio para candidatos normales y valida formato. Frecuencia de recordatorio tambien es obligatoria para candidatos normales.
  • Biografia en espanol es obligatoria, admite hasta 2000 caracteres y pasa por LinkValidator. Link publico y LinkedIn son opcionales, con validacion de URL y maximo de 1000 caracteres.
  • En alta manual, si no se adjunta foto, el backend asigna la foto default del sistema. En edicion existe ademas la opcion Restaurar foto default.
  • Los candidatos agregados manualmente quedan con tipo NORMAL, toman el siguiente orden no fijo disponible y reciben filas de progreso NOT_STARTED para todas las tareas hoy configuradas en la eleccion.
  • La UI inline fuerza onlySp=true al crear un candidato manual nuevo. Ademas, cada guardado del formulario inline ejecuta copyBioToOtherLanguages(): replica siempre bioSpanish y linkSpanish hacia EN/PT y tambien copia respuestas abiertas desde espanol. Si ya existian traducciones diferenciadas, quedan sobrescritas y deben corregirse luego desde Traducciones.
  • La pantalla historica /admin/election/candidates/edit sigue montada, pero hoy la operacion normal del modulo se hace desde el formulario inline del dashboard principal.

Opcion de abstencion y orden de candidatos

  • Desde la cabecera del modulo puede agregarse una unica opcion de abstencion. Si ya existe, el boton desaparece.
  • La abstencion se crea con nombre trilingue fijo, bio default configurable por parametro, foto default especifica, ReminderFrequency.DISABLED y estado CONFIRMED_AND_PUBLISHED.
  • Al crearse, la abstencion toma candidateOrder = MAX_ORDER. Si ya habia un primer candidato fijo, el backend lo mueve al ultimo orden no fijo para dejar a la abstencion arriba.
  • La cabecera tambien permite activar randomOrderCandidates. Ese switch afecta la presentacion final de candidaturas publicadas; no elimina los ordenes persistidos ni las posiciones fijas.
  • En modo no aleatorio, cada candidato normal puede moverse arriba/abajo, fijarse primero, fijarse ultimo o volver al bloque no fijo. Las posiciones fijas usan internamente MAX_ORDER y MIN_ORDER.
  • La lista administrativa siempre muestra la posicion resultante segun el estado actual: Fijo primero, Fijo ultimo, Aleatorio o la posicion secuencial visible.

Nominacion desde organizaciones

  • La nominacion desde organizaciones se hace con el token doNominationToken de cada organizacion, usando la pagina /token/organization/do-nomination.
  • El acceso real requiere dos condiciones simultaneas: que el switch manual doNominationLinkAvailable este habilitado y que la eleccion este dentro de la ventana de calendario N_2_PERIODO_CALL_FOR_CANDIDATES.
  • La organizacion no puede volver a nominar mientras tenga alguna nominacion propia en estado PROPOSED, ACCEPTED_BY_CANDIDATE o APPROVED. Si la nominacion previa fue rechazada por la persona nominada o quedo invalida, el sistema vuelve a permitir una nueva nominacion.
  • El formulario exige Nombre completo, Email, Codigo de pais del telefono, Telefono y Motivo. El nombre requiere al menos 3 caracteres y valida un patron de nombre completo; el motivo exige entre 20 y 2000 caracteres.
  • La UI normaliza espacios y arma el telefono como <codigoPais> <telefono>. El backend vuelve a validar largos y formato minimo antes de persistir.
  • Al guardar, el backend crea la nominacion en estado PROPOSED, genera acceptNominationToken y encola el email de nominacion para la persona nominada.
  • Si la eleccion tiene paises restringidos configurados, la pagina de nominacion los muestra en un modal informativo antes de completar el envio.

Aceptacion o rechazo por la persona nominada

  • La aceptacion se inicia con el acceptNominationToken de la nominacion. Si la nominacion ya fue aceptada, la pantalla de condiciones redirige automaticamente al panel de tareas.
  • La aceptacion solo se permite cuando la nominacion sigue en PROPOSED, el switch manual nominationTasksLinkAvailable esta habilitado y la eleccion continua dentro de N_2_PERIODO_CALL_FOR_CANDIDATES.
  • Ademas, el backend bloquea la aceptacion si ya existe otra nominacion de la misma eleccion en estado ACCEPTED_BY_CANDIDATE para el mismo email normalizado.
  • Cuando la aceptacion prospera, el sistema crea un candidato nuevo con nombre y email tomados de la nominacion, onlySp=true, foto default, estado INCOMPLETE, estados de capacitacion/evaluacion en PENDING y el siguiente orden no fijo disponible.
  • En ese mismo paso se generan filas de progreso NOT_STARTED para todas las tareas hoy configuradas en la eleccion y la nominacion pasa a ACCEPTED_BY_CANDIDATE.
  • Si la persona nominada rechaza, la nominacion pasa a REJECTED_BY_CANDIDATE. Ademas, cualquier apoyo todavia pendiente en estado PROPOSED se fuerza a REJECTED.

Tareas de candidatura y apoyos

La pagina /token/nomination/tasks solo existe para nominaciones aceptadas. El detalle de preguntas, declaraciones y preguntas de comunidad ya quedo separado en esta guia; aqui se mantienen las reglas operativas generales del bloque de apoyos y acceso.

  • El acceso a tareas requiere nominacion aceptada y respeta tanto el switch manual nominationTasksLinkAvailable como las ventanas de calendario asociadas. Cuando una tarea ya vencio o tiene dependencias previas pendientes, la pagina la deja solo en los modos permitidos por su estado real.
  • Las tareas Capacitacion y Evaluacion tambien sincronizan estados operativos del candidato: al marcarse STARTED o COMPLETED pueden mover campusCourseStatus y evaluationStatus.
  • El bloque de preguntas a candidatos de comunidad se muestra solo dentro de N_12_PERIODO_CANDIDATE_QUESTIONS.
  • Los apoyos de organizaciones solo pueden pedirse para organizaciones de la misma eleccion, con membershipContactEmail cargado, distintas de la organizacion que nomino y cuyo email de contacto no coincida con el email del candidato.
  • Ademas, una organizacion no puede volver a ser pedida dos veces para la misma nominacion ni puede haber otorgado ya apoyo a otra nominacion de esa misma eleccion. El sistema admite como maximo 2 apoyos activos de organizacion por nominacion, contando PROPOSED, ACCEPTED y APPROVED.
  • Los apoyos por contacto manual solo aplican a las tareas USER_SUPPORTS_2 y USER_SUPPORTS_5. El contacto no puede ser el propio email del candidato ni repetirse dentro de la misma nominacion.
  • Si la eleccion tiene authorizedNominateEmails configurado, el formulario de nominacion solo acepta correos de candidato incluidos en esa lista. Si la lista esta vacia, no se aplica esa restriccion adicional.
  • Si la eleccion tiene authorizedSupportEmails configurado, la UI del candidato solo permite cargar contactos manuales incluidos en esa lista. Si la lista esta vacia, no se aplica esa restriccion adicional.
  • El sistema no deja solicitar mas apoyos manuales de los requeridos por la tarea. Para ese conteo considera activos los estados PROPOSED, ACCEPTED y APPROVED.
  • La pagina publica de apoyo permite aceptar o rechazar. Al responder, encola un email informando el cambio al candidato.
  • Cuando una nominacion alcanza 2 apoyos de usuario aceptados/aprobados, el backend intenta completar automaticamente la tarea USER_SUPPORTS_2. Cuando alcanza 5, hace lo mismo con USER_SUPPORTS_5. Para apoyos de organizacion, la tarea ORG_SUPPORTS se completa automaticamente al llegar a 2 apoyos aceptados/aprobados.

Gestion administrativa posterior

  • La lista administrativa muestra para cada candidato foto, resumen de nominacion vinculada, nombre, id, email, biografia, link publico visible, LinkedIn, estado de Campus y estado de candidatura.
  • Si el candidato no tiene linkSpanish, la UI muestra como fallback el perfil publico del candidato construido con publicElectionToken y action=candidate.
  • La accion Estado permite cambiar el estado del candidato, agregar comentario y guardar con o sin envio del correo CANDIDATE_CONFIRMED_AND_PUBLISHED cuando se pasa a CONFIRMED_AND_PUBLISHED.
  • La advertencia sobre aprobacion de auditores en esa pantalla es solo informativa: si no todos los commissioners aprobaron, la UI muestra el resumen, pero el backend igual acepta el cambio de estado.
  • La accion Capacitacion permite editar campusCourseStatus, evaluationStatus, calificacion y archivo Proctorio. Si el admin deja capacitacion o evaluacion en COMPLETED o NOT_APPLICABLE, la pantalla intenta marcar como completada la tarea correspondiente usando el token de nominacion.
  • La accion Traducciones permite editar links EN/PT y las traducciones de respuestas abiertas. Esa pantalla integra asistencia de IA para mejorar texto, pero el detalle funcional de prompts, limites y uso transversal queda documentado aparte.
  • La accion Ver respuestas abre una vista tecnica consolidada con datos del candidato, nominacion, apoyos, progreso de tareas, paises, organizaciones y decisiones de auditoria ya asociadas.
  • Los recordatorios manuales para nominaciones pendientes, candidatos aceptados y apoyos pendientes existen, pero hoy viven en los pre-reportes de la eleccion, no en la lista principal de candidatos.

Publicacion y efecto en boleta

  • La boleta publica toma solamente candidatos en CONFIRMED_AND_PUBLISHED.
  • Si randomOrderCandidates=false, la boleta respeta el orden persistido por candidateOrder en forma descendente, incluyendo las posiciones fijas.
  • Si randomOrderCandidates=true, el backend mezcla solo las candidaturas normales publicadas y luego reinyecta la abstencion segun la posicion relativa derivada de su orden persistido.
  • Que una candidatura quede en COMPLETE o que todas sus tareas esten completas no la publica por si sola: la inclusion publica sigue dependiendo del cambio administrativo a CONFIRMED_AND_PUBLISHED.

Completitud y navegacion

  • Atras: vuelve a Tareas.
  • Continuar despues: navega a Auditores sin marcar candidaturas como completadas.
  • Marcar como terminada y seguir: solo deja candidatesSet=true y navega a Auditores. La implementacion actual no valida que exista al menos un candidato regular cargado ni que haya nominaciones aceptadas.

Bloques relacionados

  • Calendario y tareas: la configuracion de ventanas, dependencias y catalogo de tareas esta documentada en esta guia.
  • Organizaciones: el origen de los links de nominacion y de muchos apoyos por organizacion esta documentado en esta guia.
  • Preguntas y declaraciones: el detalle funcional de preguntas estatutarias/no estatutarias, declaraciones y preguntas de comunidad esta documentado en esta guia.

Fuentes contrastadas

ElectionsManagerApp, ElectionCandidatesDashboard, CandidatesListPanel, CandidatesHeaderActionsPanel, AddCandidatePanel, EditCandidateDashboard, ManageCandidateStatusDashboard, ManageCandidateTrainingDashboard, ManageCandidateTranslationsDashboard, ManageCandidateBiographyDashboard, ViewCandidateAnswersDashboard, DoNominationPage, NominationFormPanel, AcceptNominationConditionsPage, GenericAcceptNominationTasksPage, SupportNominationPage, GenericNominationOrgSupportsManagementPanel, GenericNominationUserSupportsManagementPanel, AuthorizedSupportContactEmailValidator, Candidate, CandidateType, CandidateStatus, Nomination, NominationStatus, SupportNomination, SupportStatus, CandidateDao, ElectionsManagerEJBBean, ElectionsPreNominationEJBBean y ElectionsManagerApp.properties.xml.