You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Buenas, soy Agustín, coordinador del equipo de Recuento. Me pongo en contacto con vosotros por este medio en representación de todo nuestro equipo para explicaros los hechos que han llevado a la situación actual, en la que nuestro módulo hace las funciones de almacenamiento, de forma que conozcáis todo lo ocurrido hasta ahora y los razonamientos detrás de nuestras decisiones para facilitar un poco vuestra tarea de integración con el resto de subsistemas y que quede constancia de ello para que los compañeros del año que viene puedan tener también esta información para continuar por donde vosotros lo dejéis este año.
Nuestro equipo empezó a trabajar en el subsistema de recuento y modificación de votos relativamente pronto, allá por principios o mediados de Noviembre, y empezamos por implementar nuestras funcionalidades básicas como el servidor web para atender las peticiones a nuestra API o la modificación y eliminación de votos. Como es lógico, en estas fases tan tempranas no estábamos integrados con ningún otro sistema (dado que el proyecto heredado del año pasado tampoco lo estaba), por lo que para empezar a trabajar hicimos una pequeña base de datos local con información sobre usuarios y votaciones, con la intención de posteriormente emplear las API de los subsistemas correspondientes (en este caso, Autenticación y vosotros).
Este sistema de persistencia local continuó así un cierto tiempo, hasta que los compañeros de Autenticación B nos dijeron que su subsistema ya estaba listo para la integración, pasando así de comprobar la identidad de los usuarios en nuestra base local a hacerlo directamente contra ellos. En todo este tiempo, el almacenamiento de votos de nuestro subsistema seguía estando en local (dado que no había respuesta por vuestra parte) y de una forma bastante rudimentaria, con un simple JSON, porque pretendía ser simplemente una solución temporal.
El tiempo pasó y nos encontramos a mediados de Diciembre, integrados con más grupos (Verificación, Frontend, Cabinas...) y seguíamos teniendo la necesidad de almacenar los votos, acrecentada por las continuas peticiones que recibíamos de los compañeros de Frontend -necesitan que nosotros tengamos votos almacenados para poder mostrar gráficamente nuestro recuento- y cabina -lógicamente, la cabina de votación tiene que guardar los votos en algún sitio-, por lo que ante la falta de respuesta decidimos implementar nosotros las funciones de almacenamiento de votos y votaciones, dado que nos encontrábamos, por así decirlo, en el "centro" de los demás subsistemas que también las requerían, para poder permitir al resto de compañeros continuar con sus respectivos subsistemas. Pasamos así de un archivo de texto plano con los votos en formato JSON a una base de datos relacional empleando SQLite.
Creemos que, dado que tenéis la necesidad de integraros con los demás sistemas, lo más sencillo sería que adoptáseis el modelo que hemos desarrollado nosotros, dado que es fruto de la comunicación entre los diferentes equipos y es el que emplean actualmente el resto de compañeros. Es el siguiente:
Tabla "votaciones", que almacena la información de cada votación registrada en el sistema. Contiene los siguientes campos:
id: Identificador único de la votación
titulo: Título de la votación
fecha_creacion: Momento en el que se creó la votación
fecha_cierre: Momento en el que se cierra la votación, es decir, a partir del cual no se pueden emitir más votos y se puede recontar.
cp: Código postal asociado a la votación. Es una petición de los compañeros de Frontend para poder mostrar las votaciones del sistema en un mapa.
Tabla "preguntas", que almacena las preguntas asociadas a las votaciones. Cada votación puede tener más de una pregunta. Contiene los siguientes campos:
id: Identificador único de la pregunta
texto_pregunta: Texto en sí de la preguna
multirespuesta: Indica si la pregunta admite votar por más de una opción o no.
id_votacion: Votación a la cual pertenece la pregunta.
Tabla "opciones", que almacena las opciones asociadas a cada una de las preguntas. Contiene los siguientes campos:
id: Identificador único de la opción
texto_opcion: Texto de la opción
id_pregunta: Pregunta a la cual pertenece esta opción
Tabla "votos", que almacena los votos emitidos por los usuarios. Los votos almacenados deben estar cifrados usando el módulo de Verificación, y no se deben aceptar peticiones para almacenar votos que no lo estén, dado que es responsabilidad de las cabinas hacerlo antes de pasar el voto a almacenamiento. Campos:
id: Identificador único del voto
token_user: Token del usuario que emitió el voto. El token debe ser comprobado antes contra Autenticación, y si no es válido no se debe permitir el almacenamiento del voto.
fecha: Momento de emisión del voto
id_pregunta: Pregunta a la cual se ha respondido con este voto.
opcion: Identificador cifrado de la opción votada para la pregunta.
Esta última tabla merece un par de consideraciones especiales: en primer lugar, cabe destacar que id_pregunta es una FK a la tabla preguntas, mientras que opcion es simplemente un campo de texto. Esto es así debido a que la opción está cifrada, por lo que no se puede relacionar de ninguna forma con la tabla de opciones. En segundo lugar, este mismo particular impide comprobar que la opción votada corresponda a la pregunta en cuestión (por ejemplo, la pregunta con ID 12 puede contener las opciones 17, 18 y 19, pero dado que la opción votada está cifrada no se puede comprobar que efectivamente la opción sea una de esas tres). Este problema es ajeno al módulo de Almacenamiento, que debe limitarse a pasar los datos a Recuento quienes verificarán tras descifrar los votos que las opciones sean efectivamente correctas, descartando el voto si no es así.
Con este esquema de base de datos y operaciones CRUD básicas (teniendo en cuenta todo lo indicado anteriormente respecto a comprobaciones y aclaraciones) se puede dar servicio a las dos cabinas de votación de la misma forma que nosotros lo veníamos haciendo hasta ahora. Por nuestra parte, sólo necesitaríamos que se pudieran modificar y eliminar los votos de un usuario concreto para poder cumplir con nuestras funcionalidades.
Respecto al cifrado de los datos, es algo por lo que no os debéis preocupar, ya que el módulo de almacenamiento es totalmente ajeno a ello. El cifrado lo realiza la cabina en cuestión, os pasa el voto ya cifrado para que se almacene y posteriormente recuento obtiene los votos cifrados y los descifra usando su clave privada.
Nuestro código de gestión de almacenamiento se puede encontrar aquí y está totalmente a vuestra disposición para que lo inspeccionéis y, por supuesto, podéis contactar con nosotros vía issue si necesitais cualquier aclaración al respecto. También podéis consultar aquí la documentación de nuestra API, dado que contiene métodos relacionados con el almacenamiento y la consulta de votos y votaciones y que probablemente tendréis que recrear para que la transición de nuestro sistema al vuestro por parte de los compañeros que la utilizan sea totalmente suave y no haya problemas.
Entiendo que el margen de tiempo que queda hasta la entrega de la mejora es escaso, pero espero que toda esta información sirva para que podáis avanzar un poco hacia el camino de la integración con el resto de sistemas y que también sea de utilidad para que los compañeros del año que viene, tanto de nuestro módulo como del vuestro, conozcan la problemática generada, la solución propuesta y puedan separar definitivamente las funcionalidades en los subsistemas correspondientes.
Reitero que para cualquier cosa podéis contactar con nosotros mediante una issue en nuestro repositorio o una mención en cualquier otro y estaremos encantados de ayudar.
Un saludo.
The text was updated successfully, but these errors were encountered:
@agubelu En primer lugar, muchas gracias por el comentario y por intentar facilitarnos esto. Como para la mejora solamente voy a a presentarme yo y como queda poco tiempo, no veo posible implementar todos estos cambios. Sin embargo, cogeré la información que me has dado y se la intentaré llegar a los alumnos que sigan desarrollando este sistema el año que viene.
Un saludo, gracias y siento las molestias causadas.
Buenas, soy Agustín, coordinador del equipo de Recuento. Me pongo en contacto con vosotros por este medio en representación de todo nuestro equipo para explicaros los hechos que han llevado a la situación actual, en la que nuestro módulo hace las funciones de almacenamiento, de forma que conozcáis todo lo ocurrido hasta ahora y los razonamientos detrás de nuestras decisiones para facilitar un poco vuestra tarea de integración con el resto de subsistemas y que quede constancia de ello para que los compañeros del año que viene puedan tener también esta información para continuar por donde vosotros lo dejéis este año.
Nuestro equipo empezó a trabajar en el subsistema de recuento y modificación de votos relativamente pronto, allá por principios o mediados de Noviembre, y empezamos por implementar nuestras funcionalidades básicas como el servidor web para atender las peticiones a nuestra API o la modificación y eliminación de votos. Como es lógico, en estas fases tan tempranas no estábamos integrados con ningún otro sistema (dado que el proyecto heredado del año pasado tampoco lo estaba), por lo que para empezar a trabajar hicimos una pequeña base de datos local con información sobre usuarios y votaciones, con la intención de posteriormente emplear las API de los subsistemas correspondientes (en este caso, Autenticación y vosotros).
Este sistema de persistencia local continuó así un cierto tiempo, hasta que los compañeros de Autenticación B nos dijeron que su subsistema ya estaba listo para la integración, pasando así de comprobar la identidad de los usuarios en nuestra base local a hacerlo directamente contra ellos. En todo este tiempo, el almacenamiento de votos de nuestro subsistema seguía estando en local (dado que no había respuesta por vuestra parte) y de una forma bastante rudimentaria, con un simple JSON, porque pretendía ser simplemente una solución temporal.
El tiempo pasó y nos encontramos a mediados de Diciembre, integrados con más grupos (Verificación, Frontend, Cabinas...) y seguíamos teniendo la necesidad de almacenar los votos, acrecentada por las continuas peticiones que recibíamos de los compañeros de Frontend -necesitan que nosotros tengamos votos almacenados para poder mostrar gráficamente nuestro recuento- y cabina -lógicamente, la cabina de votación tiene que guardar los votos en algún sitio-, por lo que ante la falta de respuesta decidimos implementar nosotros las funciones de almacenamiento de votos y votaciones, dado que nos encontrábamos, por así decirlo, en el "centro" de los demás subsistemas que también las requerían, para poder permitir al resto de compañeros continuar con sus respectivos subsistemas. Pasamos así de un archivo de texto plano con los votos en formato JSON a una base de datos relacional empleando SQLite.
Creemos que, dado que tenéis la necesidad de integraros con los demás sistemas, lo más sencillo sería que adoptáseis el modelo que hemos desarrollado nosotros, dado que es fruto de la comunicación entre los diferentes equipos y es el que emplean actualmente el resto de compañeros. Es el siguiente:
Tabla "votaciones", que almacena la información de cada votación registrada en el sistema. Contiene los siguientes campos:
Tabla "preguntas", que almacena las preguntas asociadas a las votaciones. Cada votación puede tener más de una pregunta. Contiene los siguientes campos:
Tabla "opciones", que almacena las opciones asociadas a cada una de las preguntas. Contiene los siguientes campos:
Tabla "votos", que almacena los votos emitidos por los usuarios. Los votos almacenados deben estar cifrados usando el módulo de Verificación, y no se deben aceptar peticiones para almacenar votos que no lo estén, dado que es responsabilidad de las cabinas hacerlo antes de pasar el voto a almacenamiento. Campos:
Esta última tabla merece un par de consideraciones especiales: en primer lugar, cabe destacar que id_pregunta es una FK a la tabla preguntas, mientras que opcion es simplemente un campo de texto. Esto es así debido a que la opción está cifrada, por lo que no se puede relacionar de ninguna forma con la tabla de opciones. En segundo lugar, este mismo particular impide comprobar que la opción votada corresponda a la pregunta en cuestión (por ejemplo, la pregunta con ID 12 puede contener las opciones 17, 18 y 19, pero dado que la opción votada está cifrada no se puede comprobar que efectivamente la opción sea una de esas tres). Este problema es ajeno al módulo de Almacenamiento, que debe limitarse a pasar los datos a Recuento quienes verificarán tras descifrar los votos que las opciones sean efectivamente correctas, descartando el voto si no es así.
Con este esquema de base de datos y operaciones CRUD básicas (teniendo en cuenta todo lo indicado anteriormente respecto a comprobaciones y aclaraciones) se puede dar servicio a las dos cabinas de votación de la misma forma que nosotros lo veníamos haciendo hasta ahora. Por nuestra parte, sólo necesitaríamos que se pudieran modificar y eliminar los votos de un usuario concreto para poder cumplir con nuestras funcionalidades.
Respecto al cifrado de los datos, es algo por lo que no os debéis preocupar, ya que el módulo de almacenamiento es totalmente ajeno a ello. El cifrado lo realiza la cabina en cuestión, os pasa el voto ya cifrado para que se almacene y posteriormente recuento obtiene los votos cifrados y los descifra usando su clave privada.
Nuestro código de gestión de almacenamiento se puede encontrar aquí y está totalmente a vuestra disposición para que lo inspeccionéis y, por supuesto, podéis contactar con nosotros vía issue si necesitais cualquier aclaración al respecto. También podéis consultar aquí la documentación de nuestra API, dado que contiene métodos relacionados con el almacenamiento y la consulta de votos y votaciones y que probablemente tendréis que recrear para que la transición de nuestro sistema al vuestro por parte de los compañeros que la utilizan sea totalmente suave y no haya problemas.
Entiendo que el margen de tiempo que queda hasta la entrega de la mejora es escaso, pero espero que toda esta información sirva para que podáis avanzar un poco hacia el camino de la integración con el resto de sistemas y que también sea de utilidad para que los compañeros del año que viene, tanto de nuestro módulo como del vuestro, conozcan la problemática generada, la solución propuesta y puedan separar definitivamente las funcionalidades en los subsistemas correspondientes.
Reitero que para cualquier cosa podéis contactar con nosotros mediante una issue en nuestro repositorio o una mención en cualquier otro y estaremos encantados de ayudar.
Un saludo.
The text was updated successfully, but these errors were encountered: