Reservation system integrated in status webpage

[David-Estevez]

Context

From #8:

5. Pese a que el sistema de la hoja de cálculo ha demostrado históricamente cumplir con su cometido, se trata de algo totalmente arcaico, y ya que hemos dado un lavado de cara a la página de gestión, propongo ir más allá y mejorar esa parte también.

Ideas:

• Programar una página con un formulario (por ejemplo, en html) en el que sea necesario introducir un correo de dominio uc3m. Se enviará un correo de confirmación a esa dirección para confirmar la reserva. De esta manera llevaremos un control de quién y cuánto uso se hace de las impresoras. En caso de que alguien sin cuenta uc3m quiera utilizar las impresoras, el usuario deberá incluir un texto explicando el motivo del uso y el sistema además de enviar el correo de confirmación, remitirá otro correo a algún miembro de ASROB para obtener autorización.
• Crear una base de datos que será atacada desde los formularios para realizar las reservas. En esta base de datos estará almacenada la información histórica de las reservas desde el momento de su creación. Cada semana, se programará la creación de nuevas entradas en la base de datos para dar cabida a las reservas de la siguiente semana.
• Esta base de datos será leida cada vez que la página del formulario se cargue, y mostrará en una tabla similar al documento excel los huecos libres para cada impresora. Sería genial que la forma de reservar fuera pulsando sobre las distintas celdas de la tabla, al igual que se seleccionan las fechas de una estancia en un hotel, o un viaje...

Logrando esto, habremos conseguido realmente automatizar la gestión de las impresoras y la cerveza que nos tomemos sabrá mucho mejor.

Objectives

• Implement a reservation system integrated in the current printer status webpage.

References for future development

• Example of booking system with nice/simple UI
• AngularJS (JS frontend framework)
• View a Gcalendar with Angular & bootsrap

[Siotma]

From asrob-uc3m/impresoras-asrob#8

Suscribo totalmente los comentarios que haces. Yo hacía las propuestas con vistas a futuro, y obviamente sujetas a debate previo, pensando en que en la asociación hay gente no solo de electrónica y automática, sino también de informática y otras disciplinas para los que realizar algo como lo descrito puede requerir mucho menos esfuerzo.

En un futuro optimista, con un grupo de trabajo activo en impresoras y un sistema de gestión más optimizado, las impresoras tendrán mucho más uso del que tienen ahora y por tanto, limitar el uso a personas de la UC3M tendría valor de cara a poder usar un seguimiento de las reservas e identificar los usuarios más activos y los menos activos. Utilizando las cuentas de correo UC3M se evita que un usuario cree múltiples cuentas para reservar un número de horas mayor, y el sistema de correos de confirmación refuerza este filtro de forma activa (que tal vez se pudiera automatizar) limitando las horas de reserva y comprobando que el usuario que pretende reservar es un operador o no. Fuera de la ventaja de evitar duplicación de cuentas, no tiene mayor sentido limitar el acceso a la hoja de reservas, máxime cuando no hemos tenido problemas de este tipo todavía. Como ya he explicado, esta propuesta hace frente a problemas que aún no han surgido, pero que si conseguimos atraer más gente a usar las impresoras, puede que surjan. Por ello no veo necesario restringir el acceso a la hoja en este momento.

Por otro lado, sí existe una clara ventaja en sacar estadísticas de uso de impresoras, ya que podría valer para justificar los gastos relacionados con ellas, pedir subvenciones, obtener financiación desde el Departamento, optimizar su rendimiento (detectar problemas más frecuentes, escuchar sugerencias de usuarios), e incluso plantear mejoras funcionales o ampliación del número de impresoras disponibles.

En mi línea de coordinador de grupo de trabajo de Printer One, quiero aprovechar este nuevo tirón de gente para implementar cualquier mejora que pueda facilitar el acceso a las impresoras y reducir las tareas de mantenimiento para intentar garantizar buena salud para las mismas durante mucho tiempo.

[Siotma]

Ahora que tenemos una página de operadores generada automáticamente, podríamos ir un paso más allá y utilizar la información de esta página para generar una base de datos de operadores autorizados.

Utilizando una autenticación basada en GitHub (similar a esta), se podría filtrar que únicamente los usuarios de GitHub que han obtenido el título de operador puedan realizar reservas.

[Siotma]

Ayer y hoy he estado pegándome con XAMPP, HTML, PHP, SQL y demás, y además de servirme para refrescar cosas que había dejado olvidadas, he parido una página que podría hacernos las veces de sistema propio de reservas.

La página está en html con php incrustado. Utilizo el siguiente schema:

Y esta es una captura de la web. En la parte superior tiene algunos logs de depuración.

He estado hablando con @David-Estevez y creemos que esta estructura se podría explotar para conseguir algo funcional, aunque parece que estaríamos limitados por el tema del https (asrob-uc3m/actas#88)...

Opiniones?

[jgvictores]

De cara a la experiencia del usuario final, no veo que haga diferencia http/https (aunque sea recomendable https siempre que hayan cuentas y contraseñas).

¿Cómo podría casar esto con la idea de autenticación basada en GitHub?

[Siotma]

¿Cómo podría casar esto con la idea de autenticación basada en GitHub?

Según he visto, se podría dar de alta la aplicación en la cuenta de GitHub de ASROB, y usar la API de GitHub para recuperar la información del usuario (con el nombre de usuario sería suficiente) una vez logueado. Por tanto, de la captura anterior, el campo de nombre de usuario no sería necesario. Más info: https://developer.github.com/v3/guides/basics-of-authentication/

Por otra parte, @David-Estevez me habló de Flask, que según he entendido, se podría usar para algo similar: https://github-flask.readthedocs.io/en/latest/

[David-Estevez]

Usar https es IMPRESCINDIBLE, ya que se necesita hacer autenticación de usuarios y, una vez autenticados, mandar credenciales al servidor. Tendríamos un agujero enorme de seguridad si lo hacemos por http.

Por otro lado, @Siotma y yo estuvimos hablando de montar el backend de la aplicación en Flask, que es un framework de Python que tiene muchas de las cosas necesarias para una web moderna y segura ya implementadas y testeadas. Como ejemplo, el módulo que comenta @Siotma (https://github-flask.readthedocs.io/en/latest/) permite autenticar usuarios usando GitHub de manera similar a como lo hace Gitbook, usando OAuth y sin tener que trampear nada con la cuenta de ASROB.

Por otro lado, la mayor dificultad de la web tal y como yo lo veía era la interfaz de usuario para llevar a cabo la reserva, y esto lo ha solucionado @Siotma perfectamente con su interfaz basada en tablas y checkboxes. Una vez se tiene eso, que es lo más chungo, diseñar el resto de la arquitectura me parece bastante sencillo.

[Siotma]

Hoy, @David-Estevez y yo hemos hablado de la posibilidad de montar la aplicación de reservas (y eventualmente, la de impresoras y la de operadores) sobre un framework de Flask. De esta forma se podrían dinamizar las consultas, respetando prácticamente intacta sus estructuras y plantillas.

La estructura de la página sería similar a la expuesta en las capturas de más arriba, pero aprovechando bootstrap para darle un aspecto acorde con el de resto de páginas.

Además, como ya comenté, se dispone de una extensión para dar soporte a autenticación basada en GitHub: https://github-flask.readthedocs.io/en/latest/

@David-Estevez valora la posibilidad de incorporar javascript y/o AngularJS para dotar a la página de refresco en tiempo real.

Por otro lado, hemos revisado el concepto de webhooks y parece que encajarían bien con Flask en tanto en cuanto hacen POST a una url predesignada que Flask podría estar escuchando; de manera que al realizar este desarrollo obtendríamos al mismo tiempo una base con la que implementar fácilmente actualizaciones en tiempo real para nuestras páginas que actualmente son refrescadas periódicamente.

[Siotma]

@David-Estevez se ha ofrecido a iniciar un nuevo repo para este desarrollo y dotarlo de una estructura compatible con Flask, así como los ficheros necesarios para comenzar a desarrollar la web. En caso de que no le sea posible realizarlo, lo comunicará por si se puede encargar otra persona.

[David-Estevez]

Voy a intentar ampliar y/o clarificar las ideas que han surgido esta tarde también en esta issue.

Básicamente es lo que comenta @Siotma, diseñar un sistema basado en Flask, que nos permita a largo plazo unificar los esfuerzos de la web de impresoras la web de operadores y la futura web de reservas, así como sentar las bases de otras posibles futuras aplicaciones que se puedan necesitar (ejem, inventario, ejem).

Flask es idóneo para esto porque:

• Es Python. Mola y es sencillo de entender.
• Muchas de la funcionalidades que necesitamos (autenticación, plantillas, bases de datos) están suportadas por distintos módulos de Flask.
• Nos permite montar un backend con una API que nos da flexibilidad para usar diversos frontends y diseñar futuras aplicaciones.

Respecto a cómo funcionaría el sistema, existen dos posibilidades.

1. Que la web de reservas actúe como una web con un formulario y peticiones GET /POST al servidor.
2. Que la web de reservas use un framework javascript para hacer peticiones a un backend (API) en nuestro servidor.

La solución 1 tiene la ventaja de ser más sencilla de implementar. La 2, pese a ser algo más complicada, tiene la ventaja de ser más rápida e interactiva. Con la solución 2 también tenemos la posibilidad (si se demuestra su factibilidad) de alojar la web como parte de la web de asrob, usando javascript para hacer peticiones a nuestro backend.

Además, con un backend podríamos modificar nuestro sistema actual de refresco de las webs de impresoras y operadores para que en lugar de por polling, se generen por eventos. Estos eventos serían hooks de GitHub que se configurarían para actúar cada vez que se modifique o cree una issue.

Por último, un backend nos permitiría tener un ASROBot interactivo, aunque no sé si eso es algo bueno o malo 😅

Como dice @Siotma , ya que yo tengo algo de experiencia montando proyectos de Flask, me he ofrecido a crear el esqueleto de un proyecto "Hola mundo" que sirva como base para que podamos construir esta web de reservas, sea cual sea el método elegido.

[David-Estevez]

He creado el repo que alojará el proyecto en https://github.com/asrob-uc3m/printers-management-system. Como primera issue del mismo (asrob-uc3m/printers-management-system#1) está el añadir el esqueleto del proyecto en Flask.