Projet

Général

Profil

Abs2 » Historique » Version 8

Anonyme, 07/01/2009 17:50
Quelques précisions sur la saisie et le traitement.

1 1
= Cahier des charges du module absences 2 =
2
3
 == Avant propos ==
4
5
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.
6
7
 ==== Quelques principes pour le développement ====
8
9
 * 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.
10 2
 * 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.
11 1
 * Le module portera le nom de mod_abs2 dont la structure est déjà présente sur le [browser:trunk/mod_abs2 trunk].
12
 * Il faudra que le code respecte quelques principes (conventions de nomage, DRY, POO).
13
 * 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.
14
 * 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).
15
 * 3 méthodes d'envoi devront être possibles (papier, courriel et sms).
16
17
 == Les fonctionnalités ==
18
19
 === La saisie ===
20
21
 * 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.
22 3
  * => Les différents niveaux de saisie possible (indépendants du statut de l'utilisateur) :
23
   * l'utilisateur peut saisir seulement les élèves auxquels il est rattaché
24 8
    * 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.
25
    * L'interface sera liée (à la demande de l'admin) au module emploi du temps.
26 3
   * l'utilisateur peut saisir tous les élèves de l'établissement
27 8
    * L'interface devra alors permettre de saisir un lot d'élève à partir de la liste de :
28
     * tous les élèves de l'établissement
29
     * tous les élèves d'une classe
30
     * tous les élèves d'un enseignement
31
     * tous les élèves d'une Activité Inter Disciplinaire (AID)
32
    * 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.
33 3
  * => Les "moments" possibles de la saisie
34
   * l'utilisateur peut saisir son niveau d'absence à n'importe quel moment de la journée
35
   * l'utilisateur peut saisir son niveau d'absence en respectant son emploi du temps seulement
36 7
   * L'utilisateur ne peut saisir/modifier des absences que sur la journée d'aujourd'hui ou sur d'autres journées (paramétrable).
37 3
  * => Que peut saisir l'utilisateur ?
38
   * l'utilisateur peut saisir les élèves absents seulement
39
   * l'utilisateur peut corriger une absence en retard
40
   * l'utilisateur peut saisir les élèves absents et ceux en retard
41 4
   * l'utilisateur peut saisir tous les types d'absence (absence, retard, dispense, inclusion, ...)
42 7
  * => Le suivi des appels
43
   * 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)
44
    * sous la forme brute de toutes les saisies
45
    * sous sa forme traitée
46
    * Chaque professeur aura accès à un tableau récapitulatif de ses saisies (par journée, par semaine, par mois).
47
    * 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).
48
   * Toutes les saisies, même sans absent, doivent être enregistrées.
49
    *-> CPE doit avoir accès à un tableau récapitulatif de toutes les saisies (y compris les enregistrements "vides").
50 3
51
 * 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.
52
53
54
 === Le traitement ===
55
56
  ==== Préambule ====
57
58
  * Seuls les personnels autorisés (CPE et statuts personnalisés qui auront ces droits) pourront accéder à cette partie du module
59
60 4
  ==== le traitement en lui même ====
61
 ''comme ça vient ;)''
62 3
63 4
 * Mettre un motif à une absence
64
 * Mettre un type à une absence
65
 * Lancer une action sur une absence
66
 * Allonger/Raccourcir une absence
67
 * Fusionner/regrouper des absences
68
 * Envoyer un courrier/mail/sms aux responsables (responsable 1, 2 ou un simple contact)
69 7
  * 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.
70
  * Assurer le suivi de ce courrier (réponse, relance, ...)
71 4
 * Suivre le retour de ces courriers
72
 * 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,...)
73
 * 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.
74
   * Faire un lien fort avec le module discipline déjà existant sur le trunk
75
 * 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)
76
 * Pouvoir faire des exports sous plusieurs formats (csv, xml, Excell/Calc.OOo, pdf).
77 3
78
79 4
80
81
82
83 1
 === La structure de la base ===
84 5
85
  ==== Modélisation ====
86
87
 Si des codeurs préfèrent modéliser (UML ?) avant de concevoir la base, n'hésitez pas à faire des propositions ??
88
89
  ==== Proposition de structure ====
90
91 1
'' ébauche à continuer et à finir en fonction des échanges ''
92 5
 -> table a_saisies :  ''PRIMARY KEY  (`id`)''[[BR]]
93 3
94
||`id`||int(11)||NOT NULL||auto_increment||-||
95 6
||`utilisateur_id`||varchar(100)||NOT NULL||-||Utilisateurs::login||
96
||`eleve_id`||int(4)||NOT NULL||-||eleves::id_eleve||
97
||`created_on`||int(13)||NOT NULL||default '0'||timestamp UNIX||
98
||`updated_on`||int(13)||NOT NULL||default '0'||timestamp UNIX||
99
||`debut_abs`||int(12)||NOT NULL||default '0'||timestamp UNIX||
100
||`fin_abs`||int(12)||NOT NULL||default '0'||timestamp UNIX||
101 5
[[BR]]
102 1
103
 -> table a_traitements : ''PRIMARY KEY'' (`id`)[[BR]]
104
105 5
||`id`||int(11)||NOT NULL||auto_increment||-||
106
||`a_saisie_id`||varchar(250)||NOT NULL||-||a_saisies::id||
107
||`utilisateur_id`||int(13)||NOT NULL||-||utilisateurs::login||
108 6
||`created_on`||int(13)||NOT NULL||default '0'||timestamp UNIX||
109
||`updated_on`||int(13)||NOT NULL||default '0'||timestamp UNIX||
110 5
||`a_type_id`||int(4)||NOT NULL||-||a_types::id||
111 6
||`a_motif_id`||int(4)||NOT NULL||default '0'||a_motifs_id||
112
||`a_justification_id`||int(4)||NOT NULL||default '0'||a_justications::id||
113 5
||`texte_justification`||varchar(250)||NOT NULL||-||-||
114 6
||`a_action_id`||int(4)||NOT NULL||default '0'||a_actions::id||
115 5
[[BR]]
116 4
117 5
 -> table a_justifications : ''PRIMARY KEY'' (`id`)[[BR]]
118 1
119 5
||`id`||int(11)||NOT NULL||auto_increment||-||
120
||`nom`||varchar(100)||NOT NULL||-||-||
121
||`ordre`||int(3)||NOT NULL||-||-||
122
[[BR]]
123
124
 -> table a_motifs : ''PRIMARY KEY'' (`id`)[[BR]]
125
126
||`id`||int(11)||NOT NULL||auto_increment||-||
127
||`nom`||varchar(100)||NOT NULL||-||-||
128
||`ordre`||int(3)||NOT NULL||-||-||
129
[[BR]]
130
131
 -> table a_types : ''PRIMARY KEY'' (`id`)[[BR]]
132
133
||`id`||int(11)||NOT NULL||auto_increment||-||
134
||`nom`||varchar(100)||NOT NULL||-||-||
135
||`ordre`||int(3)||NOT NULL||-||-||
136
[[BR]]
137
138
 -> table a_actions : ''PRIMARY KEY'' (`id`)[[BR]]
139
140
||`id`||int(11)||NOT NULL||auto_increment||-||
141
||`nom`||varchar(100)||NOT NULL||-||-||
142
||`ordre`||int(3)||NOT NULL||-||-||
143
[[BR]]
144
145
 -> table a_creneaux : ''PRIMARY KEY'' (`id`)[[BR]]
146
147
||`id`||int(11)||NOT NULL||auto_increment||-||
148
||`nom`||varchar(100)||NOT NULL||-||-||
149
||`debut`||int(12)||NOT NULL||-||en nombre de secondes par rapport à 00:00:00||
150
||`fin`||int(12)||NOT NULL||-||en nombre de secondes par rapport à 00:00:00||
151
||`type`||varchar(100)||NOT NULL||-||'cours', 'pause', 'repas'||
152
||`jour`||varchar(100)||NOT NULL||default '9'||-||
153
[[BR]]
154
155
 -> table j_traitement_saisie
156
157
||`a_traitement_id`||int(11)||NOT NULL||-||a_traitements::id||
158
||`a_saisie_id`||int(11)||NOT NULL||-||a_saisies::id||
159
160
161
162
[[BR]]
163
[[BR]]
164
[[BR]]
165
[[BR]]
166 1
167
... @ suivre ...