gcsis
commented
1 year ago Tiro esto acá, porque considero EMHO es x donde se debe enfocar en el diseño del BE (cuento con expertise en BE dev de cómputos electorales).
Estimo debajo un mínimo esta estructura de datos (si se adopta relacional).
Concuerda con las columnas del .csv del sistema Electoral Nacional para poder comparar y detectar desviaciones para denuncias con datos reales y concretos, general y a nivel de mesas.
Estructura de los datos
Estas entities deben contar c/u con su correspondiente CRUD, mas allá de los entry controller especializados q se requieran.
province ( id, name ) --> es la provincia o CABA
|
|__>> section ( id, name ) --> Es la sección electoral
|
|__>> district ( id, name ) --> Es el distrito / municipio / departamento
|
|__>> circuit ( id ) --> Es el circuito electoral en el distrito
|
|__>> table ( id, v134, v135, vtot, vblank ) --> Es la mesa de votación
|
|___>>
_______>> fiscal_table ( fiscalId, tableId ) -->> relacion M:M de fiscales de mesas
|
|
fiscal ( id, DNI, telefono, [userId] ) -->> Cada fiscal, persona física (DNI Unique Key)
La tabla "fiscal_table" permite asociar 1 fiscal (o mas) x cada mesa o viceversa.
Aclaración conceptual de CIRCUITO para la detección de Fraudes en c/mesa:
El CIRCUITO es una zona geográfica que no siempre coincide con el concepto de localidad (puede contener mas de una o ser parte de una). Es definida por la Justicia Electoral y divisoria dentro de cada distrito, para contener una cierta cantidad de mesas en donde los votantes empadronados, están ORDENADOS ALFABETICAMENTE. Es decir que dentro de un circuito los promedios de votos resultantes de cada lista política son prácticamente idénticos y están dentro de un "desvío aceptable" o tolerancia.
Lo importante en esto es que, una vez cargada cierta cantidad de mesas, y a los fines de controlar la posibilidad de fraudes, es que conociendo el promedio de votos del partido político XX en un circuito NNNN, no debe haber diferencias importantes en los promedios entre una y otra mesa.
Por ej. si en el circuito 00085 de la mesa 412 de Bahia Blanca hay 40% de votos para LLA y 60% para UXT, pero el PROMEDIO calculado para todo ese circuito es de 52% LLA y 48% UXT, es una mesa con mucha probabilidad de fraude/error del telegrama, y por ende hay que pedir la reapertura de urna, en el turno con la justicia electoral.
Como orientación de su efecto en el FE (no es mi expertise) , con esa dispersión o "diferencia" respecto a la media, debería establecerse una tolerancia (x ej. 15%) desde la que se alerta y/o "colorea" esa mesa para identificarla visualmente en los lists. Se me ocurre que debajo de esa tolerancia es verde, y se va "enrojeciendo" en la medida que la diferencia es mayor.
Por otra parte me parece correcta la decisión de trabajar sobre Nestjs + typeorm para el BE.
Espero haber sido de utilidad y sigo a disposición.
Descripción:
Contexto:
Para administrar las cuentas de fiscales de manera eficiente en el panel de administración, es esencial implementar operaciones CRUD (Crear, Leer, Actualizar, Eliminar) para fiscales y conectar estas operaciones con los endpoints del backend.
Tareas:
Vista de Fiscales:
Diseñar y crear una vista en el panel de administración que muestre la lista de fiscales existentes. Mostrar la capacidad de crear, habilitar, deshabilitar y eliminar cuentas de fiscales desde esta vista.
Creación de Fiscales:
Implementar un formulario que permita la creación de nuevas cuentas de fiscales. El formulario debe incluir campos como nombre, correo electrónico, contraseña, entre otros. Conectar el formulario con el endpoint del backend para crear nuevas cuentas de fiscales.
Habilitar y Deshabilitar Fiscales:
Implementar botones o interruptores que permitan habilitar o deshabilitar cuentas de fiscales existentes. Conectar estas operaciones con los endpoints del backend para actualizar el estado de habilitación.
Eliminación de Fiscales:
Implementar una opción que permita eliminar cuentas de fiscales existentes. Conectar esta operación con el endpoint del backend para eliminar cuentas de fiscales.
Criterios de Aceptación:
La vista de fiscales en el panel debe mostrar la lista de cuentas de fiscales existentes y proporcionar las opciones de crear, habilitar, deshabilitar y eliminar cuentas.
El formulario de creación de fiscales debe incluir campos necesarios y permitir la creación de nuevas cuentas. Debe conectarse con el endpoint correspondiente en el backend.
Las operaciones de habilitación y deshabilitación deben funcionar según lo esperado y conectarse con los endpoints del backend para actualizar el estado de habilitación de las cuentas.
La eliminación de cuentas de fiscales debe funcionar correctamente y conectarse con el endpoint del backend para eliminar cuentas.
Probar exhaustivamente las operaciones CRUD para garantizar su funcionamiento y verificar que se manejen los errores de manera adecuada.
Documentar las operaciones CRUD en el archivo README.md, proporcionando instrucciones para su uso.