Datos Personales

[rafaelferrero]

En la reunión del día 30/05/2016 se pensaron en algunas directivas y se estableció el primer paso. Como directivas se pensó en que:

• Los registros más importantes no sean borrados físicamente de la base de datos una ves confirmado que son correctos sino que sean ocultos a la visualización de esta forma pueden quedar como registros históricos.
• Los registros ocultos, luego de un determinado tiempo de estar ocultos, sean marcados como históricos de esta forma un proceso podrá recolectarlos en una base de datos de backup y eliminados de la base de datos de producción para reducir su tamaño.
• Se sepa, de los registros más importantes, cuándo y por quién fue creado, cuándo y por quién fue modificado por última vez, y cuándo y por quién fue borrado (o sea indicado como oculto)

Nota: En el sistema anterior se tiene la fecha de ingreso y la fecha de alta, que si bien parecen ser la misma cosa la funcionalidad es bien distinta. La Fecha de Ingreso es la fecha en que la persona que solicita ser Bombero se carga al sistema y la Fecha de Alta es la fecha efectiva en la que persona es Aceptada en la institución. Un caso de uso sería el de hacer una precarga de los datos del solicitante al sistema y luego, mediante "Acta de la Comisión Directiva", se efectiviza su ingreso o no.

Como primer paso se estableció que se programe el módulo para registrar los datos personales de los Bomberos y sus Familiares siguiendos las directivas antes expuestas. Se pensó en una clase llamada Persona y una llamada Bombero que herede de Persona, a su vez una clase que relacione a cada Bombero con otra Persona como Familiar teniendo en cuenta que un Bombero puede tener muchos Familiares y viceversa, siendo cada Familiar una Persona también. Tener en cuenta que una Persona puede haber fallecido debermos también indicar, básicamente cuándo falleció.

Tipos_Documentos

• tipo_documento

Personas

• nombre
• apellido
• tipo_documento (Tipos_Documentos)
• documento
• fecha_nacimiento
• grupo_sanguineo (choice)
• factor_sanguineo (choice)

Fallecidos(Personas)

• fecha_desceso

Bomberos(Personas)

• foto
• fecha_ingreso_institucion
• nro_credencial
• lugar_nacimiento
• estado_civil

Tipos_Parentesco

• tipo_parentesco

Parentescos

• bombero
• persona
• tipo_parentesco

[lokiyin]

rafa falta el rango y el numero de handy (que deberia ser de una clase distinta porque cambia todos los años y tiene que quedar registrado el numero que tubo o que tiene con fecha para las estadisticas .. igual que el rango tiene que tener una fecha cuando dejo el rango y adquirio el otro.)

[rafaelferrero]

Sí Matías!, pero tal y como lo decís vos... deben ser clases aparte y tal vez correspondan a otros modelos. Hagamos foco, en este caso, sólo en los datos personales de los Bomberos y Familiares y su relación entre sí.

[rafaelferrero]

Hay una serie de herramientas que nos pueden servir para las tareas de Soft-Deletion y de Loggin para Auditorias.

http://jameshalsall.co.uk/posts/why-soft-deletes-are-evil-and-what-to-do-instead https://django-simple-history.readthedocs.io/en/latest/ https://github.com/etianen/django-reversion https://github.com/makinacorpus/django-safedelete

Por lo que estuve investigando, crearlo al proyecto durante el desarrollo es bastante sencillo... por lo que en principio podríamos avanzar con las distintas clases y al final podemos hacer un branch para probar el funcionamiento de estas herramientas. Por lo que ví django-simple-history está bastante bueno, simple y permite recuperar información modificada (como si fuera un sistema de control de versiones)

[lokiyin]

recordatorio.. implementar bitacora en el area altura .. importante para llevar el control de los materiales a utilizar.