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 (Doc. officielle et 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 informations disponibles lors de la saisie :
    • Les utilisateurs CPE auront l'edt de l'élève lors de la saisie des absences (popup en mouseover et click pour le fermer).
    • Les professeurs pourront voir leur propre edt et ainsi vérifier s'ils ont bien saisie les absences lors de leurs cours (couleur différente).
  • => 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'interface de saisie devra permettre de voir le suivi sur chaque créneau de la journée ainsi qu'une information sur la saisie de la veille.
      • L'interface sera liée (à la demande de l'admin) au module emploi du temps.
      • L'utilisateur pourra ou pas modifier le créneau et la date de la saisie.
    • l'utilisateur peut saisir tous les élèves de l'établissement
      • L'utilisateur pourra ne saisir que les présents (si l'admin le permet).
      • L'interface devra alors permettre de saisir un lot d'élève à partir de la liste de :
        • tous les élèves de l'établissement
        • tous les élèves d'une classe
        • tous les élèves d'un enseignement
        • tous les élèves d'une Activité Inter Disciplinaire (AID)
      • L'interface devra permettre par un simple coche de préciser que l'absence dure toute la journée sans devoir nécessairement préciser les créneaux d'absence.
  • => 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").
• Pouvoir rentrer des absences a priori sans que ça provoque l'envoi de lettres aux parents ......
• 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,...)
• Prévoir un motif d'absence qui ne donne pas lieu à l'envoi de lettre comme pour les voyages scolaire, concours, journée d'appel,...
• 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).

  ==== le suivi du courrier ====

Tout reste à définir exactement avec les futurs et actuels utilisateurs.

==== Les interfaces des utilisateurs ====

• Lors de la consultation de la fiche d'un élève par un cpe, avoir une récapitulation de ses dernières absences sans avoir à donner un intervalle de date
• Prévoir l'affichage du motif de l'absence (maladie, décès etc ....) dans l'interface de l'enseignant

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

	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

-> table a_traitements : PRIMARY KEY (id)

	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

-> table a_justifications : PRIMARY KEY (id)

	id		int(11)		NOT NULL		auto_increment		-
	nom		varchar(100)		NOT NULL		-		-
	ordre		int(3)		NOT NULL		-		-

-> table a_motifs : PRIMARY KEY (id)

	id		int(11)		NOT NULL		auto_increment		-
	nom		varchar(100)		NOT NULL		-		-
	ordre		int(3)		NOT NULL		-		-

-> table a_types : PRIMARY KEY (id)

	id		int(11)		NOT NULL		auto_increment		-
	nom		varchar(100)		NOT NULL		-		-
	ordre		int(3)		NOT NULL		-		-

-> table a_actions : PRIMARY KEY (id)

	id		int(11)		NOT NULL		auto_increment		-
	nom		varchar(100)		NOT NULL		-		-
	ordre		int(3)		NOT NULL		-		-

-> table a_creneaux : PRIMARY KEY (id)

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

-> table j_traitement_saisie

	a_traitement_id		int(11)		NOT NULL		-		a_traitements::id
	a_saisie_id		int(11)		NOT NULL		-		a_saisies::id

... @ suivre ...