Idees per als models de dades de l'IMS

[FherStk]

Bona tarda companys,

Aquest missatge té dos objectius:

1. Provar fins a quin punt ens resulta còmode i productiu coordinar-nos i comunicar-nos amb les discussions de GitHub.
2. Fer-nos una idea de quin model de dades inicial ens cal per a desenvolupar les dues funcionalitats amb les quals volem arrencar: el sistema de control d'assistència a classe i el sistema de gestió d'actes.

Recordeu que a la wiki teniu tot el necessari per a poder configurar-vos un entorn de treball i començar a fer proves amb Odoo.

Com sabeu, Odoo ens proporciona un sistema integral i, per tant, tots els models de dades són susceptibles de relacionar-se amb altres i caldria establir un criteri per a evitar duplicitats i simplificar el sistema al màxim abans de començar el desenvolupament per separat de les dues funcionalitats que es volen implementar.

Faig un petit compendi dels models de dades que crec que ens faran falta, amb la idea de posar-nos d'acord i que tots puguem aportar idees i opinions. Aprofito també per a rescatar el que va comentar l'Òscar a l'última reunió de l'IMS que vàrem tenir: el Víctor va desenvolupar una aplicació per a controlar l'assistència a l'aula i d'aquesta experiència en podem treure molt profit per a agilitzar el desenvolupament.

Funcionament

Per entendre el perquè dels models de dades, afegeixo enllaços al funcionament que es proposa per cada part de l'IMS:

• Control d'assistència: Funcionalitats del control d'assistència #2 (comment)
• Gestió d'actes: Funcionalitats de la gestió d'actes #3 (comment)

Models de dades

En funció de l'anterior, exposo un llistat dels models de dades (sense detall) repartit per funcionalitat, la idea és veure si es repeteixen (cal tenir en compte que Odoo afegirà un camp ID autonumèric de forma automàtica, així com informació extra per a la traçabilitat):

Assistència

• Plantilla

  • Relació cap a 1 Nivell (ESO/BTX/CFGM/CFGS).
  • Relació cap a 1 Estudi (DAM/ASIX/GA/AIF/ESO/BTX; potser per a BTX caldria separar l'especialitat?).
  • Relació cap a 1 MP.
  • Relació cap a 0-1 UF.
  • Relació cap a 1 Aula.
  • Hora d'inici.
  • Hora final.
  • Relació cap a 1-N Professor.
  • Relació cap a 1-N Alumne.

• Assistència

  • Mateixes dades que la plantilla (es genera en funció d'aquesta, però són independents per a mantenir un històric i permetre més flexibilitat).
  • Relació cap a 1-N Estat (professor). Per cada professor, cal marcar si hi és present (el professor que està passant llista ja apareix marcat de forma automàtica; atenció, en cas de guàrdia, s'afegirà el professor de guàrdia com a assistent).
  • Relació cap a 1-N Estat (alumne). Per cada alumne, cal marcar el seu estat (present, que és el predeterminat; absent; retard; incidència; etc.). Es podria donar el cas de tenir un retard i que després generés en una expulsió. Cal valorar si és necessari complicar la lògica per a mantenir aquesta informació (potser no, haurien de ser pocs casos).

• Nivell

  • Nom

• Estudi

  • Codi
  • Nom

• MP

  • Codi
  • Nom

• UF

  • Codi
  • Nom

• Aula

  • Codi
  • Nom

• Professor (pot heretar del model "res_partner" d'Odoo, que és el que Odoo fa servir per a clients, proveïdors, usuaris, etc.).

  • Nom
  • Cognoms
  • Correu electrònic

• Alumne (pot heretar del model "res_partner" d'Odoo, que és el que Odoo fa servir per a clients, proveïdors, usuaris, etc.).

  • Nom
  • Cognoms
  • Correu electrònic
  • Relació cap a 1-N Seguiment

• Seguiment

  • Relació cap a 1 Professor (el que ha introduït l'entrada).
  • Relació cap a 1-N Document.
  • Relació cap a 1 Estudi (per tenir històric general per nivell d'estudis).
  • Relació cap a 1 MP (opcional, per tenir comentaris de l'alumne a nivell de MP).
  • Relació cap a 1 UF (opcional, per tenir comentaris de l'alumne a nivell de UF).
  • Comentaris (camp de text lliure)

• Document

  • Cal mirar com ho gestiona Odoo, per aprofitar-ho i, de ser possible, tenir un històric de versions.

• Estat

  • Relació cap a 1 Alumne o Professor
  • Relació cap a 1 Assistència
  • Valor (assistència; retard; absència sense justificar; absència justificada; incidència, potser caldria separar per tipus d'incidència?). Cal tenir en compte que l'eina, en el cas dels professors, només permetrà marcar absència o assistència.
  • Comentaris.

Actes

Cañ tenir en compte que el Coordinador de Qualitat és l'encarregat de coordinar la documentació i, per tant, és l'usuari que ha de poder crear plantilles noves a disposició del centre i decidir com s'han de veure aquestes plantilles. Tanmateix, un professor que crea una nova acta de reunió pel seu departament podria veure interessant crear una "subplantilla" on tingui definits els assistents, lloc de la reunió, etc.

• Plantilla:

  • Relació cap a 1 Tipus
  • Descripció
  • Relació cap a 1-N Bloc (bloc o ítem, és contingut de l'ordre del dia).

• SubPlantilla (a nivell d'implementació, Plantilla i SubPlantilla podrien ser el mateix model de dades):

  • Nom
  • Descripció
  • Relació cap a 1 Plantilla
  • Relació cap a 1 Aula
  • Relació cap a 1 Modalitat
  • Relació cap a 1-N Persona (poden ser Professors, Alumnes, PAS, etc.).

• Tipus

  • Nom
  • Descripció

• Aula

  • Ja ha sortit definida dins l'apartat d'assistència.

• Modalitat

  • Nom
  • Descripció

• Persona

  • Aquí es veu la necessitat de disposar d'un model Persona per a agrupar a alumnes, professors, PAS, etc. Si tots aquests models hereten del "res_partner" d'Odoo, es pot fer servir com a superclasse. Altrament, podem fer la nostra pròpia classe "Persona" i fer que la resta n'heretin d'aquesta. Potser ens queda més net i més independent.

• Bloc (cal tenir en compte que cada bloc tindrà un comportament diferent en el moment de generar una acta a partir d'una plantilla).

  • Nom.
  • Descripció.

• Acta

  • Mateixes dades que la plantilla (es genera en funció d'aquesta, però són independents per a mantenir un històric i permetre més flexibilitat).
  • Relació cap a 1-N Contingut (és el contingut de cada bloc).
  • Relació cap a 1 Persona (el responsable de signar l'acta).
  • Relació cap a 1-N Persona (els que poden veure l'acta, read-only).
  • Relació cap a 1-N Persona (els que poden modificar l'acta).
  • Relació cap a 1 Signatura (si el responsable ha signat o no).

• Contingut

  • Relació cap a 1 Acta.
  • Relació cap a 1 Bloc.
  • Tota la informació necessària per a aquest bloc.

• Signatura

  • Es fa en un model diferent perquè Odoo pugui fer el tracking de qui, quan, etc.
  • Signada (si/no). Només la persona responsable la pot signar, qualsevol modificació a l'acta fa que sigui necessari firmar-la de nou. Odoo guarda de forma automàtica quin usuari ha modificat un registre i quan (sense històric, només l'última vegada), per tant, comparant dates es podria saber si la signatura de l'acta és vàlida o cal singar-la de nou.

[jmanelgithub]

Respecte el model de asistencia.
Jo trobo mes senzill distingir entre estat_alumne i estat_profe, ja que a asistencia esta separat, que apunti a dos taulas diferents.
Trobo que falta una relacio al objecte alumne que el relacioni amb una taula documents que contingui els documents pujats pel profesor (seria una relacio 1 a N).

[FherStk]

Respecte la documentació, és correcte, de fet faltaria tota la part de la fitxa de l'alumne (on s'inclou la documentació, comentaris, seguiment, etc.).

Respecte dels estats, crec que simplifica més tenir una única taula. Des d'assistència es tindrà la relació cap a l'estat (amb el seu valor) i aquí dirà si és d'alumne o de profe (la clau forana pot ser null en un dels dos casos). Fer dos taules d'estat implicaria les dos claus foranes a assistència, i una taula extra que de l'altra forma ens estalviem.

[FherStk]

He actualitzat el post original.

[q2dg]

teachers.xml.txt

Hola. Només per a què us feu a la idea del format que genera el FET i que l'Ieduca "es menja" per generar els horaris tan bonics amb quadrets de colors, us passo l'arxiu XML dels horaris d'aquest any. No sé si servirà d'ajuda en algun moment, però més que res per si s'opta, en algun moment, per automatitzar la generació d'horaris d'alguna manera.

Salut!

[FherStk]

Genial! Lo meto en la wiki :)

https://github.com/ElPuig/IMS/wiki/3.-FAQs-and-utils#document-xml-amb-horaris-importable-per-ieduca

[FherStk]

Actualitzo el post original, he mogut la informació cap a les noves discussions (no he esborrat res, només ho he reubicat).

[FherStk]

Bona tarda,

Actualitzo amb informació que ens fa arribar en @vcarceler, ens comenta:

[...] una pincelada de cómo estaba montado lo de las clases en AttendanceManager por si es de utilidad.
Al final todo giraba entorno a un "classblock" que representaba una bloque lectivo (una clase concreta en el horario de un grupo).

La tabla era:

DROP TABLE IF EXISTS `classblock`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `classblock` (
  `idclassblock` int(11) NOT NULL AUTO_INCREMENT,
  `teacher_idteacher` int(11) NOT NULL,
  `subject_idsubject` int(11) NOT NULL,
  `group_idgroup` int(11) NOT NULL,
  `term_idterm` int(11) NOT NULL,
  `day_of_week` int(11) NOT NULL COMMENT '1=sunday,\n2=monday,\n...',
  `start` time NOT NULL,
  `end` time NOT NULL,
  PRIMARY KEY (`idclassblock`),
  KEY `fk_classblock_subject1` (`subject_idsubject`),
  KEY `fk_classblock_group1` (`group_idgroup`),
  KEY `fk_classblock_term1` (`term_idterm`),
  KEY `fk_classblock_teacher1` (`teacher_idteacher`),
  CONSTRAINT `fk_classblock_group1` FOREIGN KEY (`group_idgroup`) REFERENCES `group` (`idgroup`) ON DELETE CASCADE ON UPDATE NO ACTION,
  CONSTRAINT `fk_classblock_subject1` FOREIGN KEY (`subject_idsubject`) REFERENCES `subject` (`idsubject`) ON DELETE CASCADE ON UPDATE NO ACTION,
  CONSTRAINT `fk_classblock_teacher1` FOREIGN KEY (`teacher_idteacher`) REFERENCES `teacher` (`idteacher`) ON DELETE CASCADE ON UPDATE NO ACTION,
  CONSTRAINT `fk_classblock_term1` FOREIGN KEY (`term_idterm`) REFERENCES `term` (`idterm`) ON DELETE CASCADE ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=6081 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

Y ahí teníamos el id de la clase, del profesor, del grupo, de la materia, del plazo en el que se imparte, día de la semana y hora de inicio/fin.

Los grupos eran colecciones de alumnos. Y la interfaz permitía lo que tú propones de poner y quitar alumnos de un grupo para que se ajuste a lo que tienes en clase. Teníamos el concepto de grupos anidados para hacer especializaciones rápidas (es decir los mismos alumnos que otro grupo pero añadiendo a alguien) aunque esto es un poco loco y no estoy seguro de que mole tanto.

Total la interfaz te puede ayudar a insertar en tu grupo, el que sea que te estás creando, los alumnos que forman parte de otro grupo de golpe.

Cada UF era una materia (subject) independiente pero nosotros utilizábamos una notación tal que CICLO - GRUPO - MP - UF para identificarlas.

Recuerdo que aunque teníamos varios tipos de faltas (miss)

DROP TABLE IF EXISTS `miss`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `miss` (
  `idmiss` int(11) NOT NULL AUTO_INCREMENT,
  `type` int(11) NOT NULL COMMENT 'Permite distinguir entre: falta, falta justificada, incidencia, expulsión',
  `date` date NOT NULL,
  `comment` varchar(255) DEFAULT NULL,
  `student_idstudent` int(11) NOT NULL,
  `teacher_idteacher` int(11) NOT NULL,
  `subject_idsubject` int(11) NOT NULL,
  `classblock_idclassblock` int(11) NOT NULL,
  PRIMARY KEY (`idmiss`),
  UNIQUE KEY `unique_miss` (`type`,`date`,`student_idstudent`,`teacher_idteacher`,`subject_idsubject`,`classblock_idclassblock`),
  KEY `fk_miss_student1` (`student_idstudent`),
  KEY `fk_miss_teacher1` (`teacher_idteacher`),
  KEY `fk_miss_subject1` (`subject_idsubject`),
  KEY `fk_miss_classblock1` (`classblock_idclassblock`),
  CONSTRAINT `fk_miss_classblock1` FOREIGN KEY (`classblock_idclassblock`) REFERENCES `classblock` (`idclassblock`) ON DELETE CASCADE ON UPDATE NO ACTION,
  CONSTRAINT `fk_miss_student1` FOREIGN KEY (`student_idstudent`) REFERENCES `student` (`idstudent`) ON DELETE CASCADE ON UPDATE NO ACTION,
  CONSTRAINT `fk_miss_subject1` FOREIGN KEY (`subject_idsubject`) REFERENCES `subject` (`idsubject`) ON DELETE CASCADE ON UPDATE NO ACTION,
  CONSTRAINT `fk_miss_teacher1` FOREIGN KEY (`teacher_idteacher`) REFERENCES `teacher` (`idteacher`) ON DELETE CASCADE ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=88988 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

No registrábamos las asistencias. Es decir, registrábamos las faltas, retrasos, expulsiones, etc.. pero no las asistencias. Y quien no tuviera falta pues se suponía que había venido.

Pero no estoy seguro de que no valga la pena registrar las asistencias.