Sistema de Horas - Timetracking

Anotaciones abajo.

2024/06/11 Reunión con Mauro.

• Meter las validaciones en el deserialize del LegacyEntry.

2024/06/07 pabloso, mauro 11:20 a 13.40

New

dd	mm	yyyy	client	user	topic	subtopic	description	min	billing factor
–	–	––	–––	no estaria	––-	––––	–––––-	–-	–––––––
–	–	––	–––	en la individual	––-	––––	–––––-	–-	–––––––

Legacy

dd	mm	yyyy	user	client	class_	project	issue	desc	duration	billing factor
–	–	––	––-	–––	–––-	–––-	––-	––	––––	–––––––

Consideraciones

• Crear ektodantic
• Mauro propone cambiar nombre de krotolog a kroto, la invocacion sera kroto logs, kroto report … polemica por la frase "La herramienta para cargar horas ES KROTO"
• User, en db de usuario redundante

Artifacts de la reu

Branch en krotolog pydantic (probando_pytdantic.py) para probar las funcionalidades deseadas, a emular en ektodantic,
posiblemente ektodantic se combine con dataclasses.

TODO

[ ] - Primer versión del validación de tipos. (Pabloso, definir fecha)

2024/06/05

Reu pili-pablo

Objerivo diferenciar milestones corto y mediano plazo. Definir a la tarde viabilidad.

Base de datos para cada usuario que se actualice a mitad de mes y a fin de mes -> esta bade de datos tiene que tener la validacion de datos.

-validacion de datos entre los distintos clientes > definir lo más cercano a lo que tenemos andando
-fecha de tres campos. Release: que la fecha sea un solo campo
-user
-topic/subtopic
-billing factor. se usa solo para lynk. release: por default puede ir 1, en caso que uno quiera modificarlo a mano.
-class of work? interno de ektocomms. en que tareas estamos invirtendo el tiempo? solo se usa en lynk. release: estaria bueno considerarlo para tener metricas con los clientes.

Pili se queda con la tarea de avanzar con la documentación de lo que hay hoy en krotolog para ver de mejorarla si hace falta.
Pablo.S Reunión con Especialistas a la tarde

Reu Fito - PSosa - Mauro

Puesta en común

• Validaciones: Conforme a la tabla definida arriba

  • Configuracion por clientes ej: topic y subtopic
  • Toma decisiones gorra, pero solo valida

• Ingesta offline

• Multiusuario

• Quiero cargar en diferido (qué hacemos con el timestamp)

Armar repo con:
- README
- Usuarios
- Clientes
- Validador
- Logs de inputs

Virtualenvs krotolog y otros

188M venv
186M venv_pandas_214
74M venv_django
32M venv_pydantic

23M son sólo del virtualenv pelado apenas creado.

+165M venv
+163M venv_pandas_214
+52M venv_django
+9M venv_pydantic

y unos kB escribirlo nosotros jejej.

TODO

• Charlar con Fran si le parece viable que las formas de ingreso de data al sistema sean contribs.
  Así, lo que hoy es krotolog, sería mudado a contribs (parte de esto), cambiaría de nombre y krotolog
  core quedaría con el validador para cada cliente, una carpeta con las db separadas por usuarios, otra
  con los reportes de los clientes y posiblemente algún archivo de log.
• Valores de categorias, unificar y socializar.

PROXIMA REU - Pablo, Mauro - Viernes 07-06-2024 15hs. - Objetivos: ver que hay en krotolog, darle forma al repo.

2024/06/12 Reu Pablo Mauro

Notas

kroto.vim ojo, puede estar piola jajaja. Podría generar la línea del CSV con placeholders.

Contexto para CLI: por ejemplo desde .env, el usuario actual.

Acciones

• Pablo va a agregar validaciones para year, month y day, individuales, y
  Branch, validate_date.
• para self.time como una validación compuesta de más alto nivel (rango de fecha válido/probable).
• Pablo va agregar ValidationError con un mensaje más explicativo para el caso de cada field de un dataclass.
• Mauro va a fixear el for que borró sin querer. Quedó fixeado en branch pydantic.
• Mauro va a mover archivos para tener el paquete kroto de python. También hacer el commando logs para mergear los logs de los usuarios. Branch paquete…
• Pablo probar cambios 19/06/2024
• Quedan los issues cargados issues
• Demo de la que salgan los tests como artifacts.
• Migrar al uso de la nueva version
• Docu
• [ ]