Gepi

= Cahier des charges du module absences 2 =

 == Avant propos ==

Devant la nécessité de recoder le module absences, nous allons profiter de ce lieu pour établir un cahier des charges le plus complet possible. A cet effet, en fonction des discussions sur les différentes liste de diffusion de gepi, la synthèse sera mise à jour ici même. Tous ceux qui veulent participer à ces échanges sont les bienvenus.

 ==== Quelques principes pour le développement ====

 * Pour éviter de disperser les bonnes volontés, il serait bien qu'une version aboutie soit prète avant la fin de l'année scolaire 2008-2009 pour pouvoir tester en grandeur nature le module dans les établissements.

 * Le choix technologique a été porté sur un outil d'ORM récent et puissant : Propel ([http://propel.phpdb.org/trac/wiki/Users/Documentation/1.3 Doc. officielle] et [wiki:propel traduction partielle]) est en test sinon un motif ActiveRecord adapté à la structure de Gepi fera l'affaire.

 * Le module portera le nom de mod_abs2 dont la structure est déjà présente sur le [browser:trunk/mod_abs2 trunk].

 * Il faudra que le code respecte quelques principes (conventions de nomage, DRY, POO).

 * Ce module devra être lié avec le nouveau module Disciplines de Stéphane Boireau ainsi qu'avec le module emploi du temps. Pour la saisie des absences, on utilisera les AID pour constituer des groupes d'élèves-professeurs-activité. Le module AID devra donc également être lié au module absences.

 * Tous les documents produits par Gepi devront être possibles sous plusieurs formats (html, [browser:trunk/class_php/odf.php open document], [browser:trunk/fpdf pdf], [browser:trunk/class_php/RSSFeed rss], csv).

 * 3 méthodes d'envoi devront être possibles (papier, courriel et sms).

 == Les fonctionnalités ==

 === La saisie ===

 * Chaque utilisateur devra pouvoir disposer de droits bien définis => un professeur ne peut saisir "absent" que des élèves qu'il a en cours par exemple.

  * => Les différents niveaux de saisie possible (indépendants du statut de l'utilisateur) :

   * l'utilisateur peut saisir seulement les élèves auxquels il est rattaché

   * l'utilisateur peut saisir tous les élèves de l'établissement

  * => Les "moments" possibles de la saisie

   * l'utilisateur peut saisir son niveau d'absence à n'importe quel moment de la journée

   * l'utilisateur peut saisir son niveau d'absence en respectant son emploi du temps seulement

  * => Que peut saisir l'utilisateur ?

   * l'utilisateur peut saisir les élèves absents seulement

   * l'utilisateur peut corriger une absence en retard

   * l'utilisateur peut saisir les élèves absents et ceux en retard

   * l'utilisateur peut saisir tous les types d'absence (absence, retard, dispense, inclusion, ...)

 * Il faudra prévoir d'utiliser les statuts personnalisés pour permettre à un administrateur de créer des utilisateurs avec des droits particuliers sur ses fonctionnalités.

 === Le traitement ===

  ==== Préambule ====

  * Seuls les personnels autorisés (CPE et statuts personnalisés qui auront ces droits) pourront accéder à cette partie du module

  ==== le traitement en lui même ====

 ''comme ça vient ;)''

 * Mettre un motif à une absence

 * Mettre un type à une absence

 * Lancer une action sur une absence

 * Allonger/Raccourcir une absence

 * Fusionner/regrouper des absences

 * Envoyer un courrier/mail/sms aux responsables (responsable 1, 2 ou un simple contact)

 * Suivre le retour de ces courriers

 * Avoir accès très rapidement sur la liste des absents à toutes les informations concernant l'élève absent (numéro de téléphone, adresse, bilan de ses absences,...)

 * Pouvoir faire des statistiques sur chaque classe, chaque élève, chaque type d'absence, en tenant compte du nombre de jour, de la discipline, du professeur, du régime.

   * Faire un lien fort avec le module discipline déjà existant sur le trunk

 * Lire le bilan de la saisie "fond de salle" dans un seul tableau en précisant le nombre d'absents total (avec également une distinction par régime)

 * Pouvoir faire des exports sous plusieurs formats (csv, xml, Excell/Calc.OOo, pdf).

 === La structure de la base ===

  ==== Modélisation ====

 Si des codeurs préfèrent modéliser (UML ?) avant de concevoir la base, n'hésitez pas à faire des propositions ??

  ==== Proposition de structure ====

'' ébauche à continuer et à finir en fonction des échanges ''

 -> table a_saisies :  ''PRIMARY KEY  (`id`)''[[BR]]

||`id`||int(11)||NOT NULL||auto_increment||-||

||`utilisateurs_id`||varchar(100)||NOT NULL||-||Utilisateurs::login||

||`eleves_id`||int(4)||NOT NULL||-||eleves::id_eleve||

||`date_saisie`||int(13)||NOT NULL||-||timestamp UNIX||

||`debut_abs`||int(12)||NOT NULL||-||timestamp UNIX||

||`fin_abs`||int(12)||NOT NULL||-||timestamp UNIX||

[[BR]]

 -> table a_traitements : ''PRIMARY KEY'' (`id`)[[BR]]

||`id`||int(11)||NOT NULL||auto_increment||-||

||`a_saisie_id`||varchar(250)||NOT NULL||-||a_saisies::id||

||`utilisateur_id`||int(13)||NOT NULL||-||utilisateurs::login||

||`created_on`||int(13)||NOT NULL||-||timestamp UNIX||

||`update_on`||int(13)||NOT NULL||-||timestamp UNIX||

||`a_type_id`||int(4)||NOT NULL||-||a_types::id||

||`a_motif_id`||int(4)||NOT NULL||-||a_motifs_id||

||`a_justification_id`||int(4)||NOT NULL||-||a_justications::id||

||`texte_justification`||varchar(250)||NOT NULL||-||-||

||`a_action_id`||int(4)||NOT NULL||-||a_actions::id||

[[BR]]

 -> table a_justifications : ''PRIMARY KEY'' (`id`)[[BR]]

||`id`||int(11)||NOT NULL||auto_increment||-||

||`nom`||varchar(100)||NOT NULL||-||-||

||`ordre`||int(3)||NOT NULL||-||-||

[[BR]]

 -> table a_motifs : ''PRIMARY KEY'' (`id`)[[BR]]

||`id`||int(11)||NOT NULL||auto_increment||-||

||`nom`||varchar(100)||NOT NULL||-||-||

||`ordre`||int(3)||NOT NULL||-||-||

[[BR]]

 -> table a_types : ''PRIMARY KEY'' (`id`)[[BR]]

||`id`||int(11)||NOT NULL||auto_increment||-||

||`nom`||varchar(100)||NOT NULL||-||-||

||`ordre`||int(3)||NOT NULL||-||-||

[[BR]]

 -> table a_actions : ''PRIMARY KEY'' (`id`)[[BR]]

||`id`||int(11)||NOT NULL||auto_increment||-||

||`nom`||varchar(100)||NOT NULL||-||-||

||`ordre`||int(3)||NOT NULL||-||-||

[[BR]]

 -> table a_creneaux : ''PRIMARY KEY'' (`id`)[[BR]]

||`id`||int(11)||NOT NULL||auto_increment||-||

||`nom`||varchar(100)||NOT NULL||-||-||

||`debut`||int(12)||NOT NULL||-||en nombre de secondes par rapport à 00:00:00||

||`fin`||int(12)||NOT NULL||-||en nombre de secondes par rapport à 00:00:00||

||`type`||varchar(100)||NOT NULL||-||'cours', 'pause', 'repas'||

||`jour`||varchar(100)||NOT NULL||default '9'||-||

[[BR]]

 -> table j_traitement_saisie

||`a_traitement_id`||int(11)||NOT NULL||-||a_traitements::id||

||`a_saisie_id`||int(11)||NOT NULL||-||a_saisies::id||

[[BR]]

[[BR]]

[[BR]]

[[BR]]

... @ suivre ...