Preguntas, declaraciones y comunidad

Esta guia describe el bloque vigente de v3.0 para preguntas estatutarias, preguntas no estatutarias, declaraciones del candidato y preguntas de comunidad. El contenido fue contrastado contra la UI administrativa, los task panels tokenizados, la pagina publica de candidatos, el dominio CandidateQuestion y la logica EJB que persiste, valida y publica cada respuesta.

Ubicacion en el flujo

  • La gestion administrativa de preguntas de comunidad esta montada en /admin/election/questions.
  • Las respuestas del candidato a preguntas y declaraciones viven dentro de /token/nomination/tasks para nominaciones ya aceptadas.
  • En el catalogo de tareas, este bloque usa cuatro claves separadas: OTHER_STATUTORY_QUESTIONS, OTHER_NON_STATUTORY_QUESTIONS, DECLARATIONS y DECLARATIONS_NON_STATUTORY.
  • La experiencia publica relacionada corre sobre la pagina de eleccion/candidato y depende de la publicacion de candidatos (N_11), del periodo de preguntas a candidatos (N_12) y de que la tarea correspondiente este marcada como publica.

Modelo operativo del bloque

  • Las preguntas estatutarias y no estatutarias son respuestas abiertas del candidato guardadas en la entidad Candidate.
  • Las declaraciones son aceptaciones explicitas guardadas tambien sobre Candidate, mediante checkboxes y una declaracion PEP por radio.
  • Las preguntas de comunidad se guardan aparte como CandidateQuestion, con remitente, idioma, pregunta, respuesta, estado, owner actual y fechas de creacion/actualizacion/publicacion.
  • El backend no mezcla estos flujos: preguntas/declaraciones del candidato forman parte del checklist de candidatura; preguntas de comunidad forman un flujo publico-administrativo paralelo con moderacion y eventual respuesta del candidato.

Preguntas estatutarias

  • La tarea OTHER_STATUTORY_QUESTIONS muestra siempre 4 preguntas abiertas.
  • Los textos visibles se resuelven por parametro con OTHER_STATUTORY_Q1_LABEL a OTHER_STATUTORY_Q4_LABEL. Si faltan, el sistema usa defaults hoy orientados a perfil personal, trayectoria en la organizacion, vision institucional y aporte esperado.
  • Cada respuesta se completa en un editor con asistencia de IA y limite de 1000 caracteres en la UI.
  • El formulario permite Continuar despues: guarda el estado actual y deja la tarea en STARTED.
  • Finalizar y enviar exige que las cuatro respuestas queden no vacias. Si falta una, la tarea no pasa a COMPLETED.
  • Al persistir desde el link de candidatura, el backend normaliza espacios y guarda la respuesta base en espanol; las columnas EN/PT quedan inicialmente con el mismo valor hasta que un admin las edite en traducciones.
  • En la pagina publica del candidato, estas respuestas solo se muestran si ya se alcanzo N_11_SINGLE_CANDIDATES_PUBLISHED y la tarea OTHER_STATUTORY_QUESTIONS esta marcada como publica.

Preguntas no estatutarias

  • La tarea OTHER_NON_STATUTORY_QUESTIONS muestra una sola pregunta abierta.
  • Su label sale de OTHER_NON_STATUTORY_Q1_LABEL. Si el parametro no existe, el texto default actual apunta a motivaciones de la nominacion y valor esperado desde el cargo.
  • La UX es equivalente a la de preguntas estatutarias: editor con asistencia de IA, limite visual de 1000 caracteres, boton de borrador (STARTED) y cierre obligatorio con respuesta no vacia para pasar a COMPLETED.
  • La persistencia sigue el mismo patron: se guarda la respuesta base en espanol y EN/PT quedan replicados hasta que se traduzcan manualmente.
  • En la pagina publica del candidato, esta respuesta solo aparece si N_11 ya fue alcanzado y la tarea OTHER_NON_STATUTORY_QUESTIONS esta marcada como publica.

Declaraciones estatutarias

  • La tarea DECLARATIONS no usa respuestas abiertas: presenta declaraciones obligatorias que deben aceptarse antes de completar la candidatura.
  • El backend arma la definicion en tiempo real segun idioma y tipo de eleccion, usando parametros DECLARATIONS_D1 a DECLARATIONS_D7 con fallback local.
  • Hoy el set base obligatorio incluye: incompatibilidades y capacidades, conflictos de interes, competencias e idoneidad, declaracion PEP, compromisos dinamicos y tratamiento/uso/publicacion de la informacion.
  • La declaracion disciplinaria (D4) solo aparece cuando el tipo efectivo de eleccion es BOARD.
  • La declaracion PEP es el unico control tipo radio y exige elegir entre NOT_PEP o PEP. El resto son checkboxes obligatorios.
  • Este formulario no tiene boton de borrador: solo puede finalizarse. Si falta una aceptacion obligatoria o la opcion PEP, la persistencia falla.
  • Si la eleccion publica la tarea DECLARATIONS, la informacion queda disponible para las vistas de soporte/auditoria, pero la pagina publica del candidato no renderiza estas declaraciones como bloque narrativo equivalente al de preguntas.

Declaraciones (n.e)

  • La tarea DECLARATIONS_NON_STATUTORY se genera segun el ElectionType efectivo de la eleccion.
  • Si la eleccion es IANA, se agrega la declaracion de conocimiento sobre IANA (D8).
  • Si la eleccion es ASO, se agrega la declaracion de conocimiento sobre ASO AC y PDP (D9).
  • Ademas, esta tarea vuelve a incluir las declaraciones de compromisos dinamicos y de tratamiento/uso/publicacion de la informacion (D6 y D7), aun cuando no aplique D8 ni D9.
  • Al igual que en declaraciones estatutarias, todos los controles configurados son obligatorios y la pantalla no ofrece guardado parcial.
  • En el resumen de auditoria del candidato, esta tarjeta solo aparece si la tarea esta habilitada y existe al menos una respuesta cargada.

Preguntas de comunidad

Las preguntas de comunidad no forman parte del checklist de tareas del candidato. Son un flujo propio con creacion publica, moderacion administrativa, eventual respuesta del candidato y publicacion final.

  • La carga publica requiere que la eleccion tenga publicElectionLinkAvailable=true, que exista questionToken valido y que la fecha actual caiga dentro de N_12_PERIODO_CANDIDATE_QUESTIONS.
  • Desde la pagina publica del candidato se puede enviar una pregunta al candidato actual o, si se marca la opcion correspondiente, replicarla a todos los candidatos publicos de la eleccion.
  • La UI publica pide nombre, email y texto de la pregunta. Si CAPTCHA esta habilitado y existe dataSiteKey, tambien valida reCAPTCHA.
  • La UI publica permite hasta 1000 caracteres, pero el backend normaliza questionText a 500 caracteres como maximo antes de persistir.
  • Solo se aceptan preguntas para candidatos en CONFIRMED_AND_PUBLISHED y que no sean la opcion de abstencion.
  • Al crearse publicamente, la pregunta nace en estado QUESTION_RECEIVED_LACNIC, owner LACNIC por compatibilidad historica, copia el mismo texto a SP/EN/PT y encola aviso al destinatario estandar de la eleccion. En una instalación de terceros estos valores técnicos significan “recibida por la administración electoral”; no implican intervención de LACNIC.

Moderacion administrativa de comunidad

  • El dashboard administrativo de preguntas lista id, candidato, estado, owner actual y preview de la pregunta.
  • El editor administrativo permite crear preguntas nuevas o editar existentes para cualquier candidato no abstencion de la eleccion abierta.
  • El formulario administrativo expone askedByName, askedByEmail, idioma de la pregunta, candidato, estado, textos de pregunta SP/EN/PT y textos de respuesta SP/EN/PT.
  • El admin puede guardar con email o sin email. Guardar sin email persiste igual, pero evita la notificacion de cambio de estado.
  • Las transiciones con efecto de correo hoy son: QUESTION_READY_FOR_CANDIDATE notifica al candidato; ANSWER_SUBMITTED_BY_CANDIDATE notifica al destinatario estandar; PUBLISHED notifica a quien hizo la pregunta.
  • Pasar a REJECTED o volver a QUESTION_RECEIVED_LACNIC no dispara correo de estado.
  • El editor tambien integra asistencia de IA para revisar o mejorar los textos de pregunta y respuesta.

Respuesta del candidato a preguntas de comunidad

  • En /token/nomination/tasks existe un panel lateral de preguntas de comunidad separado del task seleccionado.
  • Ese panel solo se muestra mientras la ventana N_12_PERIODO_CANDIDATE_QUESTIONS sigue abierta.
  • En la seccion pendiente, el candidato solo ve preguntas en estado QUESTION_READY_FOR_CANDIDATE.
  • Las preguntas ya respondidas por el candidato quedan en una seccion aparte cuando estan en ANSWER_SUBMITTED_BY_CANDIDATE o PUBLISHED.
  • La respuesta del candidato exige texto no vacio, usa un editor con revision ortografica asistida por IA y limita la entrada a 1000 caracteres.
  • Al enviar, el backend vuelve a validar token, nominacion aceptada, ventana N_12 abierta, pertenencia de la pregunta al candidato y estado QUESTION_READY_FOR_CANDIDATE. Si todo cierra, cambia la pregunta a ANSWER_SUBMITTED_BY_CANDIDATE y replica el mismo texto a SP/EN/PT.

Visibilidad publica real

  • Las respuestas a preguntas estatutarias y no estatutarias se muestran con iniciales fijas CE y fecha tomada de N_11_SINGLE_CANDIDATES_PUBLISHED.
  • El bloque de preguntas de comunidad se renderiza en la pagina publica del candidato desde que arranca N_12.
  • Las preguntas PUBLISHED muestran pregunta y respuesta completas, iniciales del remitente y fechas de pregunta/respuesta.
  • Las preguntas pendientes tambien quedan visibles en la UI publica con distinto nivel de mascara: QUESTION_RECEIVED_LACNIC oculta la pregunta y deja la respuesta esperando revision; QUESTION_READY_FOR_CANDIDATE muestra la pregunta y deja la respuesta como pendiente del candidato; ANSWER_SUBMITTED_BY_CANDIDATE muestra la pregunta y enmascara la respuesta mientras espera publicacion.
  • Las preguntas REJECTED no se muestran publicamente.

Impacto en revision y auditoria

  • La vista de auditoria publica del candidato genera tarjetas de resumen para DECLARATIONS, DECLARATIONS_NON_STATUTORY, OTHER_STATUTORY_QUESTIONS y OTHER_NON_STATUTORY_QUESTIONS cuando esas tareas estan habilitadas.
  • En declaraciones, la severidad del resumen depende del estado de completitud de la tarea: COMPLETED queda como correcto; cualquier otro estado queda como pendiente.
  • En preguntas estatutarias, el resumen cuenta respuestas contestadas sobre un total fijo de 4.
  • En preguntas no estatutarias, el resumen depende de la cantidad de respuestas disponibles y del estado de la tarea; si no hay preguntas configuradas, la tarjeta queda en warning.
  • No existe una tarjeta equivalente para preguntas de comunidad dentro de ese resumen: ese flujo se revisa desde el dashboard administrativo de preguntas y desde la pagina publica del candidato.

Completitud y navegacion

  • Las preguntas abiertas pueden quedar en STARTED y retomarse despues. Las declaraciones no tienen guardado parcial: o quedan validadas y persistidas completas, o no se actualizan.
  • La visibilidad publica de preguntas estatutarias/no estatutarias depende de la bandera publicable de cada tarea, no solo de que el candidato haya respondido.
  • Las preguntas de comunidad dependen del calendario N_12 y de la moderacion administrativa; no marcan tareas del candidato como completas ni reemplazan las preguntas del checklist.

Bloques relacionados

  • Candidaturas y nominaciones: el flujo general de aceptacion, apoyos y publicacion de candidatos esta documentado en esta guia.
  • Calendario y tareas: la configuracion de claves, dependencias, etapas y visibilidad publica se documenta en esta guia.
  • Auditoria previa y final: el consumo de estas respuestas dentro de la revision de candidatos, la conformidad final y la revision de votos esta documentado en esta guia.

Fuentes contrastadas

ElectionQuestionsDashboard, QuestionsListPanel, QuestionEditPanel, GenericNominationDeclarationsManagementPanel, GenericNominationNonStatutoryDeclarationsManagementPanel, GenericNominationOtherStatutoryQuestionsManagementPanel, GenericNominationOtherNonStatutoryQuestionsManagementPanel, CandidateCommunityQuestionsPanel, GenericAcceptNominationTasksPage, PublicElectionPage, AuditPublicCandidateDetailPage, CandidateQuestion, CandidateQuestionStatus, CandidateDeclarationCode, CandidateDeclarationsDefinition, ElectionTaskKey, CandidateQuestionDao, ElectionsPreNominationEJBBean, ElectionsManagerEJBBean, PublicElectionVisibilityResolver, PublicElectionSnapshotBuilder y ElectionsManagerApp.properties.xml.