moffinguer / decide-part-camaron-2 Goto Github PK
View Code? Open in Web Editor NEWThis project forked from adrrf/decide-part-camaron
Plataforma de voto electrónico educativa
License: GNU Affero General Public License v3.0
This project forked from adrrf/decide-part-camaron
Plataforma de voto electrónico educativa
License: GNU Affero General Public License v3.0
el workflow de pr automáticos deberia hacer pr cuando a develop se hace un push
el workflow no funciona debido a la protección de las ramas
Los botones de crear un Backup y restaurar la Database deben de estar en el dashboard, ya que añaden funcionalidad al módulo
Ambos botones están en la esquina superior de la vista vote
Las funciones de postprocessing deberian estar correctamente testadas antes de subir a master
Las funciones no estan testeadas y están en master
Los test funcionan correctamente
Los test, a pesar de funcionar correctamente antes de la integración, ahora tienen fallos debido al cambio en el metodo post de Store
Se debe de poder hacer un despliegue tanto en Vagrant como en Docker y en la Nube
Actualmente no está desplegado de forma continua de ninguna forma
Se verifica la implementacion de Django Channels para el uso de WebSockets con test unitarios en el test.py del módulo store.
Los datos en tiempo real no están siendo testeados en la aplicación.
Un usuario puede ver el historico de votos de ese usuario
No está implementado
El Dashboard debe mostrar informacion actualizada en tiempo real sobre las votaciones.
Enseña datos recopilados de la base de datos en un momento concreto.
Debe cambiar de forma que teniendo varias preguntas por votación, se aplique un postprocesado a cada pregunta teniendo en cuenta el tipo de pregunta (nomal, pregunta si/no, etc).
Actualmente el post procesado de la votación está hecho para una sola pregunta por votación
The store page is accessed correctly
When you start the app and go to the store page, an error appears
Cuando haces una petición HTTP POST, la petición se procesa de forma síncrona, lo que significa que Django espera hasta que se completa la petición antes de continuar.
Cuando se establece una conexión WebSocket, se crea un bucle de eventos que maneja las comunicaciones entre el cliente y el servidor. Este bucle de eventos es asíncrono, lo que significa que puede manejar múltiples tareas al mismo tiempo sin tener que esperar a que se complete una tarea antes de pasar a la siguiente.
Cuando intentas hacer una consulta a la base de datos (que es una operación síncrona) dentro de este bucle de eventos, Django te da un error porque no puedes hacer operaciones síncronas dentro de un contexto asíncrono.
Cuando se realiza un post debería enviarse un mensaje con la información actualizada
Se establecen las conexiones con el servidor pero no se envía ni recibe nada
Tablón de datos con información sobre una votación, y funciones
No está integrado
Las funciones de postprocesamiento deberían estar en un módulo independiente.
Las funciones de postprocesamiento están actualmente en el módulo de voting.
El workflow deberia funcionar correctamente
El worlflow no ejecuta
que al realizar un nuevo push a master, se cree, automáticamente en el repositorio central una pull request con esos cambios.
el procedimiento de pull request a master se tiene que hacer de manera manual
Tests y vistas de part-camaron-3 deberían de funcionar
Tras haberse mergeado los cambios para integración se ha encontrado que se ha roto
When obtaining the results of a vote, in the postproc atribute, the first argument of the json is called "type" and contains the name of the method used to process the data.
Actually, as on decide part 3, this field only contains the same value of the "votes" atribute
intentionally blank
Debe de crearse la funcionalidad en base al siguiente algoritmo
No está implementado
Se debe de crear un sistema de backup en caso de borrar la base de datos. Se debe de elegir el backup.
No está implementado
El historial de votos muestra las votings, que pueden tener varias preguntas tras los cambios del grupo part-camaron-3
El historial muestra votings en las que ha participado el usuario, pero teniendo en cuenta una sola pregunta por voting únicamente
The "backup" folder's content is not pushed every time.
The "backup" folder's content is pushed every time, meaning its backups are always pushed whenever they're changed.
En la plantilla debe existir un campo que permita al creador de la incidencia incluir información que facilite replicar el problema, como datos del entorno.
La plantilla solo incluye un Workflow, un comportamiento esperado y el comportamiento real.
Se debería de crear una carpeta backup cuando haces un backup
No lo hace
con cada tag subida a master deberiamos tener una release, para que no sea tan tediosa la creación de la release se automatizará el proceso con un workflow
no tenemos ninguna release, ni ningun proceso de automaticación que automatice la generación de las mismas
Se debe de poder hacer un despliegue en la Nube
Actualmente no está desplegado de forma continua de ninguna forma
Visualización de todas las votaciones en el dashboard de manera ordenada.
Aparecen una debajo de otra.
The ammount of backup files can be overwhelming, the app should display a mechanism for deleting backup files locally
The only way to delete a backup is by deleting the file manually
Se debe de establecer en la Wiki la estrategia a seguir para issues. Las plantillas existen, se deben clarificar y explicar.
Se debe mostrar el número de votos que tiene una votación y el porcentaje del censo que ha votado en ella.
No tiene ninguna funcionalidad.
Se debe de poder hacer un despliegue en Vagrant
Actualmente no está desplegado de forma continua de ninguna forma
Los votos de los usuarios están cifrados, por lo que no es posible acceder a ellos en la base de datos y no deben mostrarse los campos "a" y "b" cifrados en el historial.
Se había malinterpretado los campos a y b de los votos como opciones de voto, y por tanto se mostraban en el historial como las opciones votadas por el usuario en dicho voto.
Que el módulo de post procesamiento acepte el modo cuota de droop
El módulo de post procesamiento no acepta el modo cuota de droop
Cuando se realiza una votacion en booth, se envia al dashboard de store para que cuente como nuevo voto
No se envía nada desde booth, solo desde el post de store de administrador
Funcionalidades a parte de visualización de datos en el panel de control.
Sólo se pueden visualizar datos en el panel de control.
que al realizar un nuevo push a develop, se cree, automáticamente una pull request a la rama master con esos cambios.
el procedimiento de pull request a master se tiene que hacer de manera manual
Cuando se haga una votación que no es de tipo single, denegar que se pueda usar técnicas de postprocesado
Ahora mismo intenta hacer el postprocesado rompiendo el sistema
El historial mostrará las votaciones junto a los campos relevantes para el usuario
El historial muestra uncamente el nombre y las preguntas de la votación en un estilo muy simple
Se debe de crear el siguiente incremento, con el algoritmo siguiente
No está implementado
Se espera integrarnos con el grupo-part-camaron-3 con el modulo de Voting
Seleccionar las tecnicas de postprocesados cuando se cree una votacion
Solo puedes modificar los tipos de votos. Dejandolo así afecta a las técnicas creadas, creando incompatibilidades
Se incluyen los botones de backup sin problema en el panel de dashboard
Hay conflictos en archivos modificados
De de cumplir con el siguiente funcionamiento
No está implementado
Lista con atributos para las votaciones como el id de la votacion y el id del votante además del momento en el que se dió la votación
La lista solo muestra los indices, sin atributos para ninguno de ellos
Deben haber al menos 5 o 6 pruebas
Solo existen 2 pruebas del backup
El algoritmo de borda debería de devolver un listado de valores por votación
No funciona
No procede
Se debe de cubrir todas las implementaciones añadidas en la rama
No se comprueban todas las líneas del código
El código pasa la depuración de vscode con normalidad
vscode detecta un error en la línea 47 de change_list.html de las templates del módulo store al utilizar la sintaxis de plantillas de Django ({{ variable }}) dentro de un bloque de código JavaScript. A pesar de que esto funciona al desplegar Django es detectado como un error en el código.
que al realizar un nuevo push a master, se cree, automáticamente en el repositorio central una pull request con esos cambios.
el procedimiento de pull request a master se tiene que hacer de manera manual
Se debería de comprobar cada vez que se haga un push el codigo se formatee de tal forma que use el estandar de pep8
Actualmente hacemos la verificación con Codacy, si hay errores, se decide si quitar o arreglarlo
Si hay una pull request para CI abierta, ignorarla, y continuar
Lanza un error por existir una existente
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.