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

   * L'utilisateur ne peut saisir/modifier des absences que sur la journée d'aujourd'hui ou sur d'autres journées (paramétrable).

  * => 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, ...)

  * => Le suivi des appels

   * Tableau récapitulatif de toutes les saisies de la journée (avec possibilité d'imprimer et/ou d'archiver sous la forme d'un fichier)

    * sous la forme brute de toutes les saisies

    * sous sa forme traitée

    * Chaque professeur aura accès à un tableau récapitulatif de ses saisies (par journée, par semaine, par mois).

    * Permettre (paramétrable) à un professeur principal de voir toutes les saisies (par journée, par semaine, par mois) d'une classe (dont il est PP).

   * Toutes les saisies, même sans absent, doivent être enregistrées.

    *-> CPE doit avoir accès à un tableau récapitulatif de toutes les saisies (y compris les enregistrements "vides").

 * 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)

  * Possibilité de demander des justifications pour plusieurs absences en une seule lettre. Le fichier doit donc proposer sur une seule feuille la liste des absences à justifier.

  * Assurer le suivi de ce courrier (réponse, relance, ...)

 * 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||-||

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

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

||`created_on`||int(13)||NOT NULL||default '0'||timestamp UNIX||

||`updated_on`||int(13)||NOT NULL||default '0'||timestamp UNIX||

||`debut_abs`||int(12)||NOT NULL||default '0'||timestamp UNIX||

||`fin_abs`||int(12)||NOT NULL||default '0'||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||default '0'||timestamp UNIX||

||`updated_on`||int(13)||NOT NULL||default '0'||timestamp UNIX||

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

||`a_motif_id`||int(4)||NOT NULL||default '0'||a_motifs_id||

||`a_justification_id`||int(4)||NOT NULL||default '0'||a_justications::id||

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

||`a_action_id`||int(4)||NOT NULL||default '0'||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 ...