forked from ScoDoc/DocScoDoc
Compare commits
125 Commits
etat_civil
...
master
Author | SHA1 | Date | |
---|---|---|---|
0720b783fe | |||
508e1b1f7e | |||
c93a8799e4 | |||
ab649db429 | |||
1af13c23b7 | |||
01a51e3d1d | |||
a698c80f7b | |||
75eacf1e73 | |||
8528217d5f | |||
cdf4beb008 | |||
b9309c9a1e | |||
|
83efd5fe7d | ||
|
ffba18c883 | ||
a995e3f886 | |||
|
c688bf6578 | ||
71e0a0270c | |||
4f4519c543 | |||
8e5f8684f7 | |||
|
85d0271ec2 | ||
5f44559b76 | |||
85552f28d7 | |||
43d13366eb | |||
024f95d9f6 | |||
7975ecf2d2 | |||
328e3766b7 | |||
3160671095 | |||
bd17e29efe | |||
cb564c975f | |||
92cb7b951f | |||
|
34497e429f | ||
|
7a6381082e | ||
3541513a3d | |||
9fb95aa3ac | |||
6b4eca11e5 | |||
6b8a988b28 | |||
195530fd26 | |||
54863f24ad | |||
8180bae87f | |||
843a566ed9 | |||
f97d117211 | |||
|
aba125c524 | ||
d651b3e2d7 | |||
c687db297c | |||
f9caeb90f3 | |||
833a35a037 | |||
|
58e3ee9500 | ||
|
7ef0f108b4 | ||
56fa613fcc | |||
ba52e8df33 | |||
78ecbcbe44 | |||
374c8db9b4 | |||
5505f733b0 | |||
0e81ca5d5d | |||
8a8ce91267 | |||
bd8e5d38cc | |||
dccb94bcdd | |||
f44095c768 | |||
7995348749 | |||
4aff3a212f | |||
2bda0c0dd0 | |||
85fdb885cc | |||
4c58b40eef | |||
137930a24d | |||
844388adac | |||
d426b83c19 | |||
b63c26fea5 | |||
60f3ef841e | |||
94d0644b9f | |||
40a6d54f76 | |||
5b9321183f | |||
6976a485b2 | |||
3a9d58f9e0 | |||
1154040ceb | |||
a57dd34bf9 | |||
78e2cef813 | |||
03f5b6800c | |||
1936ed47d2 | |||
a7be700a13 | |||
a17e8c1fe2 | |||
02c1be40dd | |||
e9ebe637ee | |||
bf68f0b1a7 | |||
5032e9fb23 | |||
5d0c429ace | |||
0fb62b79bf | |||
a83326ef2e | |||
b89cae6d13 | |||
5d0fc8bbdc | |||
72f89d42b0 | |||
0d48079a51 | |||
54f73f476d | |||
|
ebe4e92639 | ||
|
8ce0af10e8 | ||
beca815be2 | |||
9b290fe0fa | |||
2082ae84ca | |||
bcf99e292d | |||
23a2609833 | |||
8ce4ca0f28 | |||
cf57787c45 | |||
d5ff90dc7f | |||
055a85e274 | |||
007987db88 | |||
70424eba78 | |||
ed8c651df6 | |||
23642a9910 | |||
ad48bd04b6 | |||
c009fc95b2 | |||
7d27cf8bfa | |||
085e5c35c1 | |||
dd968bac02 | |||
27a43efb5a | |||
1b138b7b8d | |||
514cb016fb | |||
90d0f1b086 | |||
7e316463e6 | |||
fb2adf40a6 | |||
65bc5d304c | |||
290f967e32 | |||
5c9c8e8947 | |||
7813a14bc7 | |||
|
563edf93c1 | ||
|
447d654928 | ||
|
0c171ae072 | ||
6a774a7271 |
19
README.md
19
README.md
@ -21,8 +21,9 @@ Il est recommandé de créer un virtualenv:
|
||||
python3.11 -m venv venv
|
||||
source venv/bin/activate
|
||||
```
|
||||
(n'importe quelle version de python récente fera l'affaire).
|
||||
|
||||
puis d'y installer les composants suivants:
|
||||
Puis installer les composants suivants dans ce virtualenv:
|
||||
|
||||
```bash
|
||||
pip install mkdocs
|
||||
@ -31,8 +32,24 @@ pip install mkdocs-material
|
||||
pip install mkdocs-plugin-inline-svg
|
||||
```
|
||||
|
||||
## Génération de la doc
|
||||
|
||||
Pour générer le site:
|
||||
|
||||
```bash
|
||||
mkdocs build
|
||||
```
|
||||
|
||||
Pour lancer un serveur local permettant d'afficher la doc, avec rafraichissement
|
||||
automatique dès qu'un fichier source est modifié:
|
||||
|
||||
```bash
|
||||
mkdocs serve
|
||||
```
|
||||
|
||||
Pour le reste voir la documentation de [MkDocs](https://www.mkdocs.org/).
|
||||
|
||||
## WIP
|
||||
|
||||
- reprendre la page BUT.md
|
||||
-
|
@ -1,28 +1,39 @@
|
||||
# Génération des bulletins en Python
|
||||
|
||||
# Générer des bulletins en Python
|
||||
Il est possible de coder de nouveaux styles de bulletins de notes (web et/ou PDF), pour répondre précisément aux besoins de votre établissement.
|
||||
Informations internes à destination des développeurs.
|
||||
|
||||
Ce n'est pas très difficile, mais il faudra coder en langage Python avec pour le PDF la bibliothèque ReportLab (qui est bien documentée, [voir le guide](http://www.reportlab.com/software/opensource/rl-toolkit/guide/)).
|
||||
## Types de bulletins
|
||||
|
||||
ScoDoc demande la création d'un bulletin pour un étudiant donné dans semestre donné (`formsemestre_id`).
|
||||
Le bulletin doit être rendu sous forme d'une liste d'objets PLATYPUS (voir le chapitre 5 du "User Guide" de ReportLab cité plus haut).
|
||||
- Formations classiques
|
||||
- HTML, court, intermédiaire, long
|
||||
- XML (deprecated)
|
||||
- JSON
|
||||
- PDF
|
||||
- Formations BUT
|
||||
- JSON (utilisé par la version HTML)
|
||||
- XML (partiel, deprecated)
|
||||
- PDF
|
||||
- "but court" HTML
|
||||
- "but court" PDF
|
||||
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> Attention (août 2011): nouvelle version, changement d'API: les informations ci-dessous s'appliquent à partir de la subversion 1047.
|
||||
## Balises décisions de jury pour chaque type
|
||||
|
||||
|
||||
## Organisation
|
||||
A minima, il vous faut créer un module python (fichier .py) qui se définira une classe chargée de générer vos bulletins.
|
||||
|
||||
## Organisation
|
||||
|
||||
A minima, il vous faut créer un module python (fichier .py) qui se définira une
|
||||
classe chargée de générer vos bulletins.
|
||||
|
||||
Ce fichier doit être placé dans le répertoire `/opt/scodoc/instance/Products/ScoDoc`
|
||||
|
||||
Il faut aussi l'importer dans `sco_bulletins_generator.py` (voir tout à la fin de ce fichier).
|
||||
Il faut aussi l'importer dans `sco_bulletins_generator.py` (voir tout à la fin
|
||||
de ce fichier).
|
||||
|
||||
Voici un module minimal commenté (le fichier `sco_bulletins_example.py` est fournit avec ScoDoc):
|
||||
```
|
||||
#!python
|
||||
# -*- mode: python -*-
|
||||
# -*- coding: utf-8 -*-
|
||||
Voici un module minimal commenté (le fichier `sco_bulletins_example.py` est
|
||||
fournit avec ScoDoc):
|
||||
|
||||
```py
|
||||
"""Génération d'un bulletin de note style "Exemple"
|
||||
(commentaire libre ici)
|
||||
"""
|
||||
@ -47,7 +58,7 @@ class [BulletinGeneratorExample](BulletinGeneratorExample.md)(sco_bulletins_stan
|
||||
# .bul_part_below(self, format=*) : infos sous la table
|
||||
# .bul_signatures_pdf(self) : signatures
|
||||
|
||||
def bul_table(self, format=*):
|
||||
def bul_table(self, fmt=*):
|
||||
"""Défini la partie centrale de notre bulletin PDF.
|
||||
Doit renvoyer une liste d'objets PLATYPUS
|
||||
"""
|
||||
@ -58,23 +69,27 @@ class [BulletinGeneratorExample](BulletinGeneratorExample.md)(sco_bulletins_stan
|
||||
)
|
||||
]
|
||||
|
||||
# Déclarer votre classe à [ScoDoc](ScoDoc.md):
|
||||
sco_bulletins_generator.register_bulletin_class(BulletinGeneratorExample)
|
||||
# Déclarer votre classe à ScoDoc
|
||||
sco_bulletins_generator.register_bulletin_class(BulletinGeneratorExample)
|
||||
```
|
||||
|
||||
Si l'on voulait générer aussi du HTML (pour la version web), il suffirait de le déclarer dans la liste `supported_formats` et que la méthode `bul_table()` renvoie une chaîne HTML si le paramètre format vaut `'html'`.
|
||||
Si l'on voulait générer aussi du HTML (pour la version web), il suffirait de le
|
||||
déclarer dans la liste `supported_formats` et que la méthode `bul_table()`
|
||||
renvoie une chaîne HTML si le paramètre `fmt` vaut `'html'`.
|
||||
|
||||
|
||||
Pour modifier l'en-tête du bulletin PDF (partie au dessus de la table), il faut surcharger la méthode `bul_title_pdf` qui elle aussi renvoie une liste d'objets PLATYPUS:
|
||||
```
|
||||
#!python
|
||||
Pour modifier l'en-tête du bulletin PDF (partie au dessus de la table), il faut
|
||||
surcharger la méthode `bul_title_pdf` qui elle aussi renvoie une liste d'objets
|
||||
PLATYPUS:
|
||||
|
||||
```py
|
||||
def bul_title_pdf(self):
|
||||
...
|
||||
```
|
||||
|
||||
De même, les informations placées sous la table principale sont renvoyées par la méthode `gen_part_below`:
|
||||
```
|
||||
#!python
|
||||
|
||||
```py
|
||||
def gen_part_below(self, format=*):
|
||||
"""Génère les informations placées sous la table de notes
|
||||
(absences, appréciations, décisions de jury...)
|
||||
@ -85,104 +100,75 @@ De même, les informations placées sous la table principale sont renvoyées par
|
||||
...
|
||||
```
|
||||
|
||||
et les signatures (seulement sur le PDF) par `bul_signatures_pdf`. Toutes ces méthodes renvoient des listes d'objets PLATYPUS quelconques.
|
||||
et les signatures (seulement sur le PDF) par `bul_signatures_pdf`. Toutes ces
|
||||
méthodes renvoient des listes d'objets PLATYPUS quelconques.
|
||||
|
||||
Vous pouvez partir d'un format de bulletin existant et proche de ce que voulez obtenir et définir une sous-classe modifiant (surchargeant) seulement les méthodes qui génèrent les éléments que vous voulez modifier.
|
||||
Vous pouvez partir d'un format de bulletin existant et proche de ce que voulez
|
||||
obtenir et définir une sous-classe modifiant (surchargeant) seulement les
|
||||
méthodes qui génèrent les éléments que vous voulez modifier.
|
||||
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> Attention: ne pas modifier après coup le nom des classes de générateurs (ici `BulletinGeneratorExample`), car il va être stocké en base de données par ScoDoc.
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
|
||||
alt="/!\" /> Attention: ne pas modifier après coup le nom des classes de
|
||||
générateurs (ici `BulletinGeneratorExample`), car il va être stocké en base de
|
||||
données par ScoDoc.
|
||||
|
||||
## Accès aux informations
|
||||
|
||||
La plupart des informations nécessaires sont accessibles via des attributs de
|
||||
votre instance de générateur que ScoDoc aura positionné avant d'appeler vos
|
||||
méthodes. Notamment:
|
||||
|
||||
* `self.formsemestre`: l'objet `FormSemestre`
|
||||
* `self.infos`: un (grand) dictionnaire python avec la plupart des informations
|
||||
préparée pour le bulletin à générer (voir plus loin);
|
||||
* `self.version`: indique la version de bulletin demandée par l'utilisateur
|
||||
("long" ou "short", vous pouvez en faire ce que bon vous semble);
|
||||
|
||||
## Le dictionnaire d'informations
|
||||
|
||||
L'attribut `infos` est un dictionnaire qui contient de très nombreuses
|
||||
informations. il doit être utilisé en **lecture seule** (il est possible que des
|
||||
informations soient partagées entre threads différents, aussi les modifier peut
|
||||
avoir des effets indésirables). .
|
||||
|
||||
|
||||
## Accès aux informations
|
||||
La plupart des informations nécessaires sont accessibles via des attributs de votre instance de générateur que ScoDoc aura positionné avant d'appeler vos méthodes. Notamment:
|
||||
* `self.infos`: un (grand) dictionnaire python avec la plupart des informations préparée pour le bulletin à générer (voir plus loin);
|
||||
* `self.version`: indique la version de bulletin demandée par l'utilisateur ("long" ou "short", vous pouvez en faire ce que bon vous semble);
|
||||
* `self.context`: contexte ScoDoc, permettant l'accès à l'API complète.
|
||||
### Paramètres (préférences)
|
||||
|
||||
Tous les paramètres du semestre sont accessibles via leur nom. Voir la liste sur
|
||||
la page [NomsPreferences](NomsPreferences.md).
|
||||
|
||||
## Le dictionnaire d'informations
|
||||
L'attribut `infos` est un dictionnaire qui contient de très nombreuses informations. il doit être utilisé en **lecture seule** (il est possible que des informations soient partagées entre threads différents, aussi les modifier peut avoir des effets indésirables). .
|
||||
Exemple: `infos['SCOLAR_FONT_SIZE']` est un entier, `infos['UnivName']` est le
|
||||
nom de l'université.
|
||||
|
||||
### Informations sur l'étudiant
|
||||
|
||||
### Paramètres (préférences)
|
||||
Tous les paramètres du semestre sont accessibles via leur nom. Voir la liste sur la page [NomsPreferences](NomsPreferences.md).
|
||||
#### Identité
|
||||
|
||||
Exemple: `infos['SCOLAR_FONT_SIZE']` est un entier, `infos['UnivName']` est le nom de l'université.
|
||||
|
||||
|
||||
### Informations sur le semestre
|
||||
Un semestre est représenté par un dictionnaire avec les attributs
|
||||
suivants:
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
int |semestre_id| Indice dans le parcours | 1
|
||||
string |titre| | 'DUT GEII'
|
||||
string |titre_num| | 'DUT GEII, semestre 1'
|
||||
string |titreannee| | 'DUT GEII, semestre 1 FI 2011'
|
||||
string |titremois| | 'DUT GEII, semestre 1 FI (Mars 2011 - Jul 2011)'
|
||||
string |annee_debut| | '2011'
|
||||
string |annee_fin| | '2011'
|
||||
| anneescolaire| | '2010 - 2011'
|
||||
string |date_debut| | '09/03/2011'
|
||||
| date_debut_iso| | '2011-03-09'
|
||||
| date_fin| | '31/07/2011'
|
||||
| date_fin_iso| | '2011-07-31'
|
||||
| dateord| | '2011-03-09'
|
||||
| mois_debut| | 'Mars 2011'
|
||||
int |mois_debut_ord| | 3
|
||||
| mois_fin| | 'Jul 2011'
|
||||
int |mois_fin_ord| | 7
|
||||
string |modalite| | 'FI'
|
||||
string |etape_apo| Code étape Apogée | 'V1TR2'
|
||||
string |etape_apo2| Code étape Apogée (si 2 codes) | *
|
||||
string |etat| verrouillé ('0') ou non ('1') | '1'
|
||||
| formation_id| id interne de la formation | 'FORM14570'
|
||||
| formsemestre_id| id interne du semestre | 'SEM15176'
|
||||
string |gestion_compensation| | '0'
|
||||
string |gestion_semestrielle| | '0'
|
||||
string |responsable_id| | 'viennet'
|
||||
int {0,1} |ens_can_edit_eval| | 0
|
||||
int {0,1}|resp_can_change_ens| | 0
|
||||
int {0,1} |resp_can_edit| | 0
|
||||
string |bul_bgcolor| | *
|
||||
string |bul_hide_xml| | '0'
|
||||
|
||||
|
||||
Pour le semestre à traiter, ces attributs sont directement dans `infos`.
|
||||
|
||||
On trouve aussi dans `infos['etud']` tous les semestres par lesquels
|
||||
est passé l'étudiant.
|
||||
|
||||
|
||||
### Informations sur l'étudiant
|
||||
|
||||
#### Identité
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
| string * | etudid | id ScoDoc de l'étudiant | 'EID15219' |
|
||||
string | code_ine | | *
|
||||
string | code_nip | | *
|
||||
string | codepostaldomicile | | '75018'
|
||||
| date_naissance | | *
|
||||
| annee_naissance | | '1947'
|
||||
| domicile | | *
|
||||
| email | | *
|
||||
| lieu_naissance | | *
|
||||
| nationalite | | *
|
||||
| ne | "e" si étudiante, vide sinon | *
|
||||
| nom | | 'FOURIER'
|
||||
| prenom | | 'JOSEPH'
|
||||
| sexe | | 'M.'
|
||||
| nomprenom | | 'M. Joseph Fourier'
|
||||
| paysdomicile | | *
|
||||
| telephone | | *
|
||||
| telephonemobile | | *
|
||||
| telephonemobilestr | | *
|
||||
| telephonestr | | *
|
||||
| typeadresse | | 'domicile'
|
||||
| villedomicile | | *
|
||||
| villelycee | |
|
||||
| string * | etudid | id ScoDoc de l'étudiant | 'EID15219' |
|
||||
string | code_ine | | *
|
||||
string | code_nip | | *
|
||||
string | codepostaldomicile | | '75018'
|
||||
| date_naissance | | *
|
||||
| annee_naissance | | '1947'
|
||||
| domicile | | *
|
||||
| email | | *
|
||||
| lieu_naissance | | *
|
||||
| nationalite | | *
|
||||
| ne | "e" si étudiante, vide sinon | *
|
||||
| nom | | 'FOURIER'
|
||||
| prenom | | 'JOSEPH'
|
||||
| sexe | | 'M.'
|
||||
| nomprenom | | 'M. Joseph Fourier'
|
||||
| paysdomicile | | *
|
||||
| telephone | | *
|
||||
| telephonemobile | | *
|
||||
| telephonemobilestr | | *
|
||||
| telephonestr | | *
|
||||
| typeadresse | | 'domicile'
|
||||
| villedomicile | | *
|
||||
| villelycee | |
|
||||
|
||||
|
||||
#### Admission
|
||||
@ -190,37 +176,36 @@ Informations importées dans ScoDoc lors de la création de l'étudiant
|
||||
(import des données d'admission): établissement d'origine, notes de
|
||||
lycée, etc.)
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
| bac | Série de bac | 'S'
|
||||
| specialite | Spécialité de bac | 'SVT'
|
||||
| math | note math antérieure (en terminale ou au bac ou ...) | *
|
||||
| physique | note physique antérieure | *
|
||||
| francais | note francais (au bac en général) | *
|
||||
| anglais | note anglais antérieure | *
|
||||
| annee_bac | année d'obtention du bac | '2010'
|
||||
| nomlycee | | *
|
||||
| codelycee | | *
|
||||
| codepostallycee | | *
|
||||
| qualite | note de qualité du dossier attribuée par le jury d'admission | *
|
||||
| rang | rang de cet établissement dans les voeux du candidat (si applicable) | *
|
||||
| rap | | "Pas d'informations sur les conditions d'admission."
|
||||
| rapporteur | pseudo du collègue chargé de l'examen de ce dossier | *
|
||||
| score | Score calculé pour ce dossier à l'admission | *
|
||||
| commentaire | Commentaire du jury d'admission| *
|
||||
| decision | Décision du jury d'admission | 'ADMIS'
|
||||
| description | Comment l'étudiant a été inscrit | '(creation individuelle)'
|
||||
|
||||
| bac | Série de bac | 'S'
|
||||
| specialite | Spécialité de bac | 'SVT'
|
||||
| math | note math antérieure (en terminale ou au bac ou ...) | *
|
||||
| physique | note physique antérieure | *
|
||||
| francais | note francais (au bac en général) | *
|
||||
| anglais | note anglais antérieure | *
|
||||
| annee_bac | année d'obtention du bac | '2010'
|
||||
| nomlycee | | *
|
||||
| codelycee | | *
|
||||
| codepostallycee | | *
|
||||
| qualite | note de qualité du dossier attribuée par le jury d'admission | *
|
||||
| rang | rang de cet établissement dans les voeux du candidat (si applicable) | *
|
||||
| rap | | "Pas d'informations sur les conditions d'admission."
|
||||
| rapporteur | pseudo du collègue chargé de l'examen de ce dossier | *
|
||||
| score | Score calculé pour ce dossier à l'admission | *
|
||||
| commentaire | Commentaire du jury d'admission| *
|
||||
| decision | Décision du jury d'admission | 'ADMIS'
|
||||
| description | Comment l'étudiant a été inscrit | '(creation individuelle)'
|
||||
|
||||
#### Inscription
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
int | annee | | 2011
|
||||
string | etatincursem | état (I=inscrit, D=démissionnaire) | 'I'
|
||||
string | inscription | | 'DUT GEII, semestre 1 FI (Mars 2011 - Jul 2011)'
|
||||
string | situation | | 'inscrit en DUT GEII, semestre 1 FI (Mars 2011 - Jul 2011) le 11/09/2011'
|
||||
string | statut | ? | *
|
||||
string | etatincursem | état (I=inscrit, D=démissionnaire) | 'I'
|
||||
string | inscription | | 'DUT GEII, semestre 1 FI (Mars 2011 - Jul 2011)'
|
||||
string | situation | | 'inscrit en DUT GEII, semestre 1 FI (Mars 2011 - Jul 2011) le 11/09/2011'
|
||||
string | statut | ? | *
|
||||
| descr_inscription | | 'Inscrit le 27/06/2011.'
|
||||
|
||||
En outre, les attributs `sems`, `cursem` et `ins` apportent des informations
|
||||
@ -238,205 +223,206 @@ Type | Nom | Description | Exemple de valeur
|
||||
string | refcomp_specialite | code spécialité | "RT"
|
||||
string | refcomp_specialite_long| spécialité | "Réseaux et Télécommunications"
|
||||
|
||||
### Résultats (notes) de l'étudiant dans le semestre
|
||||
### Résultats (notes) de l'étudiant dans le semestre
|
||||
|
||||
Quelques infos sur les résultats. Le détail des notes est dans la
|
||||
liste `infos['ues']` et ses sous-listes imbriquées (modules, evaluation).
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
string | moy_gen | moyenne générale de l'étudiant dans le semestre | '12.00'
|
||||
string | bonus_sport_culture | bonus appliqué | 0
|
||||
string | moy_max | moyenne max promo | '12.00'
|
||||
string | moy_min | moyenne min promo | '10.00'
|
||||
string | moy_moy | moyenne des moyennes promo | '11.00'
|
||||
int | nb_inscrits | nombre étudiants du semestre (incluant démissionnaires et défaillants) | 78
|
||||
int | nb_demissions | nombre de démissions dans le semestre | 3
|
||||
int | nb_defaillants | nombre de défaillants dans le semestre | 2
|
||||
int | nbabs | nombre de 1/2 journées d'absences | 0L
|
||||
int | nbabsjust | idem, justifiées | 0L
|
||||
string | rang | classement | '(attente)'
|
||||
string | rang_txt | classement (avec titre) | 'Rang (attente) / 2'
|
||||
list | ues | résultats dans les UE, voir ci-dessous | [ liste de dict ]
|
||||
string | moy_gen | moyenne générale de l'étudiant dans le semestre | '12.00'
|
||||
string | bonus_sport_culture | bonus appliqué | 0
|
||||
string | moy_max | moyenne max promo | '12.00'
|
||||
string | moy_min | moyenne min promo | '10.00'
|
||||
string | moy_moy | moyenne des moyennes promo | '11.00'
|
||||
int | nb_inscrits | nombre étudiants du semestre (incluant démissionnaires et défaillants) | 78
|
||||
int | nb_demissions | nombre de démissions dans le semestre | 3
|
||||
int | nb_defaillants | nombre de défaillants dans le semestre | 2
|
||||
int | nbabs | nombre de 1/2 journées d'absences | 0L
|
||||
int | nbabsjust | idem, justifiées | 0L
|
||||
string | rang | classement | '(attente)'
|
||||
string | rang_txt | classement (avec titre) | 'Rang (attente) / 2'
|
||||
list | ues | résultats dans les UE, voir ci-dessous | [ liste de dict ]
|
||||
|
||||
Chaque élément de la liste `ues` représente les résultats de
|
||||
l'étudiant dans une UE.
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
string | acronyme | | 'UE 1'
|
||||
string | coef_ue_txt | Coefficient (chaîne) | '2'
|
||||
string| cur_moy_ue_txt | Moyenne prise en compte pour cette UE | '12.00'
|
||||
float | max | moyenne max promo | 12.0
|
||||
float | min | moyenne min promo | 10.0
|
||||
list | modules | détails notes dans les modules de l'UE | [ liste de dict]
|
||||
list | modules_capitalized | | []
|
||||
float | moy | | 11.0
|
||||
string | moy_ue_txt | moyenne étudiant dans UE | '12.00'
|
||||
int | nb_moy | nombre de moyenens calculées dans cette UE (inscrits, sans démissionnaires ni défaillants) | 76
|
||||
int | numero | rang tri UE | 1
|
||||
string | titre | | 'Formation Générale'
|
||||
int | type | code type UE | 0
|
||||
string | ue_code | code dans programme formation | 'UCOD5'
|
||||
string | ue_descr_html | rang ou autre info à afficher | '(attente)/2'
|
||||
string | ue_descr_txt | rang ou autre info à afficher | '(attente)/2'
|
||||
string | ue_id | id interne ScoDoc | 'UE14572'
|
||||
dict | ue_status | statut de l'UE (voir ci-dessous)| { dict }
|
||||
string | acronyme | | 'UE 1'
|
||||
string | coef_ue_txt | Coefficient (chaîne) | '2'
|
||||
string| cur_moy_ue_txt | Moyenne prise en compte pour cette UE | '12.00'
|
||||
float | max | moyenne max promo | 12.0
|
||||
float | min | moyenne min promo | 10.0
|
||||
list | modules | détails notes dans les modules de l'UE | [ liste de dict]
|
||||
list | modules_capitalized | | []
|
||||
float | moy | | 11.0
|
||||
string | moy_ue_txt | moyenne étudiant dans UE | '12.00'
|
||||
int | nb_moy | nombre de moyenens calculées dans cette UE (inscrits, sans démissionnaires ni défaillants) | 76
|
||||
int | numero | rang tri UE | 1
|
||||
string | titre | | 'Formation Générale'
|
||||
int | type | code type UE | 0
|
||||
string | ue_code | code dans programme formation | 'UCOD5'
|
||||
string | ue_descr_html | rang ou autre info à afficher | '(attente)/2'
|
||||
string | ue_descr_txt | rang ou autre info à afficher | '(attente)/2'
|
||||
string | ue_id | id interne ScoDoc | 'UE14572'
|
||||
dict | ue_status | statut de l'UE (voir ci-dessous)| { dict }
|
||||
|
||||
**Statut d'une UE (champ `ue_status`):**
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
float | coef_ue | | 2.0
|
||||
| coefs_bonus_gen | | []
|
||||
| cur_coef_ue | | 2.0
|
||||
| cur_moy_ue | | 12.0
|
||||
string | expr_diag | infos erreur calcul formule utilisateur | {}
|
||||
bool | is_capitalized | est-elle capitalisée? | False
|
||||
| moy | | 12.0
|
||||
| nb_missing | | 1
|
||||
| nb_notes | | 1
|
||||
| notes_bonus_gen | | []
|
||||
| sum_coefs | | 2.0
|
||||
| was_capitalized | | False
|
||||
float | coef_ue | | 2.0
|
||||
| coefs_bonus_gen | | []
|
||||
| cur_coef_ue | | 2.0
|
||||
| cur_moy_ue | | 12.0
|
||||
string | expr_diag | infos erreur calcul formule utilisateur | {}
|
||||
bool | is_capitalized | est-elle capitalisée? | False
|
||||
| moy | | 12.0
|
||||
| nb_missing | | 1
|
||||
| nb_notes | | 1
|
||||
| notes_bonus_gen | | []
|
||||
| sum_coefs | | 2.0
|
||||
| was_capitalized | | False
|
||||
|
||||
|
||||
**Résultats dans un module:**
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
| code | | *
|
||||
| code_html | | *
|
||||
| code_txt | | *
|
||||
| computation_expr | | *
|
||||
| ens | | []
|
||||
| evaluations | | []
|
||||
| formsemestre_id | | 'SEM15176'
|
||||
| mat | | {'titre': 'Mathématiques' }
|
||||
| mod_coef_txt | | '2'
|
||||
| mod_descr_txt | | "Module Fondamentaux d'algèbre et de trigonométrie, coef. 2 (Béatrice DUPONT)"
|
||||
| mod_eff | | 2
|
||||
| mod_moy_txt | | '12.00'
|
||||
| mod_rang | | '(attente)'
|
||||
| mod_rang_txt | | '(attente)/2'
|
||||
| module | | {voir plus loin}
|
||||
| module_id | | 'MOD14576'
|
||||
| moduleimpl_id | | 'MIP15178'
|
||||
| name | | 'Algèbre'
|
||||
| responsable_id | id du responsable | 'dupont'
|
||||
| stats | statistiques sur les notes du module | `{'moy': 9.576, 'nb_missing': 2, 'max': 16.5, 'min': 0.0, 'nb_notes': 39, 'nb_valid_evals': 1}`
|
||||
| code | | *
|
||||
| code_html | | *
|
||||
| code_txt | | *
|
||||
| computation_expr | | *
|
||||
| ens | | []
|
||||
| evaluations | | []
|
||||
| formsemestre_id | | 'SEM15176'
|
||||
| mat | | {'titre': 'Mathématiques' }
|
||||
| mod_coef_txt | | '2'
|
||||
| mod_descr_txt | | "Module Fondamentaux d'algèbre et de trigonométrie, coef. 2 (Béatrice DUPONT)"
|
||||
| mod_eff | | 2
|
||||
| mod_moy_txt | | '12.00'
|
||||
| mod_rang | | '(attente)'
|
||||
| mod_rang_txt | | '(attente)/2'
|
||||
| module | | {voir plus loin}
|
||||
| module_id | | 'MOD14576'
|
||||
| moduleimpl_id | | 'MIP15178'
|
||||
| name | | 'Algèbre'
|
||||
| responsable_id | id du responsable | 'dupont'
|
||||
| stats | statistiques sur les notes du module | `{'moy': 9.576, 'nb_missing': 2, 'max': 16.5, 'min': 0.0, 'nb_notes': 39, 'nb_valid_evals': 1}`
|
||||
|
||||
Le module (tel que décrit dans le programme de la formation) est représenté par:
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
string | titre | | "Fondamentaux d'algèbre et de trigonométrie"
|
||||
string | abbrev | | 'Algèbre'
|
||||
string | code | | 'M1'
|
||||
float | coefficient | | 2.0
|
||||
| ects | | None
|
||||
| formation_id | | 'FORM14570'
|
||||
| heures_cours | | 0.0
|
||||
| heures_td | | 30.0
|
||||
| heures_tp | | 0.0
|
||||
| matiere_id | | 'MAT14574'
|
||||
| module_id | | 'MOD14576'
|
||||
| numero | | 10
|
||||
| semestre_id | | 1
|
||||
| ue_id | | 'UE14572'
|
||||
string | titre | | "Fondamentaux d'algèbre et de trigonométrie"
|
||||
string | abbrev | | 'Algèbre'
|
||||
string | code | | 'M1'
|
||||
float | coefficient | | 2.0
|
||||
| ects | | None
|
||||
| formation_id | | 'FORM14570'
|
||||
| heures_cours | | 0.0
|
||||
| heures_td | | 30.0
|
||||
| heures_tp | | 0.0
|
||||
| matiere_id | | 'MAT14574'
|
||||
| module_id | | 'MOD14576'
|
||||
| numero | | 10
|
||||
| semestre_id | | 1
|
||||
| ue_id | | 'UE14572'
|
||||
|
||||
|
||||
|
||||
**Résultat dans une évaluation:**
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
| coef_txt | | '1'
|
||||
| coefficient | | 1.0
|
||||
| descrheure | | ' ? 08h00'
|
||||
| description | | *
|
||||
| duree | | '2h'
|
||||
| etat | | { voir plus loin }
|
||||
| evaluation_id | | 'EVAL15226'
|
||||
| evaluation_type | | 0
|
||||
| heure_debut | | '08h00'
|
||||
| heure_fin | | '08h00'
|
||||
| jour | | '01/07/2011'
|
||||
| moduleimpl_id | | 'MIP15178'
|
||||
| name | | 'le 01/07/2011'
|
||||
| nb_abs | | 0
|
||||
| nb_att | | 0
|
||||
| nb_inscrits | | 2
|
||||
| nb_neutre | | 0
|
||||
| nb_notes | | 2
|
||||
| note_html | | '12.00'
|
||||
| note_max | | 20.0
|
||||
| note_txt | | '12.00'
|
||||
| notes | | { voir plus loin }
|
||||
| publish_incomplete | | '0'
|
||||
| visibulletin | | '1'
|
||||
| coef_txt | | '1'
|
||||
| coefficient | | 1.0
|
||||
| descrheure | | ' ? 08h00'
|
||||
| description | | *
|
||||
| duree | | '2h'
|
||||
| etat | | { voir plus loin }
|
||||
| evaluation_id | | 'EVAL15226'
|
||||
| evaluation_type | | 0
|
||||
| heure_debut | | '08h00'
|
||||
| heure_fin | | '08h00'
|
||||
| jour | | '01/07/2011'
|
||||
| moduleimpl_id | | 'MIP15178'
|
||||
| name | | 'le 01/07/2011'
|
||||
| nb_abs | | 0
|
||||
| nb_att | | 0
|
||||
| nb_inscrits | | 2
|
||||
| nb_neutre | | 0
|
||||
| nb_notes | | 2
|
||||
| note_html | | '12.00'
|
||||
| note_max | | 20.0
|
||||
| note_txt | | '12.00'
|
||||
| notes | | { voir plus loin }
|
||||
| publish_incomplete | | '0'
|
||||
| visibulletin | | '1'
|
||||
|
||||
**Etat d'une évaluation:**
|
||||
|
||||
Le champ `etat` d'une évaluation ets un dict donnant des informations sur les résultats de la promo (et des groupes) dans cette évaluation:
|
||||
Le champ `etat` d'une évaluation est un dict donnant des informations sur les résultats de la promo (et des groupes) dans cette évaluation:
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
bool | evalattente | | False
|
||||
bool | evalcomplete | | True
|
||||
| evaluation_id | id interne | 'EVAL15226'
|
||||
list | gr_incomplets | | []
|
||||
list | gr_moyennes | | []
|
||||
list | groups | liste des groupes | {}
|
||||
datetime | last_modif | | <mx.DateTime.DateTime object>
|
||||
string | median | note médianne promo | '11.00'
|
||||
string | moy | note moyenne promo | '11.00'
|
||||
| nb_abs | nb étudiants absents | 0
|
||||
| nb_att | nb notes en attente | 0
|
||||
| nb_inscrits | nb inscrits à ce module | 2
|
||||
| nb_neutre | nb notes neutralisées | 0
|
||||
| nb_notes | nb notes saisies | 2
|
||||
bool | evalattente | | False
|
||||
bool | evalcomplete | | True
|
||||
| evaluation_id | id interne | 15226
|
||||
list | gr_incomplets | | []
|
||||
list | gr_moyennes | | []
|
||||
list | groups | liste des groupes | {}
|
||||
datetime | last_modif | | datetime
|
||||
string | median | note médianne promo | '11.00'
|
||||
string | moy | note moyenne promo | '11.00'
|
||||
| nb_abs | nb étudiants absents | 0
|
||||
| nb_att | nb notes en attente | 0
|
||||
| nb_inscrits | nb inscrits à ce module | 2
|
||||
| nb_neutre | nb notes neutralisées | 0
|
||||
| nb_notes | nb notes saisies | 2
|
||||
|
||||
|
||||
`gr_moyennes` est un dict:
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
| gr_median | | '11.00'
|
||||
| gr_moy | | '11.00'
|
||||
| gr_nb_att | | 0
|
||||
| gr_nb_notes | | 2
|
||||
| group_id | | 'G24919'
|
||||
| group_name | | None
|
||||
| gr_median | | '11.00'
|
||||
| gr_moy | | '11.00'
|
||||
| gr_nb_att | | 0
|
||||
| gr_nb_notes | | 2
|
||||
| group_id | | 'G24919'
|
||||
| group_name | | None
|
||||
|
||||
**Notes dans une évaluation:**
|
||||
|
||||
Le champ `notes` dans une évaluation est un dictionnaire dont les clés sont les `etudids`, et les valeurs des dictionnaires donnant les informations sur la note de l'étudiant dans cette évaluation:
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
string | comment | commentaire saisie note | *
|
||||
datetime | date | date de saisie | <mx.DateTime.DateTime object>
|
||||
string | etudid | | 'EID15214'
|
||||
string | evaluation_id | | 'EVAL15226'
|
||||
string | uid | utilisateur ayant saisi la note | 'admin'
|
||||
float | value | valeur de la note (sur 20) | 10.0
|
||||
string | comment | commentaire saisie note | *
|
||||
datetime | date | date de saisie | <mx.DateTime.DateTime object>
|
||||
string | etudid | | 'EID15214'
|
||||
string | evaluation_id | | 'EVAL15226'
|
||||
string | uid | utilisateur ayant saisi la note | 'admin'
|
||||
float | value | valeur de la note (sur 20) | 10.0
|
||||
|
||||
|
||||
|
||||
### Décisions de jury et autres informations
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
### Décisions de jury et autres informations
|
||||
|
||||
Type | Nom | Description | Exemple de valeur
|
||||
----| --- | ---- | ---
|
||||
| decision_sem | | None ou dict
|
||||
string | decision_jury | décision du jury en clair (présent seulement si décision saisie) | 'Validé'
|
||||
list | appreciations | | []
|
||||
list | appreciations_list | | []
|
||||
list | appreciations_txt | | []
|
||||
string | mention | texte de la mention calculée | 'Très bien'
|
||||
| filigranne | texte en surimpression | 'Provisoire'
|
||||
| decision_sem | | None ou dict
|
||||
string | decision_jury | décision du jury en clair (présent seulement si décision saisie) | 'Validé'
|
||||
list | appreciations | | []
|
||||
list | appreciations_list | | []
|
||||
list | appreciations_txt | | []
|
||||
string | mention | texte de la mention calculée | 'Très bien'
|
||||
| filigranne | texte en surimpression | 'Provisoire'
|
||||
|
||||
|
||||
## Note: la fonction log
|
||||
## Note: la fonction log
|
||||
|
||||
Pour la mise au point, il peut être utile de recourir à la bonne vieille
|
||||
fonction log, qui envoie du texte dans le fichier de log courant, normalement
|
||||
|
284
docs/Assiduites.md
Normal file
284
docs/Assiduites.md
Normal file
@ -0,0 +1,284 @@
|
||||
<!-- markdownlint-disable MD007 -->
|
||||
# Suivi de l'assiduité
|
||||
|
||||
Ce module de ScoDoc remplace l'ancien module de suivi des absences de Scodoc.
|
||||
Il propose des fonctions plus étendues: absences, retards, justificatifs (et
|
||||
gestion des documents associés) avec une granularité fine, des outils de
|
||||
_reporting_ et une API complète permettant d'interfacer des modules tiers.
|
||||
|
||||
Ce projet a été développé de 2022 à 2024, par Matthias Hartmann, apprenti de l'IUT de
|
||||
Lannion financé par l'Association ScoDoc.
|
||||
|
||||
**Ce module est disponible à partir de ScoDoc version 9.6**.
|
||||
|
||||
[Vidéo de présentation du module d'assiduités](https://youtu.be/p7xips26W54)
|
||||
|
||||
## Fonctionnalités
|
||||
|
||||
Le module fournit:
|
||||
|
||||
- Gestion des absences/présences/retards
|
||||
- Précision des saisies (périodes déterminées par une heure de début et une
|
||||
heure de fin au lieu de demi-journées)
|
||||
- Gestion et sauvegarde de justificatifs (documents)
|
||||
- Une [API complète](ScoDoc9API.md#api-assiduites)
|
||||
- [**EXPERIMENTAL**] Raccordement à un emploi du temps ([documentation](EmploisDuTemps.md))
|
||||
|
||||
## Migration de l'ancien module
|
||||
|
||||
Afin de favoriser la transition de l'ancien module au nouveau, un script de
|
||||
migration a été développé: à l'installation de ScoDoc 9.6, les anciennes
|
||||
données d'absences et justificatifs sont traduites pour ce module.
|
||||
|
||||
Voir détails dans [la documentation d'installation](UpgradeToDeb12Sco96.md) et
|
||||
sur la [documentation des commandes de migration des absences](AssiduitesMigration.md).
|
||||
|
||||
## Personnalisation du module
|
||||
|
||||
Le module possède deux types de configuration, une générale et une par département/semestre.
|
||||
|
||||
### La configuration générale
|
||||
|
||||
Elle permet de configurer les horaires de saisie d'assiduités
|
||||
|
||||
!!! warning "Attention"
|
||||
La configuration bloque les saisies en dehors des horaires définis.
|
||||
|
||||
![Configuration de l'assiduité : Général](screens/config_assiduites_gen.png)
|
||||
|
||||
Route : `/ScoDoc/config_assiduites`
|
||||
|
||||
- `Début de la journée` : l'heure de début des cours (par défaut :
|
||||
8h00)
|
||||
- `L'heure de midi` : l'heure pivot qui sépare la matinée de l'après-midi (par
|
||||
défaut : 13h00)
|
||||
- `Fin de la journée` : l'heure de fin des cours (par défaut :
|
||||
18h00)
|
||||
- `Granularité` : La granularité de la saisie (par défaut : 15 min)
|
||||
|
||||
### La configuration par département/semestre
|
||||
|
||||
Elle permet de configurer certaines actions liés à l'assiduité
|
||||
|
||||
![Configuration de l'assiduité : département](screens/config_assiduites_dept.png)
|
||||
|
||||
Route : `/ScoDoc/<Dept>/Scolarite/edit_preferences`
|
||||
|
||||
- `Imposer la déclaration du module` : Forcer les utilisateurs de ScoDoc à
|
||||
renseigner le module à chaque saisie d'assiduités.
|
||||
- `Désactiver la saisie des présences` : Retire les boutons et les affichages liés aux présences.
|
||||
- `Jours non travaillés` : Défini les jours sur lesquels la saisie d'assiduités
|
||||
ne sera pas possible.
|
||||
- `Métrique de l'assiduité` : Défini l'unité de l'assiduité qui sera utilisé par
|
||||
les autres modules de ScoDoc.
|
||||
- `1/2 J.` : Demi-Journée
|
||||
- `J.` : Journées
|
||||
- `H.` : Heures
|
||||
- `Seuil d'alerte des absences` : Nombre d'absences limite avant alerte (utilisation de la métrique d'assiduité)
|
||||
|
||||
## Gestion de l'assiduité
|
||||
|
||||
### Saisir l'assiduité d'un groupe
|
||||
|
||||
#### Saisir par Jour
|
||||
|
||||
Route : `/ScoDoc/<DEPT>/Scolarite/Assiduites/signal_assiduites_group?formsemestre_id=<formsemestre_id>&group_ids=<group_id,...>&day=<yyyy-mm-dd>`
|
||||
|
||||
_Page accessible depuis le tableau de bord d'un semestre (`Saisir l'assiduité`)._
|
||||
|
||||
_Page accessible depuis le tableau de bord d'un module (`Saisie Absences`)._
|
||||
|
||||
![Saisir l'assiduité](screens/signal_assiduites_group.png)
|
||||
|
||||
##### Composition de la page
|
||||
|
||||
- Choix du/des groupe(s) et de la date
|
||||
![Choix groupe et date](screens/signal_assiduites_group-groupe.png)
|
||||
- Vous pouvez cliquer sur le calendrier pour changer plus facilement la date. Si la date n'est pas un jour travaillé la page sélectionnera automatiquement le prochain jour travaillé.
|
||||
- Vous pouvez afficher plusieurs groupes en cliquant sur le nom du group affiché ( ici TP1(10) )
|
||||
- Timeline / choix de la plage concernée (exemple : durée d'un cours)
|
||||
![Timeline](screens/signal_assiduites_group-timeline.png)
|
||||
- La zone bleu est un élément intéractif. Elle correspond à la plage concernée. Vous pouvez la déplacer en cliquant dessus puis en déplaçant la souris en gardant maintenu le clic. Vous pouvez également l'agrandir ou rétrécir en effectuant la même action mais depuis un des bords de la zone bleu. Le curseur changera pour vous indiquer que vous aller modifier la taille.
|
||||
- Sinon vous pouvez directement changer les horaires à l'aide des sélecteurs à gauche de la timeline
|
||||
- Vous pouvez aussi utiliser les boutons `Matin` et `Après-midi` pour placer rapidement la zone bleue.
|
||||
- Choix du module (et affichage ou non des photos des étudiants)
|
||||
![Module](screens/signal_assiduites_group-module.png)
|
||||
- Vous pouvez changer de module en cliquant sur le sélecteur. Un message d'avertissement s'affichera si vous ne sélectionnez pas de module alors que la préférence `Imposer la déclaration du module` est active.
|
||||
- Vous pouvez afficher ou non les photos des étudiants en cochant la case `Afficher les photos`
|
||||
- Lignes étudiants et saisie
|
||||
![Lignes étudiantes](screens/signal_assiduites_group-lignes_etud.png)
|
||||
|
||||
##### Composition d'une ligne étudiante
|
||||
|
||||
![Ligne étudiante classique](screens/signal_assiduites-group-ligne-etud.png)
|
||||
|
||||
- En premier il y a les informations de l'étudiant (nom, prenom, photo)
|
||||
- ensuite il y a symbolisation des assiduités sur la journée.
|
||||
- le petit carré affiche la dernière assiduité du jour précédent
|
||||
- la ligne affiche l'assiduité de la journée. La taille des blocs est proportionnelle à la taille de l'assiduité saisie.
|
||||
- La zone bleue correspond à la plage de saisie (Timeline)
|
||||
- Enfin il y a les boutons de saisie. Dans l'ordre
|
||||
- Présence
|
||||
- Retard
|
||||
- Absence
|
||||
|
||||
!!! warning "Attention"
|
||||
il est possible que la plage de saisie rentre en conflit avec la plage d'une assiduité.
|
||||
_(Il est impossible d'avoir deux assiduités aux même moment. Cela produit donc un conflit.)_
|
||||
Ce conflit est symbolisé par la mise en évidence de la ligne étudiante
|
||||
|
||||
![Conflit](screens/signal_assiduites_group-conflit.png)
|
||||
|
||||
Pour résoudre ce conflit il faudra effectuer au moins une de ces actions:
|
||||
|
||||
- Changer la plage de saisie
|
||||
- Modifier l'assiduité qui rentre en conflit
|
||||
- Supprimer l'assiduité qui rentre en conflit
|
||||
- Ne pas saisir pour l'étudiant concerné
|
||||
- Utiliser le résolveur de conflit (l’icône à droite de la ligne étudiante)
|
||||
|
||||
!!! info "Astuces"
|
||||
- Vous pouvez passer la souris sur les blocs d'assiduités / le petit carré pour avoir plus d'informations.
|
||||
- Vous pouvez cliquer sur un bloc pour changer la plage de saisie à la plage de l'assiduité.
|
||||
- Vous pouvez cliquer sur les ℹ️ pour ouvrir la page de modification d'une assiduité
|
||||
|
||||
#### Saisir par Semaine
|
||||
|
||||
Route : `/ScoDoc/<DEPT>/Scolarite/Assiduites/signal_assiduites_hebdo?formsemestre_id=<formsemestre_id>&group_ids=<group_id,...>&week=<yyyy-Www : 2024-W25 >`
|
||||
|
||||
_Page accessible depuis le tableau de bord d'un semestre (`Saisie hebdomadaire`)._
|
||||
|
||||
_Page accessible depuis le tableau de bord d'un module (`Saisie Absences(Hebdo)`)._
|
||||
|
||||
!!! warning "Attention"
|
||||
Les semaines sont restreintes au semestre en cours. Vous ne pourrez pas saisir en dehors du semestre.
|
||||
|
||||
Cliquer sur `autre semaine` affichera un calendrier du semestre en cours. Vous pourrez ensuite choisir la semaine en cliquant sur le calendrier.
|
||||
|
||||
!!! info "Astuce"
|
||||
Vous pouvez changer les horaires en cliquant dessus. Par défaut ils correspondent à la configuration générale.
|
||||
|
||||
![Saisie Hebdomadaire](screens/saisie_hebdo.png)
|
||||
|
||||
### Saisir l'assiduité d'un étudiant
|
||||
|
||||
#### Ajouter une assiduité
|
||||
|
||||
Route : `/ScoDoc/<DEPT>/Scolarite/Assiduites/ajout_assiduite_etud?etudid=<etudid>`
|
||||
|
||||
_Page accessible en cliquant sur `Ajouter` dans la barre latérale._
|
||||
|
||||
!!! warning "Attention"
|
||||
Les modules proposés sont lié au semestre courant. Si vous souhaitez saisir une assiduité pour un semestre passé, vous devez aller sur la page [Bilan](#bilan) du semestre concerné puis cliquer sur `signaler l'assiduité` dans la ligne de l'étudiant concerné.
|
||||
|
||||
![Ajouter une assiduité](screens/ajout_assiduite_etud.png)
|
||||
|
||||
#### Modifier / Voir une assiduité
|
||||
|
||||
Route : `/ScoDoc/<DEPT>/Scolarite/Assiduites/edit_assiduite_etud/<assiduite_id>`
|
||||
|
||||
_Page accessible en cliquant sur ℹ️ dans les tableaux d'assiduités._
|
||||
|
||||
![Modification d'une assiduité](screens/edit_assiduite_etud.png)
|
||||
|
||||
#### Ajouter un justificatif
|
||||
|
||||
Route : `/ScoDoc/<DEPT>/Scolarite/Assiduites/ajout_justificatif_etud?etudid=<etudid>`
|
||||
|
||||
_Page accessible en cliquant sur `Justifier` dans la barre latérale._
|
||||
|
||||
Un justificatif peut prendre un des états suivants :
|
||||
|
||||
- En attente de validation
|
||||
- Non valide
|
||||
- Modifié
|
||||
- Valide
|
||||
|
||||
!!! warning "Attention"
|
||||
Pour saisir les états `Valide` , `Modifié`, `Non valide` il faut obligatoirement la permission `JustifValidate`
|
||||
|
||||
!!! warning "Attention"
|
||||
Seul l'état `Valide` permet de justifier une assiduité. Les autres états sont là pour faciliter le suivi du justificatif.
|
||||
|
||||
Il est possible d'importer des fichiers (exemple: une convocation au permis de conduire ) et de donner une description au justificatif.
|
||||
|
||||
!!! warning "Attention"
|
||||
Les justificatifs pouvant contenir des informations sensibles, seuls ceux ayant la permission `AbsJustifView` et celui qui a saisie l'information peuvent voir la description et les fichiers.
|
||||
|
||||
![Ajouter un justificatif à un étudiant](screens/ajout_justificatif_etud.png)
|
||||
|
||||
#### Modifier / Voir un justificatif
|
||||
|
||||
Route : `/ScoDoc/<DEPT>/Scolarite/Assiduites/edit_justificatif_etud/<justif_id>`
|
||||
|
||||
_Page accessible en cliquant sur ℹ️ dans les tableaux de justificatifs._
|
||||
|
||||
!!! info "Astuce"
|
||||
Cliquer sur le nom d'un fichier permet de le télécharger
|
||||
|
||||
!!! warning "Attention"
|
||||
Pour saisir les états `Valide` , `Modifié`, `Non valide` il faut obligatoirement la permission `JustifValidate`
|
||||
|
||||
![Modification d'un justificatif](screens/edit_justificatif_etud.png)
|
||||
|
||||
### Voir l'assiduité d'un groupe
|
||||
|
||||
#### Bilan
|
||||
|
||||
Route : `/ScoDoc/<DEPT>/Scolarite/Assiduites/visu_assi_group?date_debut=<yyyy-mm-dd>&date_fin=<yyyy-mm-dd>&group_ids=<group_id>`
|
||||
|
||||
_Page accessible depuis le tableau de bord d'un semestre._
|
||||
|
||||
La page est configurée par défaut pour afficher les comptes sur la durée du semestre. Mais il est possible de changer les dates puis de cliquer sur `Changer`.
|
||||
|
||||
L'option `Restreindre aux modules de ce semestre` permet de ne comptabiliser que les assiduités ayant un module spécifié.
|
||||
(Le module `Autre` ne sera pas comptabilisé)
|
||||
|
||||
![Visualisation de l'assiduité d'un groupe](screens/bilan_assiduites_group.png)
|
||||
|
||||
### Voir l'assiduité d'un étudiant
|
||||
|
||||
#### Liste/Bilan
|
||||
|
||||
Route : `/ScoDoc/<DEPT>/Scolarite/Assiduites/bilan_etud?etudid=<etudid>`
|
||||
|
||||
_Page accessible en cliquant sur `Liste/Bilan` dans la barre latérale._
|
||||
|
||||
Cette page permet :
|
||||
|
||||
- d'afficher les statistiques de l'assiduité d'un étudiant sur une période. (par défaut : l'année scolaire en cours)
|
||||
- d'afficher la liste des assiduités et justificatifs enregistrés pour l'étudiant
|
||||
- d'afficher si l'étudiant a trop d'absences (par rapport à la préférence `Seuil d'alerte des absences`)
|
||||
|
||||
![Liste/Bilan de l'assiduité d'un étudiant](screens/bilan_assiduites_etud.png)
|
||||
|
||||
#### Calendrier
|
||||
|
||||
Route : `/ScoDoc/<DEPT>/Scolarite/Assiduites/calendrier_assi_etud?etudid=<etudid>`
|
||||
|
||||
_Page accessible en cliquant sur `Calendrier` dans la barre latérale._
|
||||
|
||||
La page calendrier permet d'afficher un calendrier de l'année scolaire en cours et d'afficher l'assiduité de l'étudiant concerné.
|
||||
Il est possible de changer l'année en cours à l'aide du sélecteur en bas de page.
|
||||
|
||||
En haut de la page se trouve des éléments de configuration de l'affichage :
|
||||
|
||||
- `Afficher les présences` : permet d'afficher les présences (par défaut : Non)
|
||||
- `Afficher les retards` : permet d'afficher les retards (par défaut : Non)
|
||||
- `Mode demi-journée` : permet d'afficher l'assiduité par demi-journée (par défaut : Oui). Si non coché, l'assiduité sera montrée par journée
|
||||
|
||||
La zone avec les bordures oranges correspond à la semaine en cours.
|
||||
|
||||
![Calendrier de l'Assiduité d'un étudiant](screens/calendrier_assiduite_etud.png)
|
||||
|
||||
!!! info "Astuces"
|
||||
Passer sa souris sur un jour affichera une bulle. Cette bulle montre les assiduités de la journée.
|
||||
Il est aussi possible de cliquer sur les assiduités de la bulle pour se rendre sur leur page d'édition.
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Migration des absences vers les assiduités](AssiduitesMigration.md)
|
||||
- [API](ScoDoc9API.md) : API pour interfaçage avec d'autres applications
|
||||
- [API et fichiers justificatifs](FichiersJustificatifs)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
375
docs/AssiduitesDev.md
Normal file
375
docs/AssiduitesDev.md
Normal file
@ -0,0 +1,375 @@
|
||||
# Module Assiduité
|
||||
|
||||
!!! warning
|
||||
Attention vous vous trouvez sur la documentation **_Développeur_** du module Assiduité.
|
||||
|
||||
La documentation utilisateur est [ici](Assiduites.md).
|
||||
|
||||
Le module Assiduité est le nouveau module introduit en 9.6 permettant la saisie précise de l'assiduité des étudiants et étudiantes.
|
||||
|
||||
Ce module a été développé par Matthias HARTMANN, pendant son alternance entre 2022 et 2024 (alternance financée par l'association ScoDoc) et remplace l'ancien module _Absence_.
|
||||
|
||||
## Représentation en BDD
|
||||
|
||||
Le module Assiduité introduit deux nouveaux objets à la base ScoDoc :
|
||||
|
||||
- `Assiduite` : l'objet représentant une assiduité (absent,retard,present)
|
||||
- `Justificatif` : l'objet représentant un justificatif (permet de justifier ou non une assiduité / plusieurs assiduités)
|
||||
|
||||
La modélisation est gérée dans le fichier [app/models/assiduites.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/models/assiduites.py).
|
||||
|
||||
### Représentation de l'Assiduité
|
||||
|
||||
Le tableau si dessous reprend la représation des données d'une assiduité.
|
||||
|
||||
!!! warning
|
||||
Dans ScoDoc, l'heure affichée doit être celle affichée sur la montre des étudiants.
|
||||
|
||||
Assurez vous que la **timezone** du serveur soit la bonne.
|
||||
|
||||
| champs | type | commentaire |
|
||||
| ----------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------- |
|
||||
| id / assiduite_id | Integer | L'identifiant de l'assiduité |
|
||||
| date_debut | DateTimeTZ | La date (+heure) de début de l'assiduité. Doit avoir une TIMEZONE |
|
||||
| date_fin | DateTimeTZ | La date (+heure) de fin de l'assiduité. Doit avoir une TIMEZONE |
|
||||
| etudid | Integer | L'identifiant de l'étudiant concerné par l'assiduité **(clé externe)** |
|
||||
| moduleimpl_id | Integer | L'identifiant du moduleimpl concerné par l'assiduité. ([plus d'infos](#moduleimpl)) **Peut être None** **(clé externe)** |
|
||||
| etat | Integer | L'état de l'assiduité ([plus d'infos](#etats-dassiduite)) |
|
||||
| description | Text | La description de l'assiduité **Peut être None** |
|
||||
| entry_date | DateTimeTZ | La date (+heure) de saisie de l'assiduité. Doit avoir une TIMEZONE. Par défaut à la date actuelle |
|
||||
| user_id | Integer | L'identifiant de l'utilisateur qui a saisie l'assiduité. **Peut être None** **(clé externe)** |
|
||||
| est_just | Boolean | Indique si l'assiduité est justifiée |
|
||||
| external_data | JSON | Champs de données JSON peu utilisées dans ScoDoc même mais facilite la vie aux utilisateurs de l'API **Peut être None** |
|
||||
|
||||
!!! tip
|
||||
Il est conseillé d'utiliser les méthodes du modèle Assiduité afin de créer / éditer / supprimer une assiduité.
|
||||
|
||||
#### Etats d'assiduité
|
||||
|
||||
!!! info
|
||||
Une classe EtatAssiduite simplifiant la traduction ETAT ↔ VALEUR est disponible dans [app/scodoc/sco_utils.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/scodoc/sco_utils.py)
|
||||
|
||||
| état | valeur |
|
||||
| ------- | ------ |
|
||||
| PRESENT | 0 |
|
||||
| RETARD | 1 |
|
||||
| ABSENT | 2 |
|
||||
|
||||
!!! warning
|
||||
Seules les assiduités `RETARD` et `ABSENT` peuvent être justifiées.
|
||||
|
||||
#### Etudiants
|
||||
|
||||
Chaque assiduité est obligatoirement associée à un étudiant (Identite).
|
||||
Il est possible de récupérer toutes les assiduités d'un étudiant en utilisant la relation à partir du modèle Identite.
|
||||
|
||||
```py
|
||||
etudiant : Identite = Identite.get_etud(1234)
|
||||
assiduites_etud : Query = etudiant.assiduites
|
||||
|
||||
# Identite.assiduites est une query et permet donc les filtrages etc.
|
||||
|
||||
# Première absence
|
||||
prem_abs: Assiduite = assiduites_etud.filter(
|
||||
Assiduite.etat == scu.EtatAssiduite.ABSENT
|
||||
).first()
|
||||
```
|
||||
|
||||
#### ModuleImpl
|
||||
|
||||
Une assiduité peut être reliée à un ModuleImpl à l'aide du `moduleimpl_id`.
|
||||
|
||||
Cependant suite à une demande des utilisateurs, il existe un **FAUX** module nommé `autre`. Ce module permet de contourner la sécurité de la préférence `forcer la saisie d'un module` dans le cas où la saisie d'assiduité n'est pas directement en lien avec un module enregistré dans ScoDoc.
|
||||
|
||||
!!! warning
|
||||
Ce **FAUX** module n'est pas inscrit dans le `moduleimpl_id` mais dans `external_data`.
|
||||
|
||||
Voici le format de `external_data` :
|
||||
```json
|
||||
{
|
||||
"module":"Autre",
|
||||
"cle-non-scodoc" : "valeur-non-scodoc"
|
||||
}
|
||||
```
|
||||
|
||||
Des fonctions ont été rédigées pour faciliter la gestion de ce **FAUX** module. Elles sont toutes disponibles dans la classe de l'objet Assiduité. ([voir le code](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/models/assiduites.py))
|
||||
|
||||
- `get_module` : récupère (si existant) le module associé à l'assiduité
|
||||
|
||||
- Si module `ScoDoc` : renvoie l'objet Module (ou le titre du module si la traduction est active)
|
||||
- Si module `external_data:Autre` : renvoie la chaîne `Autre module (pas dans la liste)`
|
||||
- Si module `external_data:?` : renvoie la valeur liée à la clé "module" de external_data
|
||||
- Si pas de module : renvoie None (ou `Module non spécifié` si la traduction est active)
|
||||
|
||||
- `get_moduleimpl_id` : récupère (si existant) le moduleimpl_id associé à l'assiduité (comprend le module autre)
|
||||
|
||||
- Si moduleimpl `ScoDoc` : renvoie l'id du moduleimpl
|
||||
- Si module dans `external_data` : renvoie la valeur liée à la clé "module" de external_data
|
||||
- Si pas de module : renvoie None
|
||||
|
||||
- `set_moduleimpl_id` : permet de mettre à jour le moduleimpl_id (prend en compte le module autre)
|
||||
|
||||
On peut donner :
|
||||
|
||||
- `<int/str:moduleimpl_id>` : l'identifiant d'un moduleimpl
|
||||
- `"autre"` : le module autre
|
||||
- `""` : pas de module
|
||||
|
||||
|
||||
### Représentation du Justificatif
|
||||
|
||||
Le tableau si dessous reprend la représation des données d'un justificatif.
|
||||
|
||||
!!! warning
|
||||
Dans ScoDoc, l'heure affichée doit être celle affichée sur la montre des étudiants.
|
||||
|
||||
Assurez vous que la **timezone** du serveur soit la bonne.
|
||||
|
||||
| champs | type | commentaire | |
|
||||
| -------------- | ---------- | ---------------------------------------------------------------------------------------------------------------- | - |
|
||||
| id / justif_id | Integer | L'identifiant du justificatif | |
|
||||
| date_debut | DateTimeTZ | La date (+heure) de début du justificatif. Doit avoir une TIMEZONE | |
|
||||
| date_fin | DateTimeTZ | La date (+heure) de fin du justificatif. Doit avoir une TIMEZONE | |
|
||||
| etudid | Integer | L'identifiant de l'étudiant concerné par le justificatif **(clé externe)** | |
|
||||
| etat | Integer | L'état du justificatif([plus d'infos](#etats-de-justificatif)) | |
|
||||
| raison | Text | La raison du justificatif**Peut être None** | |
|
||||
| entry_date | DateTimeTZ | La date (+heure) de saisie du justificatif. Doit avoir une TIMEZONE. Par défaut à la date actuelle | |
|
||||
| user_id | Integer | L'identifiant de l'utilisateur qui a saisie le justificatif. **Peut être None** **(clé externe)** | |
|
||||
| fichier | Text | l'identifiant de l'archive justificatif si existante ([plus d'infos](#gestion-des-archives-justificatives)) | |
|
||||
| external_data | JSON | Champs de données JSON non utilisé dans ScoDoc mais facilite la vie aux utilisateurs de l'API **Peut être None** | |
|
||||
|
||||
!!! tip
|
||||
Il est conseillé d'utiliser les méthodes du modèle Justificatif afin de créer / éditer / supprimer un justificatif.
|
||||
|
||||
#### Etats de Justificatif
|
||||
|
||||
!!! info
|
||||
Une classe EtatJustificatif simplifiant la traduction ETAT ↔ VALEUR est disponible dans [app/scodoc/sco_utils.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/scodoc/sco_utils.py)
|
||||
|
||||
| état | valeur |
|
||||
| ---------- | ------ |
|
||||
| VALIDE | 0 |
|
||||
| NON_VALIDE | 1 |
|
||||
| ATTENTE | 2 |
|
||||
| MODIFIE | 3 |
|
||||
|
||||
!!! warning
|
||||
Seul l'état `VALIDE` permet de justifier des assiduités. Les autres états permettent d'organiser le travail administratif.
|
||||
|
||||
#### Etudiants
|
||||
|
||||
Chaque justificatif est obligatoirement associé à un étudiant (Identite).
|
||||
Il est possible de récupérer tous les justificatifs d'un étudiant en utilisant la relation à partir du modèle Identite.
|
||||
|
||||
```py
|
||||
etudiant : Identite = Identite.get_etud(1234)
|
||||
justificatifs_etud : Query = etudiant.justificatifs
|
||||
|
||||
# Identite.justificatifs est une query et permet donc les filtrages etc.
|
||||
|
||||
# Première justificatif valide
|
||||
prem_abs: Justificatif = justificatifs_etud.filter(
|
||||
Justificatif.etat == scu.EtatJustificatif.VALIDE
|
||||
).first()
|
||||
```
|
||||
|
||||
## Fonctionnements des Assiduités
|
||||
|
||||
### Métriques
|
||||
|
||||
Les métriques d'assiduités permettent le suivi de l'assiduité d'un étudiant avec plusieurs niveaux de précisions.
|
||||
|
||||
Il existe 4 métriques :
|
||||
|
||||
- `compte` : un simple comptage du nombre d'assiduités sans autre calcul
|
||||
- `journee` : le calcul du nombre de journées concernées par les assiduités (chaque journée n'est comptée qu'une fois)
|
||||
- `demi` : le calcul du nombre de demi-journées concernées par les assiduités (chaque demi-journée n'est comptée qu'une fois)
|
||||
- `heure` : le calcul du nombre d'heures concernées par les assiduités.
|
||||
|
||||
Ces calculs sont réalisés grâce à la classe `CountCalculator` trouvable dans [app/scodoc/sco_assiduites.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/scodoc/sco_assiduites.py).
|
||||
|
||||
Il n'est pas nécessaire de créer un objet CountCalculator à chaque fois que vous voulez un calcul. Vous pouvez utiliser directement la fonction `sco_assiduites.py#get_assiduites_stats`.
|
||||
|
||||
!!! warning
|
||||
Les métriques sont utilisées dans les bulletins, sidebar et bilan.
|
||||
|
||||
Ces valeurs utilisent le [cache](#cache).
|
||||
|
||||
### Permissions
|
||||
|
||||
Les fonctions relatives aux assiduités utilisent les permissions suivantes :
|
||||
|
||||
- `AbsChange` : permet de créer / éditer / supprimer les assiduités
|
||||
- `AbsJustifView` : permet de voir les informations (descriptions) des assiduités (données personnelles cachées par défaut)
|
||||
|
||||
|
||||
## Fonctionnements des Justificatifs
|
||||
|
||||
### Permissions
|
||||
|
||||
Les fonctions relatives aux justificatifs utilisent les permissions suivantes :
|
||||
|
||||
- `AbsChange` : permet de créer / éditer / supprimer les justificatifs
|
||||
- `AbsJustifView` : permet de voir les informations (raison, fichiers) des justificatifs (données personnelles cachées par défaut)
|
||||
- `JustifValidate` : permet de changer l'état d'un justificatif de `Attente` à `Valide` / `Non Valide` / `Modifie`
|
||||
|
||||
### Gestion des archives justificatives
|
||||
|
||||
L'ensemble des fonctionnalités relatives aux archives justificatives (fichiers importés) est disponible dans le fichier [app/scodoc/sco_archives_justificatifs.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/scodoc/sco_archives_justificatifs.py)
|
||||
|
||||
!!! note
|
||||
Le système global d'archive est disponible [ici](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/scodoc/sco_archives.py)
|
||||
|
||||
Les archives sont enregistrées dans le dossier `/opt/scodoc-data/archives/`.
|
||||
|
||||
Voici la représentation de l'arborescence des fichiers justificatifs:
|
||||
|
||||
```text
|
||||
justificatif/
|
||||
└── <dept_id>/
|
||||
└── <etudid/oid>/
|
||||
└── <archive_id>/
|
||||
├── [_description.txt]
|
||||
├── [<filename.ext>]
|
||||
└── [_trace.csv]
|
||||
```
|
||||
|
||||
Les archives sont organisées par département, puis par étudiant.
|
||||
|
||||
#### Archive
|
||||
L'`archive_id` est une chaîne de caractère générée à l'importation d'un fichier. Il s'agit de la date courante au format `yyyy-mm-dd-hh-MM-ss`.
|
||||
|
||||
!!! info
|
||||
Il existe une archive par justificatif (ayant au moins un fichier importé).
|
||||
|
||||
Une archive peut contenir plusieurs fichiers. Chaque fichier est renommé de façon à avoir un nom `serveur` (ascii sans espacement).
|
||||
|
||||
##### _description.txt
|
||||
Le fichier `_description.txt` est généré par l'archiveur global mais n'est pas utilisé ici. (le fichier est vide)
|
||||
|
||||
##### _traces.csv
|
||||
|
||||
Le fichier `_trace.csv` est un fichier de log généré par l'archiveur. Il permet de tenir un registre des actions qui ont été effectuées sur l'archive. (Il est géré par sa propre classe `Trace` dans [app/scodoc/sco_archives_justificatifs.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/scodoc/sco_archives_justificatifs.py))
|
||||
|
||||
Son contenu est un CSV de la forme :
|
||||
|
||||
```csv
|
||||
nom_fichier_srv,datetime_depot,datetime_suppr,user_id
|
||||
```
|
||||
|
||||
- `nom_fichier_srv` : nom du fichier tel qu'il est enregistré sur le serveur
|
||||
- `datetime_depot` : datetime au format iso indiquant la date de dépot du fichier
|
||||
- `datetime_suppr` : datetime au format iso indiquant la date de suppression du fichier **(par défaut None)**
|
||||
- `user_id` : identifiant de l'utilisateur ayant déposé le fichier.
|
||||
|
||||
!!! info
|
||||
le champs `user_id` est utilisé par ScoDoc pour afficher au non le fichier aux utilisateurs.
|
||||
|
||||
Seuls l'utilisateur qui a importé le fichier et ceux ayant la permission `JustifView` peuvent voir le fichier.
|
||||
|
||||
#### Gestion des fichiers
|
||||
|
||||
La classe `JustificatifArchiver` possède plusieurs fonctions pour simplifier la gestion des fichiers.
|
||||
|
||||
- `save_justificatif` : enregistre un fichier pour un étudiant. Génère l'archive si elle n'existe pas. Génère le fichier trace s'il n'existe pas et log le fichier. Renvoie le nom de l'archive et le nom du fichier (traduit en nom serveur).
|
||||
- `delete_justificatif` : supprime un fichier d'une archive d'un étudiant. (Ajoute à la trace l'action). Si on ne donne pas de nom de fichier, supprime l'archive (et donc tous ses fichiers).
|
||||
- `list_justificatifs` : retourne la liste des fichiers avec l'user_id de l'importateur.
|
||||
- `get_justificatif_file` : renvoie une réponse de téléchargement (pour les vues) du fichier demandé.
|
||||
- `remove_dept_archive` : supprime toutes les archives d'un département, supprime aussi toutes les traces
|
||||
|
||||
|
||||
## Cache
|
||||
|
||||
Le module assiduité utilise le cache pour stocker temporairement certaines informations qui demandent des calculs importants.
|
||||
|
||||
### Classes liées
|
||||
|
||||
Il y a deux classes concernant les caches du module :
|
||||
|
||||
- `RequeteTableauAssiduiteCache` qui gère les caches liés aux calendrier et tableaux d'assiduité.
|
||||
- `AbsSemEtudCache` qui gère les caches liés aux comptes d'absences (nonjust et just) utilisées dans les semestres
|
||||
|
||||
!!! info
|
||||
Les classes liées aux caches se retrouvent dans le fichier [app/scodoc/sco_cache.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/scodoc/sco_cache.py)
|
||||
|
||||
### Fonctions liées
|
||||
|
||||
Des fonctions simplifiant la gestion des caches sont disponibles dans [app/scodoc/sco_assiduites.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/scodoc/sco_assiduites.py) (aussi appelé `scass`)
|
||||
|
||||
#### Récupération de valeurs
|
||||
|
||||
- `get_assiduites_count(etudid: int, sem: dict)` : retourne le nombre d'absences de l'étudiant dans le semestre donné.
|
||||
- `formsemestre_get_assiduites_count(etudid: int, formsemestre: FormSemestre, moduleimpl_id: int = None)` : retourne le nombre d'absences de l'étudiant dans le semestre donné. (filtrage avec un moduleimpl possible)
|
||||
- `get_assiduites_count_in_interval` : fonction utilisée par les deux fonctions du dessus (et par d'autres) qui s'occupe du calcul et de la mise en cache.
|
||||
|
||||
!!! info
|
||||
Les valeurs des tableaux sont directement calculés dans la génération des tableaux. Plus d'informations dans la partie dédiée aux [tableaux](#tableaux)
|
||||
|
||||
#### Invalidations
|
||||
|
||||
- `simple_invalidate_cache(obj: dict, etudid: str | int = None)` : invalide le cache à partir d'un objet et d'un etudiant. Permet d'invalider tous les caches (semestre **et** tableaux).
|
||||
- `invalidate_assiduites_count(etudid: int, sem: dict)` : invalide les calculs d'absences (nb just/njust) pour un semestre
|
||||
- `invalidate_assiduites_etud_date(etudid: int, the_date: datetime)` : invalide les cache de semestre,bulletin et absence (calcul nb just, njust)
|
||||
|
||||
!!! tip
|
||||
Le plus simple pour invalider le cache est d'utiliser la fonction `simple_invalidate_cache` car elle invalide tous les caches en utilisant les autres fonctions d'invalidation.
|
||||
|
||||
C'est la fonction la plus sûre concernant l'invalidation des caches du module Assiduité.
|
||||
|
||||
## Vues
|
||||
|
||||
Le module Assiduité propose des éléments variés pour les pages.
|
||||
|
||||
Ces éléments sont ensuite utilisés dans le script de vue du module ([app/views/assiduites.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/views/assiduites.py))
|
||||
|
||||
### Calendriers
|
||||
|
||||
Le module assiduité propose un calendrier pour voir l'assiduité d'un étudiant sur une année.
|
||||
|
||||
La vue se nomme `calendrier_assi_etud` et peut servir d'exemple sur l'utilisation du générateur de calendrier (les classes `JourAssi` et `CalendrierAssi` sont définies en bas du script de la vue)
|
||||
|
||||
La génération des calendriers utilise le script [app/scodoc/sco_gen_cal.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/scodoc/sco_gen_cal.py)
|
||||
|
||||
!!! tip
|
||||
Ce même script possède la fonction `calendrier_choix_date` permettant d'afficher un calendrier pour choisir un jour ou une semaine entre deux dates données.
|
||||
|
||||
### Formulaires
|
||||
|
||||
Les formulaires sont une partie importante des UI du module Assiduité.
|
||||
|
||||
L'ensemble des formulaires du module peut se trouver dans les fichiers suivants :
|
||||
|
||||
- [app/forms/assiduite/ajout_assiduite_etud.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/forms/assiduite/ajout_assiduite_etud.py) : Formulaires d'ajout d'une assiduité, d'ajout d'un justificatif et de modification d'un justificatif
|
||||
- [app/forms/assiduite/edit_assiduite_etud.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/forms/assiduite/edit_assiduite_etud.py) : Formulaire de modification d'une assiduité
|
||||
|
||||
Ces formulaires (basés sur Flask-WTF) sont ensuite utilisés dans les [templates jinja](#templates).
|
||||
|
||||
### Tableaux
|
||||
|
||||
Il y a 2 type de tableaux d'assiduité. Le tableau simple utilisé dans la page `visu_assi_group` et les tableaux complexes qui sont présentés dans les pages suivantes :
|
||||
|
||||
- `bilan_dept`
|
||||
- `bilan_etud`
|
||||
- `ajout_assiduite_etud`
|
||||
- `ajout_justificatif_etud`
|
||||
- `recup_assiduites_plage`
|
||||
|
||||
Les tableaux simples sont gérés par le fichier [app/tables/visu_assiduites.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/tables/visu_assiduites.py)
|
||||
|
||||
Les tableaux complexes sont gérés par le fichier [app/tables/liste_assiduites.py](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/tables/liste_assiduites.py). Ceux-ci sont plus polyvalents et utilise le système de cache.
|
||||
|
||||
!!! info
|
||||
Une fonction a été écrite pour faciliter la préparation des tableaux complexes, elle se nomme `_prepare_tableau` et se trouve dans le fichier de [vues](#vues).
|
||||
|
||||
La vue `recup_assiduites_plage` est un bon exemple d'utilisation des tableaux complexes.
|
||||
|
||||
|
||||
### Templates
|
||||
|
||||
L'ensemble des templates du module assiduité est organisé dans le dossier [app/templates/assiduites](https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/templates/assiduites)
|
||||
|
||||
On y retrouvera les `pages` (l'organisation des éléments de UI/UX et des scripts de fonctionnement) et les `widgets` (Des éléments d'UI/UX qui seront intégrés dans une page)
|
||||
|
||||
Les templates liés aux pages ont le même nom que la vue qui l'utilise.
|
||||
|
||||
Exemple : `ajout_assiduite_etud` → `ajout_assiduite_etud.j2`
|
86
docs/AssiduitesMigration.md
Normal file
86
docs/AssiduitesMigration.md
Normal file
@ -0,0 +1,86 @@
|
||||
# Migration des absences de ScoDoc 9.5 vers les assiduités 9.6
|
||||
|
||||
Lors du passage de ScoDoc 9.5 à 9.6, les anciennes données d'absences et
|
||||
justificatifs sont traduites pour [le module assiduités](Assiduites.md).
|
||||
|
||||
## Script de Migration
|
||||
|
||||
Le script se nomme `migrate-abs-to-assiduites` et ne peut se lancer qu'en ligne
|
||||
de commande:
|
||||
|
||||
```bash
|
||||
su scodoc # au besoin
|
||||
cd /opt/scodoc
|
||||
source venv/bin/activate
|
||||
|
||||
flask migrate-abs-to-assiduites --help
|
||||
```
|
||||
|
||||
Par défaut, la migration s'opérera sur l'ensemble des départements en utilisant
|
||||
les préférences de ScoDoc.
|
||||
|
||||
Néanmoins le script possède 4 options pour modifier son comportement :
|
||||
|
||||
- `-d, --dept`
|
||||
Permet de restreindre la migration à un département à l'aide de son acronyme.
|
||||
Utilisation : `flask migrate-abs-to-assiduites -d <ACRONYME>`
|
||||
- `-m, --morning`
|
||||
Permet de définir l'heure de début des cours.
|
||||
Utilisation : `flask migrate-abs-to-assiduites -m <hh:mm>`
|
||||
exemple : `hh:mm` -> `08:30`
|
||||
- `-n, --noon`
|
||||
Permet de définir l'heure de fin du matin (= l'heure de début de l'après-midi).
|
||||
Utilisation : `flask migrate-abs-to-assiduites -n <hh:mm>`
|
||||
exemple : `hh:mm` -> `13:30`
|
||||
- `-e, --evening`
|
||||
Permet de définir l'heure de fin des cours.
|
||||
Utilisation : `flask migrate-abs-to-assiduites -e <hh:mm>`
|
||||
exemple : `hh:mm` -> `18:30`
|
||||
|
||||
Les options peuvent s’enchaîner : `flask migrate-abs-to-assiduites -d TEST -m 10:30 -n 14:50 -e 19:45`
|
||||
|
||||
Lors du lancement du script, une barre de progression apparaîtra. Celle si vous
|
||||
indique l'avancée de la transformation des absences en assiduités.
|
||||
|
||||
Une fois arrivée à 100%, Un processus de validation et de justification des
|
||||
assiduités se lancera. Celui-ci peut (suivant les configurations) prendre un
|
||||
certain temps. Veuillez ne pas le stopper en cours de route.
|
||||
|
||||
Lorsque la migration sera finie, un fichier log de la migration sera généré pour
|
||||
chaque département. Vous recevrez aussi des statistiques sur le nombre de
|
||||
justificatif et d'assiduités générés.
|
||||
|
||||
## Script de Suppression
|
||||
|
||||
En cas de problème, ou si vous souhaitez purger la base de donnée, un script de
|
||||
suppression des assiduités et des justificatifs est disponible.
|
||||
|
||||
Le script se nomme `downgrade-assiduites-module`.
|
||||
|
||||
Si vous lancer le script sans aucune option, il ne se passera rien.
|
||||
|
||||
Voici les options :
|
||||
|
||||
- `-d, --dept`
|
||||
Permet de restreindre la suppression à un département à l'aide de son acronyme.
|
||||
Utilisation : `flask downgrade-assiduites-module -d <ACRONYME>`
|
||||
- `-a, --assiduites`
|
||||
Provoque la suppression de toutes les assiduités
|
||||
Utilisation : `flask downgrade-assiduites-module -a`
|
||||
- `-j, --justificatifs`
|
||||
Provoque la suppression de tous les justificatifs
|
||||
Utilisation : `flask downgrade-assiduites-module -j`
|
||||
|
||||
Quelques exemples :
|
||||
|
||||
- Pour tout supprimer : `flask downgrade-assiduites-module -a -j`
|
||||
- Pour supprimer un département : `flask downgrade-assiduites-module -d DEPT -a -j`
|
||||
- Pour supprimer l'assiduité d'un département : `flask downgrade-assiduites-module -d DEPT -a`
|
||||
- Pour supprimer les justificatifs d'un département : `flask downgrade-assiduites-module -d DEPT -j`
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Le module assiduités](Assiduites.md)
|
||||
- [Mise à jour vers ScoDoc 9.6 / Debian 12](UpgradeToDeb12Sco96.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
@ -1,6 +1,5 @@
|
||||
# Association 1901 ScoDoc
|
||||
|
||||
|
||||
ScoDoc est un logiciel libre et gratuit, Open Source.
|
||||
|
||||
Le développement du projet a été porté par son créateur, Emmanuel Viennet,
|
||||
@ -8,26 +7,26 @@ professeur à l'université Sorbonne Paris Nord (ex Paris 13), plusieurs fois ch
|
||||
du département Réseaux et Télécommunications de l'IUT de Villetaneuse et
|
||||
Président de l'ACD R&T. Plusieurs collègues bénévoles ont contribué, corrigeant
|
||||
ou ajoutant des fonctions. Ils sont enseignants ou BIATSS dans les IUT de
|
||||
Colmar, Ville d'Avray, Grenoble, Le Havre, Lille, Nantes, pour ne citer que
|
||||
ceux-là.
|
||||
Colmar, Ville d'Avray, Grenoble, Le Havre, Lille, Lyon, Mulhouse, Nantes, pour
|
||||
ne citer que ceux-là.
|
||||
|
||||
Le développement d'un logiciel de cette ampleur prend du temps et demande des
|
||||
moyens matériels : serveurs, machines de développement et de test. La
|
||||
possibilité de recruter des stagiaires, apprentis ou CDD pour travailler sur le
|
||||
projet a souvent été évoquée. Pour se donner ces possibilités et pérenniser le
|
||||
projet, nous avons créé début 2020 une association à but non lucratif (loi
|
||||
1901).
|
||||
1901).
|
||||
|
||||
Les établissements ou départements qui utilisent ScoDoc sont encouragés à
|
||||
adhérer à l'association. Leur cotisation permettra de financer les actions de
|
||||
l'association et leur permettra d'accéder aux nouvelles fonctionnalités, mise à
|
||||
jour et support technique.
|
||||
jour et support technique.
|
||||
|
||||
Plusieurs types d'adhésion sont possibles, voir le [bulletin d'adhésion
|
||||
PDF](papers/Adhesion-2022-2023-Association-ScoDoc.pdf) ([version
|
||||
Word](papers/Adhesion-2022-2023-Association-ScoDoc.docx)), à renvoyer à
|
||||
PDF](papers/Adhesion-2024-2025-Association-ScoDoc.pdf) ([version
|
||||
Word](papers/Adhesion-2024-2025-Association-ScoDoc.docx)), à renvoyer à
|
||||
<emmanuel.viennet@gmail.com>. (note: toutes les informations nécessaires à la
|
||||
"création fournisseur" sont sur le bulletin d'adhésion).
|
||||
|
||||
Nous vous remercions de votre support qui rendra possible la pérennité du projet
|
||||
ScoDoc.
|
||||
ScoDoc.
|
||||
|
@ -1,248 +1,398 @@
|
||||
## Jury et avis de Poursuites d'Etudes
|
||||
# Jury de Poursuites d'Etudes BUT
|
||||
|
||||
Partant d'un semestre sélectionné, l'onglet **Statistiques > Documents Avis de Poursuite d'Etudes** (ci-dessous appelé **outil PE**) propose une aide à la tenue du jury et à l'édition des avis de poursuites d'études pour les étudiants de DUT.
|
||||
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.1/css/all.min.css">
|
||||
|
||||
|
||||
<i class="fa-solid fa-triangle-exclamation" style="color: darkred"></i>
|
||||
**Attention** : cette **fonctionnalité** est en cours de révision pour le BUT
|
||||
depuis janvier 2024 ; les documents (avis) en LaTeX ne sont plus générés dans
|
||||
cette nouvelle version : seul des classeurs excel sont générés. Merci de vos
|
||||
retours.
|
||||
|
||||
### Les tags
|
||||
## Cadre d'usage et nomenclature
|
||||
|
||||
Les avis (demandés par les différents établissements post-DUT) attendent fréquemment des moyennes transverses aux modules voire aux
|
||||
semestres du PPN : par exemple, moyenne sur les matières théoriques, les matières techniques,
|
||||
moyenne en français, etc...
|
||||
Un jury de Poursuites d'Etudes émet des avis sur la capacité des étudiants à
|
||||
intégrer une formation post-BUT (master, écoles d'ingénieur, écoles de commerce,
|
||||
...) en s'appuyant sur l'ensemble des résultats qu'ont obtenus les étudiants au
|
||||
cours de leur scolarité de BUT.
|
||||
|
||||
L'outil PE permet le calcul de ces moyennes en utilisant des **tags** affectés aux modules dans le **Programme** de formation.
|
||||
Tous les modules portant le même tag (attention à la casse et à l'accentuation) seront intégrés ensemble dans le calcul de la moyenne.
|
||||
Les étudiants considérés sont ceux d'une **promotion** :
|
||||
|
||||
> Une **promotion** est l'ensemble des étudiants qui recevront leur **diplôme**
|
||||
> la même année, quelque soit leurs _semestres_, leurs _parcours_, leurs
|
||||
> _modalités_ d'apprentissage (formation initiale ou apprentissage) ou leurs
|
||||
> redoublements éventuels.
|
||||
|
||||
|
||||
Les avis émis s'appuient sur différents critères (**notes moyennes/classements**) obtenus :
|
||||
|
||||
* sur des **moyennes prévues dans le règlement des études** : moyenne par
|
||||
**UE**, par **niveau de compétence** (regroupement cohérent d'UE)
|
||||
* sur des **moyennes _personnalisées_** (cf. tag), souvent demandées par les
|
||||
formations post-BUT dans les dossiers de candidature des étudiants : moyenne
|
||||
en anglais, en mathématiques, en français, ...
|
||||
* à **différents instants de la scolarité** (cf. regroupement cohérent de
|
||||
semestres) des étudiants : moyenne en 1ère année, en 2ème année, sur 3 ans,
|
||||
...
|
||||
* sur des **interclassements**, classant les étudiants indépendamment du
|
||||
_chemin_ (parcours, modalité, redoublement, ...) qu'ils ont parcouru au cours
|
||||
de leur scolarité de BUT.
|
||||
|
||||
Voici l'exemple du programme du DUT RT taggué (figure ci-dessous), où par exemple, le tag *mathématiques* est affecté à tous les
|
||||
modules du programme en lien avec des maths.
|
||||
Ces critères variant d'un établissement à un autre et d'un dossier de
|
||||
candidature à un autre, la fonctionnalité **Jury de Poursuites d'Etudes** de
|
||||
Scodoc (appelée ci-dessous **outil PE**) fournit un **ensemble de notes
|
||||
moyennes/classements le plus large possible** centralisé dans des tableurs xlsx,
|
||||
pour en avoir différentes vues.
|
||||
|
||||
Les tags peuvent également faire mention d'un coefficient servant à la pondération des modules dans le calcul de la moyenne (cf. section coefficient).
|
||||
Le tag sera alors de la forme : `nom_du_tag:coeff_entier`.
|
||||
> A vous de _piocher_ dans les données fournies en fonction de vos besoins pour
|
||||
> construire votre tableur émettre vos avis et renseigner les dossiers de
|
||||
> candidature de vos étudiants.
|
||||
|
||||
Un tag *dut* reprenant la moyenne de l'étudiant à chaque semestre est automatiquement ajouté.
|
||||
***
|
||||
|
||||
![programmeRTtaggue.png](screens/programmeRTtaggue.png)
|
||||
## Premiers pas
|
||||
|
||||
<i class="fas fa-eye" style="color: teal"></i> Dans la suite, sera pris
|
||||
l'exemple du jury des poursuites d'études **2024**, qui traitera TOUS les
|
||||
étudiants qui termineront leur scolarité (généralement en juin) 2024 : vos
|
||||
diplômés de la **promotion 2024**.
|
||||
|
||||
### Les moyennes
|
||||
### Générer l'archive zip des documents standards
|
||||
|
||||
#### Les moyennes intra et inter semestres
|
||||
1. Editer n'importe lequel des semestres Scodoc dans lequel à étudier un
|
||||
étudiant de la promotion (quelque soit sa _modalité d'apprentissage_ ou son
|
||||
_parcours_). <i class="fas fa-eye" style="color: teal"></i> Par exemple, un
|
||||
semestre 5 2023-2024.
|
||||
2. Partant du semestre sélectionné, l'onglet `Statistiques` > `Documents Avis de Poursuite d'Etudes`.
|
||||
3. `Générer les documents` pour télécharger l'archive zip du jury. <i class="fas
|
||||
fa-eye" style="color: teal"></i> Dans notre exemple, <i class="fa-solid
|
||||
fa-file" style="color: orange"></i> `Jury_PE_2024.zip`
|
||||
|
||||
Au delà du "thème" des moyennes, les avis attendent parfois que ces moyennes soient calculées sur plusieurs semestres : moyenne en 1ère année, en 2ème année
|
||||
voire (pour le jury) sur l'ensemble du parcours de l'étudiant. 8 plages de calculs temporelles sont donc prévus pour ces moyennes : pour chaque tag,
|
||||
<i class="fa-solid fa-triangle-exclamation" style="color: darkred; font-size:
|
||||
200%"></i> L'outil PE n'analyse pas seulement les futurs diplômés ; il analyse
|
||||
également TOUS les étudiants que vos diplômés ont cotoyés dans leur scolarité,
|
||||
mais qui ont démissionné, abandonné, redoublé (cf. <i class="fa-solid fa-file"
|
||||
style="color: orange"></i>`Jury_PE_2024.zip` > `details/etudiants.xlsx`) car ils
|
||||
impactent les classements. De fait, <i class="fas fa-eye" style="color:
|
||||
teal"></i> pour un jury de semestre 5 :
|
||||
* si vous avez commencé à peupler des semestres 6, assurez-vous que tous vos
|
||||
diplômés y soient inscrits, au risque que l'outil les croit démissionnaires.
|
||||
* si vous avez créé les semestres 6 mais sans étudiant inscrits, pas de souci !
|
||||
|
||||
* le label **S1** (respectivement S2, S3, S4) désigne une moyenne sur ce tag calculée sur le **S1** (respectivement S2, S3, S4) - ou plus précisement sur les modules du **S1** (respectivement S2, S3, S4) ayant été associé au tag considéré
|
||||
* le label **1A** (respectivement 2A) désigne une moyenne sur ce tag calculée sur la **première année** (respectivement la deuxième année) - ou plus précisement sur tous les modules **du S1 et du S2** (respectivement du S3 et du S4) ayant été associé au tag considéré
|
||||
* le label **3S** (souvent utilisé dans un jury de poursuites d'études se tenant juste après le S3) désigne une moyenne sur ce tag calculée sur l'**ensemble du parcours allant du S1 au S3** (inclus) - ou plus précisement sur tous les modules **du S1, S2, S3** ayant été associé à ce tag.
|
||||
* le label **4S** désigne une moyenne sur ce tag calculée sur l'**ensemble du parcours allant du S1 au S4** (inclus) - donc plus précisement sur tous les modules du programme ayant été associé à ce tag.
|
||||
### Contenu de l'archive zip
|
||||
|
||||
#### Les coefficients de pondération
|
||||
L'archive obtenue contient plusieurs tableurs :
|
||||
|
||||
Par défaut, les moyennes calculées sur les modules associés à un tag donné utilisent
|
||||
les coefficients de pondération des modules dans le programme DUT, ramenés au total des
|
||||
coefficients dans les semestres qui les concernent : partant d'un semestre \(i\), en notant :
|
||||
1. <i class="fa-solid fa-file" style="color: orange"></i>
|
||||
`synthese_jury_par_tag.xlsx` : résume les données du jury de votre promotion
|
||||
dans différents onglets :
|
||||
|
||||
* \(m_{i,j}\) la note d'un étudiant à un module associé au tag dans le semestre \(i\) (\(j\) donnant donc le numéro du module au sein du semestre parmi les modules associés au tag),
|
||||
* \(c_{i,j}\) le coefficient du module \(m_{i,j}\) dans le programme de formation
|
||||
* l'onglet `but` s'appuie sur des moyennes de semestre (cf. plus bas)
|
||||
* plusieurs onglets nommés `comp. <titre_competence>` (dépendant des
|
||||
_parcours_ de votre formation) retracent les moyennes/classements obtenues
|
||||
dans les différentes UE rattachées à la `competence`
|
||||
|
||||
alors la moyenne \(M_i\) associée au tag pour le semestre \(i\) est calculée avec :
|
||||
$$
|
||||
M_i = \frac{ \sum_{j} c_{i,j} m_{i,j} }{ \sum_{j} c_{i,j} }
|
||||
$$
|
||||
Il peut être utilisé pour :
|
||||
|
||||
En notant ensuite \(c_i\) la somme des coefficients des modules du semestre \(i\) associé au tag considéré (ici \(c_i = \sum_{j} c_{i,j}\))
|
||||
et \(C_i\) la somme des coefficients de tous les modules (y compris ceux n'étant pas associés au tag considéré) du semestre \(i\) (donc \(C_i \geq c_i\)), la
|
||||
moyenne \(M\) associée au tag sur les 4 semestres de formation (donc de label **4S**) est calculée avec :
|
||||
$$
|
||||
M = \frac{ \sum_{i} \frac{c_i}{C_i} M_i }{ \sum_{i} \frac{c_i}{C_i} }
|
||||
$$
|
||||
Plus simplement, le poids des modules associés au tag au sein d'un semestre est conservé dans le calcul de la moyenne.
|
||||
* préparer (en piochant) les moyennes/classements qui vous intéressent
|
||||
* intégrer une solution de publipostage (non proposée par l'outil PE) pour
|
||||
générer les **fiches d'avis PE** à transmettre aux étudiants pour leur
|
||||
dossier de candidature
|
||||
|
||||
L'outil PE offre la possibilité de recoefficienter les modules associés au tag dans le calcul de la moyenne en
|
||||
leur joignant un (éventuel) coefficient de pondération supplémentaire entier \(p_{i,j}\) (voir section Les tags).
|
||||
2. <i class="fa-solid fa-file" style="color: orange"></i>
|
||||
`synthese_jury_par_etudiants.xslx` : résume les données de chaque étudiant
|
||||
dans un onglet qui lui est propre. Il peut être utilisé pour
|
||||
communiquer/transmettre à l'étudiant ses moyennes/classements pour préparer
|
||||
ses dossiers
|
||||
|
||||
Dans ce cas, la moyenne \(M_i\) associée au tag sur le semestre \(i\) est impactée avec :
|
||||
$$
|
||||
M_i = \frac{ \sum_{j} p_{i,j} c_{i,j} m_{i,j} }{ \sum_{j} p_{i, j} c_{i,j} }
|
||||
$$
|
||||
La somme des coefficients des modules dans le semestre \(c_i\) devient \(c_i = \sum_{j} p_{i,j} c_{i,j}\) mais la somme
|
||||
des coefficients de tous les modules \(C_i\) reste inchangée.
|
||||
3. des tableurs dans `details` qui traduisent les différentes étapes de calcul
|
||||
faites par l'outil et sont plutôt destinés aux <i class="fa-solid
|
||||
fa-bullseye" style="color: violet"></i> développeurs
|
||||
|
||||
Plus simplement, l'idée de cette pondération est de conserver le poids des modules au sein du semestre
|
||||
tout en accord plus d'importance (lorsque \(p_{i,j} > 1\)) à la note obtenue par l'étudiant.
|
||||
## Moyennes personnalisées : les tags¶
|
||||
|
||||
Le calcul des moyennes intra-semestres (1A, 2A ou 3S) est basée sur le même principe en n'utilisant que les semestres concernés.
|
||||
Pour obtenir des **moyennes personnalisées** (par exemple moyenne en
|
||||
mathématiques, en anglais, en expression-communication, ...), l'outil s'appuie
|
||||
sur un système de **tags**.
|
||||
|
||||
#### Cas des étudiants redoublants
|
||||
> Les tags sont des _mots-clés_ (courts et sans caractères spéciaux) affectés à
|
||||
> des modules (ressources ou SAEs) dans le `Programme de formation`. <i
|
||||
> class="fa-solid fa-triangle-exclamation" style="color: darkred"></i> Ils ne
|
||||
> peuvent pas être `but` ni `comp. <titre_competence>` (réservés par l'outil).
|
||||
|
||||
Dans le cas des étudiants redoublants (par exemple ayant fait 2 semestres S1), ne sont conservés que les notes obtenues dans les UE validées
|
||||
par les décisions de jury : dans l'exemple, il s'agira (le plus souvent) des notes du S1 le plus récent, sauf pour un étudiant qui aurait capitalisé
|
||||
une UE et dont une partie des notes proviendrait de son UE capitalisée.
|
||||
Tous les modules portant le même tag (<i class="fa-solid
|
||||
fa-triangle-exclamation" style="color: darkred"></i> à la casse et à
|
||||
l'accentuation) seront _intégrés_ ensemble dans le calcul de
|
||||
moyennes/classements pour ce tag. Elles apparaitront sous la forme d'un nouvel
|
||||
onglet dans <i class="fa-solid fa-file" style="color: orange"></i>
|
||||
`synthese_jury_par_etudiants.xslx`.
|
||||
|
||||
### Les classements et les statistiques
|
||||
### Renseigner les tags
|
||||
|
||||
Les avis demandent souvent le classement associé à la moyenne obtenue sur un tag et pour un temps donné (label 1A, 2A, ...) avec l'ambiguité
|
||||
de la cohorte considérée. Ce classement peut aller de pair avec des données statistiques (nombre d'étudiants, note minimum, maximum, moyenne sur la cohorte).
|
||||
L'outil PE propose deux cohortes et donc deux séries de classement/statistique par tag et label temporel.
|
||||
Après avoir sélectionné un _programme de formation_ depuis le menu `Programmes` :
|
||||
|
||||
#### La "cohorte" filière
|
||||
![Ajouter des tags](img/ajouter_tags.png)
|
||||
|
||||
Est appelé filière l'ensemble des étudiants inscrits dans le même semestre temporel que le dernier impliqué dans la moyenne calculée. Prenons l'exemple
|
||||
d'une moyenne sur le tag mathématiques portant sur le label 3S (c'est à dire sur les semestres S1, S2, et S3). La filière sera l'ensemble des étudiants inscrits
|
||||
dans le S3. Dans ce S3, pourront se trouver des étudiants de différents parcours comme :
|
||||
1. Cochez `Montrer les tags...`
|
||||
2. Renseigner pour chaque module le ou les tags souhaités (<i class="fa-solid
|
||||
fa-bullseye" style="color: violet"></i> ici 3 tags : réseaux, ressources,
|
||||
techniques )
|
||||
|
||||
* des étudiants "standards" avec S1 validé, S2 validé, S3 validé (du premier coup)
|
||||
* des étudiants redoublants avec (par exemple) un parcours de la forme S1 validé, S2 non validé, S3 non validé, S2 validé, S3 validé (dont étant entrés à l'IUT un an avant les étudiants "standards").
|
||||
<i class="fa-solid fa-lightbulb" style="color: gold"></i> Le menu `Tagguer tous
|
||||
les modules par leur type (tag res, sae)` (après la description des ressources
|
||||
et des SAEs) permettant de tagguer automatiquement les ressources avec le tag
|
||||
`res` et les SAEs avec le tag `sae`.
|
||||
|
||||
De fait, les notes prises en compte pour les étudiants standards et les étudiants redoublant pourront provenir de modules ne s'étant pas tenus
|
||||
aux même universitaires. Les seuls modules communs garantis seront ceux du S3 (aka le dernier semestre de l'ensemble S1+S2+S3).
|
||||
<i class="fa-solid fa-triangle-exclamation" style="color: darkred; font-size:
|
||||
200%"></i> Si vos étudiants ont suivi plusieurs programmes de formation
|
||||
différents, tous leurs programmes doivent être taggués.
|
||||
|
||||
#### La "cohorte" promo
|
||||
### Paramètrer les coefficients des tags
|
||||
|
||||
Est appelé promo 20XX l'ensemble des étudiants susceptibles de valider leur diplôme DUT en date de juillet 20XX quelque soit le programme de formation DUT
|
||||
suivi.
|
||||
Les tags peuvent faire mention d'un **coefficient** servant à la pondération des
|
||||
modules dans le calcul de la moyenne (cf. section coefficient). Le tag sera
|
||||
alors de la forme : `nom_du_tag:coeff_entier`.
|
||||
|
||||
Par exemple, la promo 2017 inclut les étudiants qui valideront leur S4 en juillet 2017 ; ceux ayant validé leur S4 en juillet 2016 appartiennent à la promo 2016.
|
||||
Parmi les étudiants de la promo 2017, on retrouve les étudiants "standards" étant entrés à l'IUT en septembre 2015 avec un parcours S1 validé, S2 validé, S3 validé et S4 validé.
|
||||
On retrouve également les étudiants entrés à l'IUT en septembre 2014 et ayant redoublé 1 à 2 semestres donc validant leur S4 entre janvier et juillet 2017. Les étudiants
|
||||
ayant démissionnés ou s'étant réorientés (aka. ne s'étant pas réinscrit dans un semestre DUT là où il aurait "du" le faire) sont exclus de la promo.
|
||||
## Regroupements cohérents de semestre
|
||||
|
||||
Remarque: les calculs des étudiants de la promo fonctionnent à condition que les dates des semestres de début d'année universitaire s'étalent sur 2 années civiles (par exemple
|
||||
S1 de septembre 2016 à janvier 2017) et que les dates des semestres de fin d'année universitaire sont limitées à une année civile (par exemple S2 de janvier à juillet 2017).
|
||||
|
||||
#### Les classements
|
||||
Les moyennes (quelque soit le tag) peuvent être calculées sur plusieurs
|
||||
semestres appelés **regroupements cohérents de semestres** : moyenne en 1ère
|
||||
année, en 2ème année voire (pour le jury) sur l'ensemble des semestres (même
|
||||
redoublés) qu'a suivi un étudiant.
|
||||
|
||||
Un élève au regard de sa moyenne à un tag, sur un laps de temps donné (label S1, 1A, 3S, ...) est donc classé soit sur sa filière soit sur la promo. Les statistiques
|
||||
du groupe (que ce soit la filière ou la promo), plus précisément la note minimum, maximum et la moyenne du groupe sont également fournies.
|
||||
> Un **regroupement cohérent de semestres** (RCS) est un ensemble de semestres
|
||||
> suivis par les étudiants formant un tout cohérent pour calculer une moyenne
|
||||
> sur plusieurs semestres.
|
||||
|
||||
## L'export du tableur récapitulatif
|
||||
Globalement, 3 types de regroupements cohérents de semestres sont fournis :
|
||||
|
||||
L'onglet PE renvoie une archive zip pour une promotion d'élèves diplômés en 20XX,
|
||||
contenant notamment un fichier Jury_PE_20XXjurySyntheseDict_20XX_v2.xls. Ce fichier récapitule l'ensemble des moyennes, des classements et des statistiques
|
||||
des élèves dont le S4 sera (prévisiblement) validé en 20XX. Le fichier contient un tab par tag saisi dans le programme. Par défaut, un tag est présent :
|
||||
le tag dut. En plus des données numériques, on retrouve pour chaque élève la liste des semestres parcourues (colonne P1 à P6).
|
||||
* Les RCS `Semestre <n>` (avec `<n>` le numéro du semestre parmi 1, 2, 3, 4, 5,
|
||||
6) désignent la moyenne (pour chaque tag) calculée en utilisant les notes du
|
||||
(ou des) semestre `<n>`.
|
||||
|
||||
* Les RCS `BUT<a>` (avec `<a>` le numéro de l'année parmi 1, 2, 3) désignent la
|
||||
moyenne calculée sur les deux semestres d'une même année `<a>`.
|
||||
|
||||
* Les RCS `Moyenne du semestre <ini> à <final>` désignent les moyennes calculées
|
||||
en utilisant toutes les notes du semestre `<ini>` au semestre `<final>`. Plus
|
||||
particulièrement:
|
||||
|
||||
## Les avis PE au format LaTeX
|
||||
* Le RCS `Moyenne du semestre 1 à 5` (intégrant les semestres
|
||||
S1+S2+S3+S4+S5) peut être utile pour une vue d'ensemble des résultats -
|
||||
sur 5 semestres - lors d'un jury se tenant au S5 pour des avis de
|
||||
poursuites d'études
|
||||
|
||||
L'archive zip contient également un export des données de poursuites d'études de la promotion d'élèves au format LaTeX (fichier .tex) pour permettre (après compilation latex à faire sur votre machine) de génerer des avis de poursuites d'études des étudiants "quasi prêts à l'emploi" (pour impression ou envoi par mail).
|
||||
* Le RCS `Moyenne du semestre 1 à 3` (intégrant les semestres S1+S2+S3) peut
|
||||
être utile pour une vue d'ensemble des résultats - sur 3 semestres - lors
|
||||
d'un jury se tenant au S3 pour des avis de _réorientation_ (pour rester
|
||||
_politiquement correct_).
|
||||
|
||||
### Arborescence LaTeX
|
||||
|
||||
Les sources latex (fournies ici dans le fichier zip exporté par ScoDoc) s'articulent autour de l'arborescence suivante :
|
||||
```
|
||||
avis.tex # Fichier principal point d'entrée du compilateur latex
|
||||
avis_poursuite.tex # Fichier permettant d'inclure les avis des étudiants et fourni par ScoDoc
|
||||
avis_poursuite_nom_prenom_identifiant.tex # Avis de poursuite d'études d'un étudiant généré suivant le template
|
||||
avisPE.cls # Classe LaTex pour paramètrant la mise en page du document
|
||||
README.txt # Informations de configuration pour les administrateurs de ScoDoc
|
||||
logos # Répertoire contenant les figures (375 x 256 où toutes autres proportions équivalentes)
|
||||
+ logo_header.png # Le logo de l'établissement à adapter à vos besoins
|
||||
+ logo_footer.png # Un second logo pour le pied de page
|
||||
modeles # Répertoire contenant des macros pour la mise en forme latex
|
||||
+ un_avis.tex # Modèle pour la génération de avis_poursuite_nom_prenom_EID0000.tex
|
||||
+ parcourstimeline.tex # Ligne temporelle retraçant le parcours d'un étudiant
|
||||
+ un_footer.tex # Modèle pour le pied de page des avis PE
|
||||
```
|
||||
<i class="fa-solid fa-triangle-exclamation" style="color: darkred; font-size:
|
||||
200%"></i> Dans le cas des étudiants redoublants, seront **systématiquement**
|
||||
pris en compte les notes des semestres redoublés :
|
||||
|
||||
La compilation pourra se lancer avec : `pdflatex avis.tex`
|
||||
|
||||
Le mode de calcul des moyennes de chaque regroupement cohérent de semestres
|
||||
dépend du regroupement et du tag (cf. décription à suivre).
|
||||
|
||||
### Template LaTeX
|
||||
|
||||
Les avis LaTeX sont générés à partir de deux *templates latex*, dont le contenu est fourni dans modeles/un_avis.tex et modeles/un_footer.tex de l'archive avis.zip.
|
||||
Les données de ces regroupements cohérents de semestres sont fournis, en
|
||||
colonne, dans <i class="fa-solid fa-file" style="color: orange"></i>
|
||||
`synthese_jury_par_tag.xslx`.
|
||||
|
||||
Ces templates sont livrés avec l'installation standard de ScoDoc.
|
||||
![Regroupements cohérents de semestre](img/regroupement_coherent_semestre.png)
|
||||
|
||||
Vous pouvez également copier leur contenu dans les paramètres de ScoDoc, onglet **Paramétrage > Template LaTeX des avis** pour le modèle un_avis.tex et onglet **Paramétrage > Code LaTeX en fin d'avis** pour le modèle un_footer.tex. Vous pourrez ainsi par la suite les modifier à votre guise en respectant le format décrit ci-dessous.
|
||||
## Mode de calcul des moyennes
|
||||
|
||||
### Signataire des avis de PE
|
||||
Les moyennes de poursuites d'études (contrairement aux moyennes d'UE ou de
|
||||
regroupement cohérent d'UE) ne sont pas règlementées par l'arrêté du BUT. Leur
|
||||
mode de calcul (décrit ci-dessous) a été choisi pour **comparer les étudiants**,
|
||||
sachant la diversité des parcours, la complexité et les contraintes des
|
||||
coefficients du programme, en étant le plus cohérent possible.
|
||||
|
||||
Le nom du signataire qui sera apposé sur les avis de poursuites d'études est à saisir dans les paramètres de ScoDoc, onglet **Paramétrage > Nom du responsable des poursuites d'études**.
|
||||
> <i class="fa-solid fa-triangle-exclamation" style="color: darkred; font-size:
|
||||
> 200%"></i> Dans le cas des étudiants redoublants, seront **systématiquement**
|
||||
> pris en compte les notes de tous ses semestres y compris redoublés. L'outil ne
|
||||
> se focalise pas sur les _meilleures notes_ mais sur la _moyenne_.
|
||||
>
|
||||
> <i class="fa-solid fa-comment" style="color: darkgreen"></i> Ce choix trouve
|
||||
> un équilibre entre _pénaliser_ un étudiant en situation de redoublement par
|
||||
> rapport à un autre ayant réussi _du premier coup_ et permettre à l'étudiant
|
||||
> redoublant d'améliorer sa moyenne.
|
||||
|
||||
### Moyennes des RCS `Semestre <n>`
|
||||
|
||||
### Les sources LaTeX fournis par l'outil PE
|
||||
Rappelons que les RCS `Semestre <n>` (avec `<n>` le numéro du semestre parmi 1,
|
||||
2, 3, 4, 5, 6) désignent la moyenne (pour chaque tag) calculée en utilisant les
|
||||
notes du (ou des) semestre `<n>`. <i class="fas fa-eye" style="color: teal"></i>
|
||||
Par exemple, `Semestre 1` désigne la moyenne obtenue en partant de toutes les
|
||||
notes du S1.
|
||||
|
||||
L'outil PE renvoie dans l'archive `Jury_PE_20XX.zip` de la promotion d'élèves diplômés en 20XX, où vous trouverez :
|
||||
#### Moyenne `comp. <titre_competence>` au RCS `Semestre <n>`
|
||||
|
||||
1. un fichier par étudiant de la promotion. Ce fichier est nommé sous la forme `avis_poursuite_nom_prenom_identifiant.tex` ; il synthétise les résultats et les moyennes de l'étudiant au cours de sa scolarité DUT en suivant les *templates latex* un_avis.tex et un_footer.tex.
|
||||
La moyenne des tags (automatiques) `comp. <titre_competence>` (déduit de votre
|
||||
référentiel de compétence) pour un `Semestre <n>` est une recopie de la moyenne
|
||||
de l'UE associée à la compétence (utilisant les modules et leurs coefficients du
|
||||
programme pédagogique).
|
||||
|
||||
2. un fichier `avis_poursuite.tex` qui liste tous les avis des étudiants à compiler (inclusion des fichiers latex de chaque étudiant).
|
||||
<i class="fa-solid fa-triangle-exclamation" style="color: darkred"></i> Dans le
|
||||
cas des étudiants redoublants est fourni la moyenne des UEs des deux semestres
|
||||
qu'il a suivis (souvent l'une validée l'autre non) : par exemple, pour le
|
||||
`Semestre 1` :
|
||||
|
||||
$$moy\_ue\_au\_semestre1 = (moy\_ue\_semestre1\_non\_valide + moy\_ue\_semestre1\_valide)/2$$
|
||||
|
||||
#### Pour obtenir le document PDF
|
||||
#### Moyenne `but` au RCS `Semestre <n>`
|
||||
|
||||
1. Ouvrez l'archive zip renvoyée par ScoDoc dans votre *répertoire de travail*.
|
||||
La moyenne du tag (automatique) `but` pour un `Semestre <n>` est similaire à la
|
||||
moyenne de semestre donnée à titre indicatif par Scodoc dans les notes/jury du
|
||||
semestre. Elle utilise tous les modules, leurs coefficients par UE définis dans
|
||||
le programme pédagogique pour calculer les moyennes par UE. Puis elle fournit
|
||||
une moyenne pondérée des UEs en utilisant les crédits ECTS associés à chaque UE.
|
||||
Pour faire court :
|
||||
|
||||
2. Dans une invite de commande (cmd en Windows, terminal en linux) dont le répertoire courant est celui créé à l'ouverture de l'archive (commande `cd Jury_PE_...`), lancez la compilation des avis en exécutant la commande :
|
||||
```
|
||||
pdflatex avis.tex
|
||||
```
|
||||
Le résultat est le classeur **avis.pdf**.
|
||||
$$moy\_but\_au\_semestre = (UE1 \times ects1 + UE2 \times ects2 + ...)/(ects1 + ects2 + ...)$$
|
||||
|
||||
Cette compilation déclenche celle de `avis_poursuite.tex` qui elle-même lancera celle des avis par étudiants `avis_poursuite_nom_prenom_identifiant.tex` faisant partie de la promotion ciblée (on pourra commenter les avis des étudiants que l'on ne souhaite pas compiler en faisant débuter la ligne d'inclusion de leur avis dans `avis_poursuite.tex` d'un %).
|
||||
<i class="fa-solid fa-triangle-exclamation" style="color: darkred"></i> Dans le
|
||||
cas des étudiants redoublants est fourni la moyenne aux deux semestres qu'il a
|
||||
suivi (souvent l'un validé l'autre non) : par exemple, pour le `Semestre 1` :
|
||||
|
||||
### Le rendu PDF du template proposé
|
||||
$$moy\_but\_au\_semestre1 = (moy\_but\_au\_semestre1\_non\_valide + moy\_but\_au\_semestre1\_valide)/2$$
|
||||
|
||||
Le template proposé permet un résultat similaire à celui de la capture d'écran :
|
||||
#### Moyenne des tags personnalisés au RCS `Semestre <n>`
|
||||
|
||||
* page1 : ![avis1.png](screens/avis1.png)
|
||||
Pour les moyennes aux tags que vous avez ajoutés dans le programme de formation,
|
||||
le calcul est similaire à celle de la moyenne `but` en n'utilisant cette fois
|
||||
que les modules qui portent le tag visé.
|
||||
|
||||
* page2 : ![avis2.png](screens/avis2.png)
|
||||
<i class="fas fa-eye" style="color: teal"></i> Par exemple, si le semestre 1 a
|
||||
deux modules d'anglais taggué `anglais`, est calculé : la moyenne dans chaque UE
|
||||
avec les notes des modules d'anglais pondérés par leur coefficients
|
||||
(coefficients du programme + coefficients d'évaluation dirigeant les notes vers
|
||||
une UE ou une autre). Les moyennes dans chaque UE sont ensuite intégrée dans une
|
||||
moyenne globale en utilisant les crédits ECTS :
|
||||
|
||||
En l'état, il fournit pour chaque étudiant :
|
||||
$$moy\_anglais\_au\_semestre = (UE1\_anglais \times ects1 + UE2\_anglais \times ects2 + ...)/(ects1 + ects2 + ...)$$
|
||||
|
||||
* son nom, son prénom, son âge;
|
||||
* une frise temporelle décrivant tous les semestres DUT dans lesquels il a été inscrit (avec la nomenclature que vous avez choisi dans ScoDoc);
|
||||
* un bilan synthétique de ses moyennes aux différents semestres (avec ses classements dans son groupe et dans sa promo - voir section "les classements et les statistiques" pour l'interprétation des cohortes);
|
||||
* une zone d'annotation permettant un commentaire individualisé, l'annotation étant recherchée parmi les annotations du profil ScoDoc de l'étudiant (cf. section "L'annotation PE").
|
||||
<i class="fa-solid fa-triangle-exclamation" style="color: darkred"></i> Il vous
|
||||
est possible (via la déclaration du tag de la forme
|
||||
`nom_tag:coefficient_entier`) d'ajouter une **pondération supplémentaire** qui
|
||||
s'ajoute (par multiplication) aux coefficients du programme des modules taggués.
|
||||
|
||||
### L'annotation PE
|
||||
### Moyennes des RCS `BUT<a>`
|
||||
|
||||
Lorsqu'on édite la fiche d'un étudiant, il est possible de saisir des annotations à son sujet. Ces annotations sont aussi utilisées ici pour saisir un commentaire individualisé à apposer sur l'avis de poursuites d'études au format LaTeX de l'étudiant. Pour distinguer ce commentaire des annotations plus standards, l'annotation doit débutée par un mot-clé (ici PE:) comme le montre la capture d'écran ci-dessous :
|
||||
Les RCS `BUT<a>` (avec `<a>` le numéro de l'année parmi 1, 2, 3) regroupent deux
|
||||
semestres d'une même année `<a>` : par exemple, `BUT1` regroupent le `Semestre
|
||||
1` et le `Semestre 2`.
|
||||
|
||||
![annotation_PE.png](screens/annotation_PE.png)
|
||||
|
||||
Quelque soit le tag (`comp. <titre_compétence>`, `but` ou personnalisés), les
|
||||
moyennes _annuelles_ calculées ici s'appuient sur les moyennes des deux
|
||||
semestres regroupés (dont le mode de calcul est décrit au dessus) et fournissent
|
||||
la moyenne des deux semestres avec équipondération.
|
||||
|
||||
Cette annotation sera alors automatiquement ajoutée à l'avis LaTeX de l'étudiant (cf. `avis_poursuite_nom_prenom_identifiant.tex`).
|
||||
<i class="fas fa-eye" style="color: teal"></i> Par exemple, pour l'anglais et le
|
||||
RCS `BUT1` $moy\_anglais\_BUT1 = (moy\_anglais\_S1 + moy\_anglais\_S2)/2$
|
||||
|
||||
L'annotation peut bien entendue être remodifiée (ou ajoutée si manquante) à la main dans le fichier `avis_poursuite_nom_prenom_identifiant.tex` avant compilation en pdf.
|
||||
(où `moy_anglais_S1` désigne la moyenne d'anglais du RCS `Semestre 1` et
|
||||
`moy_anglais_S2` du RCS `Semestre 2`).
|
||||
|
||||
Plusieurs annotations ayant trait à un commentaire PE peuvent également être mémorisées dans ScoDoc (à condition de les faire toutes précéder du tag "PE:"). Dans ce cas, seule la plus récente sera ajoutée à l'avis LaTeX de l'étudiant.
|
||||
### Moyennes des RCS `Moyenne du semestre <ini> à <fin>`
|
||||
|
||||
Enfin, il est possible de modifier le tag (ici "PE:") identifiant les commentaires PE dans les annotations en allant dans l'onglet **Paramètrage > Tag désignant l'avis PE** et en y saisissant votre tag (éviter les caractères spéciaux propres au HTML, comme le ">").
|
||||
Le principe est le même que les moyennes des RCS `BUT<a>` mais en considérant
|
||||
tous les semestres allant du semestre `<ini>` au semestre `<fin>` et en
|
||||
moyennant les résultats semestre par semestre avec équipondération.
|
||||
|
||||
### Personnaliser son template
|
||||
<i class="fas fa-eye" style="color: teal"></i> Par exemple, pour l'anglais et le
|
||||
RCS `Moyenne du semestre <ini> à <fin>` :
|
||||
|
||||
#### Les patterns de base
|
||||
$$moy\_anglais = (moy\_anglais_S1 + moy\_anglais\_S2 + moy\_anglais\_S3 + moy\_anglais_S4 + moy\_anglais\_S5)/5$$
|
||||
|
||||
Les templates d'avis (un_avis et un_footer) sont des codes LaTeX classiques que vous pouvez adaptez à loisir à vos besoins.
|
||||
<i class="fa-solid fa-triangle-exclamation" style="color: darkred"></i> Si un
|
||||
semestre n'a pas de modules associé au tag visé, il n'est pas pris en compte.
|
||||
|
||||
Ils interprètent également une série de **patterns**, reconnaissables au fait qu'elles sont toutes encapsulées par deux séries de doubles * ; ces patterns sont traitées par ScoDoc pour accéder aux données de l'étudiant. Ainsi:
|
||||
<i class="fas fa-eye" style="color: teal"></i> Par exemple, pour l'anglais et le
|
||||
RCS `Moyenne du semestre <ini> à <fin>` mais pour lequel il n'y a pas de notes
|
||||
au S4 :
|
||||
|
||||
* `**nom**` sera remplacé par le nom de l'étudiant
|
||||
* `**prenom**` par le prénom
|
||||
* `**age**` par son age (à la date de création des fichiers tex)
|
||||
* `**sexe**` par son genre
|
||||
$$moy\_anglais = (moy\_anglais_S1 + moy\_anglais_S2 + moy\_anglais\_S3 + moy\_anglais\_S5)/4$$
|
||||
|
||||
Plusieurs **patterns/macros** sont proposées :
|
||||
## Classements et statistiques
|
||||
|
||||
* `**parcourstimeline**` ajoute le code LaTeX pour retracer le parcours de l'étudiant (les différents semestres dans lesquels il a été inscrit) sous la forme d'une frise temporelle (cf. capture d'écran précédente)
|
||||
* `**bilanParTag**` ajoute le code LaTeX d'un tableau, qui synthétise - pour tous les tags (sauf le tag *dut*) que vous avez affecté aux semestres de l'étudiant (cf. section Les tags) ses résultats aux différents aggrégats proposés (S1, S2, S3, S4, 1ère année, 2ème année, S1+S2+S3 et totalité du DUT)
|
||||
Les moyennes (pour chaque tag et chaque RCs) sont généralement associée à des
|
||||
**classements** et à des statistiques (note **minimum**, note **moyenne**, note
|
||||
**maximum**) qui dépendent de la **cohorte** considérée.
|
||||
|
||||
#### Les patterns personnalisées
|
||||
### Cohortes de classement
|
||||
|
||||
Tous les éléments calculés pour le jury de poursuite d'études sont également accessibles sous la forme *aggregat:cohorte:tag:critere** où :
|
||||
L'outil PE propose plusieurs cohortes pour ces classements et ces statistiques.
|
||||
|
||||
* aggregat est l'un des aggrégats parmi S1, S2, S3, S4, 1A, 2A, 3S ou 4S;
|
||||
* cohorte est soit groupe soit promo (suivant la "cohorte" que l'on souhaite prendre en compte);
|
||||
* tag est l'un des tags que vous avez déclarés dans ScoDoc (dut étant proposé par défaut);
|
||||
* critere est l'un des calculs faits pour établir le jury parmi note (la note de l'étudiant), rang (le rang dans la cohorte), min, max, moy (le minimum, le maximum ou la moyenne de la cohorte).
|
||||
<i class="fa-solid fa-triangle-exclamation" style="color: darkred;
|
||||
font-size:200%"></i> L'outil PE ne fonctionne que si :
|
||||
|
||||
Par exemple,
|
||||
* les dates des semestres de début d'année universitaires (généralement des
|
||||
semestres impairs) s'étalent sur 2 années civiles (par exemple S1 de septembre
|
||||
2021 à janvier 2022)
|
||||
* les dates des semestres de fin d'année universitaire (généralement des
|
||||
semestres pairs) sont limitées à une année civile (par exemple S2 de janvier à
|
||||
juillet 2022).
|
||||
|
||||
* **S2:groupe:mathématiques:note** sera remplacé par la note-moyenne de l'étudiant en mathématiques pour le S2;
|
||||
* **4S:promo:dut:rang** sera remplacé par le rang de l'étudiant, calculé au sein de la promo, sur sa note moyenne de DUT (moyenne calculée sur les 4 semestres S1+S2+S3+S4);
|
||||
* **1A:promo:physique:min** sera remplacé par la plus petite note de la promo obtenue en physique (moyenne de tous les modules tagués physique) sur toute la 1ère année (S1+S2).
|
||||
#### La cohorte `groupe¶`
|
||||
|
||||
> La cohorte `groupe` est l'ensemble des étudiants inscrits dans le même
|
||||
> semestre que le dernier impliqué dans la moyenne calculée.
|
||||
|
||||
<i class="fas fa-eye" style="color: teal"></i> Par exemple, pour le tag `maths`
|
||||
portant sur le RCS `Moyenne du semestre 1 à 3` c'est-à-dire sur les semestres
|
||||
S1, S2, et pour finir S3, le groupe est constitué des élèves ayant tous été
|
||||
inscrits au S3 final. Dans ce groupe, il peut y avoir des redoublants qui débuté
|
||||
un an plus tôt et ont fait un S1+S2+S1+S2 avant d'atteindre ce S3.
|
||||
|
||||
De fait, les notes prises en compte pour les moyennes pourront provenir de
|
||||
modules ne s'étant pas tenus aux même universitaires.
|
||||
|
||||
#### La cohorte `promo`
|
||||
|
||||
> La cohorte `promo 20XX` est l'ensemble des étudiants susceptibles de valider
|
||||
> leur diplôme BUT à l'année `20XX` indépendamment de leur parcours (en
|
||||
> supposant qu'ils ne redoublent plus).
|
||||
|
||||
<i class="fas fa-eye" style="color: teal"></i> Par exemple, si votre département
|
||||
propose un _parcours A_ et un _parcours B_, la promo 2024 inclut les étudiants
|
||||
qui valideront leur S6 en juillet 2024 (voire en décembre 2024 en cas de
|
||||
semestres décalés).
|
||||
|
||||
<i class="fas fa-eye" style="color: teal"></i> Autre exemple, la promo 2025 :
|
||||
parmi les étudiants de la promo 2025, on retrouve les étudiants "standards"
|
||||
étant entrés à l'IUT en septembre 2022 avec un parcours sans redoublement. On
|
||||
retrouve également les étudiants entrés à l'IUT en septembre 2021 et ayant
|
||||
redoublé 2 semestres (de BUT1 ou de BUT2). Les étudiants ayant démissionnés ou
|
||||
s'étant réorientés (aka ne s'étant pas réinscrit dans un semestre BUT là où il
|
||||
aurait "du" le faire) sont exclus de la promo. (cf. tableur <i class="fa-solid
|
||||
fa-file" style="color: orange"></i> `Jury_PE_2024.zip >
|
||||
details/etudiants_20XX.xlsx`)
|
||||
|
||||
#### La cohorte `parcours` (à venir)
|
||||
|
||||
> La cohorte `parcours 20XX` est l'ensemble des étudiants susceptibles de
|
||||
> valider leur diplôme BUT à l'année `20XX` et ayant suivi le même parcours (du
|
||||
> référentiel de compétences).
|
||||
|
||||
### Classements par cohorte
|
||||
|
||||
<i class="fa-solid fa-triangle-exclamation" style="color: darkred;
|
||||
font-size:200%"></i> Dans une même cohorte et pour certains tags (notamment ceux
|
||||
des `comp. <titre_compétence>`), les étudiants peuvent avoir suivi des modules
|
||||
différents (par exemple parce qu'ils sont prévu dans le parcours A mais pas dans
|
||||
le parcours B). Les classements dans la cohorte sont donc systématiquement
|
||||
ramenés au nombre d'étudiants inscrits dans les modules raccrochés au tag visé.
|
||||
|
||||
### Statistiques par cohorte
|
||||
|
||||
Pour chaque cohorte et chaque tag (considérant les inscrits aux modules
|
||||
rattachés aux tags) des statistiques sont fournies :
|
||||
|
||||
* `min` la plus petite note (moyenne du tag) obtenu par les étudiants de la cohorte
|
||||
* `max` la plus grande note (moyenne du tag) obtenu par les étudiants de la cohorte
|
||||
* `moy` la moyenne des notes (au tag) de la cohorte
|
||||
|
307
docs/BUT.md
307
docs/BUT.md
@ -1,14 +1,16 @@
|
||||
|
||||
# Le Bachelor Universitaire de Technologie (BUT)
|
||||
|
||||
Formation en trois ans dispensées par les IUT français, introduite en 2021, et
|
||||
basée sur une forme d'approche par compétences nécessitant un système
|
||||
d'évaluation spécifique.
|
||||
Le BUT est une formation en trois ans dispensées par les IUT français,
|
||||
introduite en 2021, et basée sur une forme d'approche par compétences
|
||||
nécessitant un système d'évaluation spécifique.
|
||||
|
||||
Cette page décrit les principaux éléments du BUT utiles à comprendre pour le
|
||||
gérer avec ScoDoc. Pour les curieux, la page
|
||||
[modélisation des parcours BUT](ModelisationParcoursBUT.md)
|
||||
donne quelques détails sur la façon dont ScoDoc organise les objets du BUT.
|
||||
gérer avec ScoDoc. Vous trouverez ensuite un exemple de mise en place des
|
||||
semestres d'un BUT ici:
|
||||
[Modélisation BUT: exemple de la spécialité Informatique](BUTExempleInfo.md).
|
||||
Pour les curieux et les développeurs, la page
|
||||
[modélisation des parcours BUT](ModelisationParcoursBUT.md) donne quelques
|
||||
détails sur la façon dont ScoDoc organise les objets du BUT.
|
||||
|
||||
De nombreux aspects sont aussi décrits dans les
|
||||
<a
|
||||
@ -18,37 +20,41 @@ style="margin-top:0px; margin-bottom:0px; border-width:0px;"/></a>
|
||||
|
||||
## UE, modules, évaluations
|
||||
|
||||
- UE : Unité d'Enseignement, associée à des crédits (ECTS) et validée (ou non)
|
||||
en jury. Une UE est rattachée à une *formation*.
|
||||
|
||||
- Module: dans ScoDoc, un module désigne une dispositif pédagogique, évalué.
|
||||
Dans les formations BUT, le module prend la forme d'une *ressource* ou d'une
|
||||
SAE (*situation d'apprentissage et d'évaluation*). Un module est rattaché à
|
||||
une (seule) UE.
|
||||
- UE : Unité d'Enseignement, associée à des crédits (ECTS) et validée (ou non)
|
||||
en jury. Une UE est rattachée à une *formation*.
|
||||
|
||||
Dans le BUT, un module est aussi associé à une ou ou plusieurs UE, cette
|
||||
association étant affecté de *coefficients* (une valeur par UE associée).
|
||||
|
||||
- Évaluation: dispositif produisant une note pour les étudiants inscrits à un
|
||||
module. L'évaluation est associée à des coefficients.
|
||||
- Module: dans ScoDoc, un module désigne une dispositif pédagogique, évalué.
|
||||
Dans les formations BUT, le module prend la forme d'une **ressource** ou d'une
|
||||
**SAE** (*situation d'apprentissage et d'évaluation*). Un module est rattaché à
|
||||
une (seule) UE.
|
||||
|
||||
Dans le BUT, un module est aussi associé à une ou ou plusieurs UE, cette
|
||||
association étant affectée de *coefficients* (une valeur par UE associée).
|
||||
|
||||
- Évaluation: dispositif produisant une note pour les étudiants inscrits à un
|
||||
module. L'évaluation est associée à des coefficients.
|
||||
|
||||
## Structure des formations par compétences de type BUT
|
||||
|
||||
L'architecture d'une formation BUT est définie par les éléments suivants:
|
||||
L'architecture d'une formation BUT est définie par un *référentiel de
|
||||
compétence* définissant notamment les éléments suivants:
|
||||
|
||||
- Compétence
|
||||
- Niveau
|
||||
- **Compétence**
|
||||
|
||||
- Niveau
|
||||
- Composantes essentielles ("En respectant les règles métiers...")
|
||||
- Situations professionnelles ("Surveillance de la qualité de la
|
||||
production...")
|
||||
production...")
|
||||
|
||||
- Niveaux de compétence: associés à une année. Attention, le niveau 1 commence
|
||||
parfois en deuxième année.
|
||||
- Numéro (1, 2, 3)
|
||||
- Titre
|
||||
- Apprentissages critiques (AC): "Identifier les dysfonctionnements du réseau local..."
|
||||
- **Niveaux de compétence**: la compétence est divisée en niveaux, associés à
|
||||
une année de la formation. Le premier niveau 1 commence souvent en première
|
||||
année (BUT1), mais parfois en deuxième année (BUT2). Le niveau est défini par
|
||||
|
||||
Chaque niveau se décompose en deux UE (aka "regroupement cohérent d'UE"), en
|
||||
- Numéro (1, 2, 3)
|
||||
- Titre
|
||||
- Apprentissages critiques (AC): "Identifier les dysfonctionnements du réseau local..."
|
||||
|
||||
Chaque niveau de compétence sera associé à deux UE (aka "regroupement cohérent d'UEs"), en
|
||||
semestres impair et pair d'une année scolaire.
|
||||
|
||||
La figure ci-dessous indique la correspondance entre compétences (découpées en
|
||||
@ -59,18 +65,21 @@ niveaux) et UEs.
|
||||
## Calcul des notes
|
||||
|
||||
Les rôles des SAÉ et ressources étant symétriques, on appellera dans la suite (et
|
||||
dans ScoDoc) *module* un objet de type SAÉ _ou_ ressource.
|
||||
dans ScoDoc) *module* un objet de type SAÉ *ou* ressource.
|
||||
|
||||
Dans la suite, on considère les poids et coefficients toujours positifs ou
|
||||
nuls (pas de coefficients négatifs).
|
||||
|
||||
### Coefficients des SAÉ et ressources
|
||||
Les coefficients des modules (ressources et SAÉ) sont fixés par le PN (*adapté
|
||||
localement*).
|
||||
|
||||
Les coefficients des modules (ressources et SAÉ) sont fixés par le programme de
|
||||
formation (basé sur des préconisations nationales *adaptées localement*). Le
|
||||
programme spécifie la liste et les coefficients des modules, il est voté en
|
||||
CFVU et ne doit donc pas être modifié en cours d'année.
|
||||
|
||||
Traditionnellement, chaque module $m$ est noté par une note (moyenne de ses
|
||||
évaluations) représentée par le nombre $\mu_m$. Si $c_{u,m}$ désigne le coefficient du
|
||||
module $m$ dans l'UE $u$, la moyenne d'UE de l'étudiant est
|
||||
évaluations) représentée par le nombre $\mu_m$. Si $c_{u,m}$ désigne le
|
||||
coefficient du module $m$ dans l'UE $u$, la moyenne d'UE de l'étudiant est
|
||||
|
||||
$$\mu_u = \frac{1}{\sum_m c_{u,m}} \, \sum_{m \in u} c_{u,m} \, \mu_m$$
|
||||
|
||||
@ -91,33 +100,38 @@ Un autre exemple, cette fois avec des coefficients différents et un nombre plus
|
||||
réduit d'apprentissages critiques:
|
||||
![but-ref-comp-ex-commente](fig/but-ref-comp-ex-commente.png)
|
||||
|
||||
### Note d'un module
|
||||
### Poids des évaluations
|
||||
|
||||
La note (moyenne) d'un module (SAÉ ou ressource) se calcule à partir de ses
|
||||
évaluations. Chaque évaluation est pondérée, par un poids $p$ est fixé par
|
||||
l'enseignant. Ce poids joue le même rôle que le coefficient d'une évaluation
|
||||
classique, mais peut se décliner en plusieurs valeurs, une par UE associée au
|
||||
module.
|
||||
module.
|
||||
|
||||
!!! warning "Attention"
|
||||
En BUT, la moyenne d'un module n'est pas un nombre unique: il y a une
|
||||
moyenne différente par UE liée à ce module.
|
||||
|
||||
|
||||
Soit $n_e$ la note à l'évaluation $e$ du module $m$, et $p_{e, u}$ son poids
|
||||
vers l'UE $u$. La somme des notes d'un module pour l'UE $u$ est:
|
||||
vers l'UE $u$. La somme des notes d'un module pour l'UE $u$ est:
|
||||
|
||||
$$n_u = \sum_e p_{e,u} \, n_e$$
|
||||
|
||||
Chaque UE indiquée par le référentiel de formation doit être évaluée: si le
|
||||
coefficient du module vers l'UE $u$ est non nul, la somme des poids vers
|
||||
coefficient du module vers l'UE $u$ est non nul, la somme des poids vers
|
||||
une UE $u$ *doit* être non nulle; si ce n'est pas le cas, le module sera déclaré
|
||||
*non conforme* et le jury ne pourra pas être tenu.
|
||||
|
||||
*non conforme* et le jury ne pourra pas être tenu.
|
||||
|
||||
### Moyenne de module (SAÉ ou ressource)
|
||||
|
||||
La moyenne d'un étudiant dans un module est un vecteur, car on a une note moyenne par UE:
|
||||
|
||||
$$\mu_{m, u} = \frac{\sum_e p_{e,u} \, n_e}{\sum_{e} \, p_{u,e}}$$
|
||||
|
||||
Toutefois, une moyenne *scalaire* (un nombre entre 0 et 20) est calculée à
|
||||
titre indicatif (et sera éventuellement utilisée dans certaines fonctions de
|
||||
ScoDoc conçues avant le BUT):
|
||||
titre indicatif (mais n'est pas présentée aux étudiants dans les bulletins pour
|
||||
ne pas les induire en erreur):
|
||||
|
||||
$$\mu_m = \frac{\sum_e (\sum_u p_{e,u}) \, n_e}{\sum_{u,e} \, p_{u,e}}$$
|
||||
|
||||
@ -131,10 +145,30 @@ L'exemple suivant illustre ce mode de calcul:
|
||||
|
||||
<img src="/fig/but-exemple-calcul-notes.png" width="70%">
|
||||
|
||||
Par ailleurs, il est (parfois, peut-être) utile de calculer des moyennes par
|
||||
pôles au sein de l'UE: pôle SAÉ, pôle ressource.
|
||||
Dans ScoDoc, on va éditer les coefficients des modules sur cette page
|
||||
<img src="/screens/but-info-edit-coefs-S4.png" width="40%">
|
||||
|
||||
(voir [l'exemple complet du paramétrage d'un BUT](BUTExempleInfo.md)).
|
||||
|
||||
#### Note: calcul des coefficients lorsqu'on sépare ressources et SAÉs
|
||||
|
||||
Certaines formations souhaitent fixer explicitement les parts respectives des ressources et SAÉs au sein d'une UE.
|
||||
Par exemple, 60% pour les ressources et 40% pour les SAÉs.
|
||||
|
||||
Supposons que l'on ait deux ressources de coefficients $r_1=2$ et $r_2=3$, et
|
||||
deux SAÉs de coefficients $s_1=4$ et $s_2=5$. Dans cet exemple, la somme des
|
||||
coefficients est de 14, et la part des ressources est de $5 / 14 = 35,7$%. Pour
|
||||
obtenir l'équilibre souhaité, il faut diviser les coefficients des ressources
|
||||
par leur somme et les multiplier 60. Ici la somem des coefficients des ressources est de 5, et celle des SAÉs est de 9.
|
||||
On aura donc dans cet exemple:
|
||||
|
||||
- $r_1 = 2 / 5 \times 60 = 24$
|
||||
- $r_2 = 3 / 5 \times 60 = 36$
|
||||
- $s_1 = 4 / 9 \times 40 = 17,8$
|
||||
- $s_2 = 5 / 9 \times 40 = 22,2$
|
||||
|
||||
### Validation d'une UE
|
||||
|
||||
La validation ou non d'une UE dépend uniquement de la moyenne générale (et des
|
||||
conditions habituelles d'assiduité et de défaillance spécifiées dans les
|
||||
règlements des établissements):
|
||||
@ -146,31 +180,41 @@ peuvent entrainer la validation d'UE a posteriori.
|
||||
|
||||
### Capitalisation
|
||||
|
||||
Les UE sont capitalisables, c'est à dire qu'un étudiant conserve les UEs
|
||||
obtenues (avec moyenne > 10/20) s'il arrête temporairement ses études ou redouble un semestre.
|
||||
Dans le BUT comme dans toutes les formations LMD, les UEs sont capitalisables,
|
||||
c'est à dire qu'un étudiant conserve les UEs obtenues (avec moyenne > 10/20)
|
||||
s'il arrête temporairement ses études ou redouble un semestre.
|
||||
|
||||
En cas de redoublement, l'étudiant qui choisi de répéter une UE capitalisée conserve le
|
||||
résultat antérieur sauf s'il obtient une meilleure moyenne.
|
||||
En cas de redoublement, l'étudiant qui choisi de répéter une UE capitalisée
|
||||
conserve le résultat antérieur sauf s'il obtient une meilleure moyenne.
|
||||
|
||||
### Moyenne générale
|
||||
### Moyenne générale indicative
|
||||
|
||||
La validation du BUT ne considère pas de "moyenne générale": chaque
|
||||
regroupement d'UE est considéré indépendamment (aucunes compensations entre UE
|
||||
relevant de compétences différentes).
|
||||
La validation du BUT ne considère pas de "moyenne générale": chaque regroupement
|
||||
d'UE est considéré indépendamment (aucune compensations entre UEs relevant de
|
||||
compétences différentes).
|
||||
|
||||
Cependant, ScoDoc calculera une moyenne générale indicative, utile pour
|
||||
Cependant, ScoDoc peut calculer une moyenne générale indicative, utile pour
|
||||
certaines opérations (tri de tableaux, création de groupe de niveaux semblables,
|
||||
avis de poursuite d'études, etc.).
|
||||
|
||||
Cette moyenne sera calculée en utilisant les ECTS de chaque UE du semestre
|
||||
Cette moyenne indicative est calculée en utilisant les ECTS de chaque UE du semestre
|
||||
considéré:
|
||||
|
||||
$$ g = \frac{1}{\sum_{u \in \cal S} \mbox{ects}_u} \sum_{u \in \cal S} \mbox{ects}_u \, \mu_u $$
|
||||
|
||||
Attention, les UEs sans notes sont ici considérées comme ayant une moyenne
|
||||
nulle. En début d'année, la moyenne générale indicative sera donc souvent très basse.
|
||||
nulle. En début d'année, la moyenne générale indicative sera donc souvent très
|
||||
basse.
|
||||
|
||||
!!! note "Note"
|
||||
Il est possible, dans chaque semestre, de désactiver le calcul de la moyenne
|
||||
générale indicative si on ne souhaite pas en tenir compte.
|
||||
<img src="/screens/but-option-moy-indicative.png" width="50%">
|
||||
|
||||
|
||||
|
||||
### Passage d'une année à l'autre
|
||||
|
||||
Les conditions de passages vers l'année suivante sont:
|
||||
|
||||
1. Moyenne supérieure ou égale à 10/20 obtenue à plus de de la moitié des
|
||||
@ -179,20 +223,23 @@ Les conditions de passages vers l'année suivante sont:
|
||||
2. Aucun regroupement cohérent d’UE < 8.
|
||||
3. Cas particulier du passage en BUT 3: nécessité d’avoir validé toutes les UE
|
||||
du BUT 1.
|
||||
|
||||
|
||||
Note: La validation des deux UE du niveau d’une compétence emporte la validation de
|
||||
l’ensemble des UE du niveau inférieur de cette même compétence.
|
||||
l’ensemble des UEs du niveau inférieur de cette même compétence.
|
||||
|
||||
Voir la [page dédiée aux jurys BUT](BUTJurys.md).
|
||||
|
||||
### Redoublements
|
||||
|
||||
La poursuite d'études dans un semestre pair d’une même année est *de droit* pour
|
||||
tout étudiant. La poursuite d’études dans un semestre impair est possible si et
|
||||
seulement si l’étudiant a obtenu :
|
||||
|
||||
- la moyenne à plus de la moitié des regroupements cohérents d’UE ;
|
||||
- et une moyenne égale ou supérieure à 8 sur 20 à chaque regroupement cohérent
|
||||
- la moyenne à plus de la moitié des regroupements cohérents d’UE ;
|
||||
- et une moyenne égale ou supérieure à 8 sur 20 à chaque regroupement cohérent
|
||||
d’UE. La poursuite d'études dans le semestre 5 nécessite de plus la validation
|
||||
de toutes les UE des semestres 1 et 2 dans les conditions de validation des
|
||||
points 4.3 et 4.4, ou par décision de jury.
|
||||
points 4.3 et 4.4, ou par décision de jury.
|
||||
|
||||
Durant la totalité du cursus conduisant au bachelor universitaire de
|
||||
technologie, l'étudiant peut être autorisé à redoubler une seule fois chaque
|
||||
@ -202,12 +249,11 @@ appréciée par ses soins. Tout refus d'autorisation de redoubler est pris aprè
|
||||
avoir entendu l'étudiant à sa demande. Il doit être motivé et assorti de
|
||||
conseils d'orientation.
|
||||
|
||||
|
||||
### Obtention du diplôme
|
||||
|
||||
Le diplôme de BUT est obtenu lorsque toutes les compétences du parcours suivi
|
||||
sont validées.
|
||||
|
||||
|
||||
### Modules "bonus" (sport, culture, LV2)
|
||||
|
||||
Les modules hors formation comme le sport ou les langues vivantes supplémentaires
|
||||
@ -217,33 +263,39 @@ bonus pourra donc être appliqué au niveau des moyennes UE: soit sur toutes
|
||||
(bonus fixe ajouté à chaque UE), soit sur un sous-ensemble des UE du semestre.
|
||||
|
||||
Les règles précises du calcul de ce bonus sont malheureusement variables d'un
|
||||
établissement à l'autre: ScoDoc 7 proposait plus d'une douzaine de variantes. La
|
||||
situation sera identique avec le BUT et ScoDoc 9, et la mise en place d'une
|
||||
fonction spécifique dans ScoDoc demandera un paramétrage particulier.
|
||||
établissement à l'autre: ScoDoc 9 propose actuellement (mars 2024)
|
||||
quarante-trois (43, vous avez bien lu) modes de calculs différents. La mise en
|
||||
place d'une fonction spécifique dans ScoDoc demande un paramétrage particulier:
|
||||
voir [la page sur les bonus et malus](BonusMalus.md).
|
||||
|
||||
# Éditer ou importer une formation
|
||||
## Éditer ou importer une formation et référentiels
|
||||
|
||||
ScoDoc permet d'importer des programmes de formations créés par d'autres
|
||||
applications, comme Orébut, puis de les modifier pour introduire une *adaptation
|
||||
locale*.
|
||||
ScoDoc permet de créer et éditer un programme de formation, et d'exporter ou
|
||||
importer des formations dans un format d'échange XML.
|
||||
|
||||
TODO: voir si on offre la possibilité de voir/gérer le delta entre le PN et le local.
|
||||
Les référentiels de compétences des BUTs ont été copiés depuis Orébut (application
|
||||
officielle de l'ADIUT).
|
||||
|
||||
# Modules et évaluations
|
||||
## Modules et évaluations
|
||||
|
||||
## Créer une évaluation
|
||||
Pour des informations générales, voir la page sur [les évaluations](Evaluation.md).
|
||||
|
||||
Pour fixer les poids des évaluations du module, on peut employer plusieurs méthodes:
|
||||
### Créer une évaluation
|
||||
|
||||
- un nombre (poids de l'évaluation dans le module, sans préciser si cette
|
||||
évaluation affecte plus un UE qu'une autre);
|
||||
Pour fixer les poids des évaluations du module, on va fixer un coefficient et
|
||||
éventuellement moduler les poids vers les UEs:
|
||||
|
||||
- cocher des apprentissages critiques (on rappelle que les AC sont associés à des niveaux de
|
||||
compétences, donc à 2 UE consécutives);
|
||||
- un nombre (poids de l'évaluation dans le module, sans préciser si cette
|
||||
évaluation affecte plus un UE qu'une autre);
|
||||
|
||||
- indiquer un poids par UE.
|
||||
- indiquer un poids par UE.
|
||||
|
||||
Par ailleurs, on peut cocher des apprentissages critiques (AC), associés à des
|
||||
niveaux de compétences, afin de vérifier que l'ensemble des évaluations couvre
|
||||
bien les critères préconisés dans le référentiel de compétences.
|
||||
|
||||
#### Coefficient et poids d'une évaluation
|
||||
|
||||
Afin de faciliter la tâche des enseignants, ScoDoc sépare le coefficient d'une
|
||||
évaluation (qui donne sa place dans le module) et les poids (qui ajustent son
|
||||
impact dans chaque UE). On introduit donc un coefficient $w_e$, et les poids
|
||||
@ -255,21 +307,24 @@ $$p_{e, u} = w_e \, \frac{b_{e,u}}{\sum_u b_{e,u}}$$
|
||||
|
||||
<img src="/fig/but-dialog-eval-create.png" width="50%">
|
||||
|
||||
- L'enseignant _doit_ renseigner le coefficient de l'évaluation.
|
||||
- Par défaut, les poids valent 1 (la contribution de l'évaluation vers les
|
||||
différentes UE respecte alors le PN).
|
||||
- Si on décoche un AC, les poids sont mis à jour, au prorata du nombre d'AC
|
||||
dans chaque UE (compétence).
|
||||
|
||||
- L'enseignant *doit* renseigner le coefficient de l'évaluation.
|
||||
- Par défaut, les poids valent 1 (la contribution de l'évaluation vers les
|
||||
différentes UE respecte alors le PN).
|
||||
- Si on décoche un AC, les poids sont mis à jour, au prorata du nombre d'AC
|
||||
dans chaque UE (compétence).
|
||||
|
||||
Voir aussi la page sur [les évaluations](Evaluation.md).
|
||||
|
||||
## Tableau de bord module
|
||||
|
||||
Fonctions de base, en plus de celles déjà présentes en ScoDoc 7:
|
||||
Fonctions spécifiques au BUT:
|
||||
|
||||
- Vérification de la conformité (tous les AC cochés dans le PN sont évalués)
|
||||
- Poids de chaque évaluation dans chaque UE et conformité au programme de la formation
|
||||
|
||||
- Poids de chaque évaluation dans chaque UE et conformité au programme de la formation
|
||||
### Travaux en cours
|
||||
|
||||
- Vérification de la conformité (tous les AC cochés dans le PN sont évalués)
|
||||
(pas encore disponible en 9.6.x).
|
||||
|
||||
En bas du tableau de bord du module on aura un tableau récapitulatif:
|
||||
|
||||
@ -281,55 +336,77 @@ des poids ou oubli d'une évaluation):
|
||||
<img src="/fig/but-tableau-evals-module-ko.png" width="50%">
|
||||
|
||||
|
||||
## Bulletins de notes
|
||||
|
||||
# Bulletins de notes
|
||||
La quantité d'information à présenter rend la conception des bulletins (relevés) de notes délicate.
|
||||
|
||||
La quantité d'information à présenter rend la conception des bulletins de notes difficile.
|
||||
Pour le BUT, on propose:
|
||||
- un bulletin semestriel avec notes des ressources, des SAÉs et résultats aux
|
||||
UEs. Ce bulletin peut être plus ou moins détaillé, versions "long",
|
||||
"intermédiaire" ou "court".
|
||||
- un bulletin résumé, en une page, donnant les principaux résultats du semestre
|
||||
et l'avancement dans l'acquisition des compétences.
|
||||
|
||||
## Modèle "Lillois"
|
||||
Proposition de l'IUT de Lille:
|
||||
Ces documents sont disponibles aux formats web (html), PDF et json (API).
|
||||
|
||||
- en ligne, les ressources, puis les SAÉ;
|
||||
- en colonnes, les UE;
|
||||
- dans chaque case, le coefficient et la note obtenue;
|
||||
- on peut ajouter les évaluations (lignes);
|
||||
- on pourrait ajouter les infos habituelles en colonnes: min/max/moy/rangs/...
|
||||
Voir quelques propositions, sources d'inspiration pour les formats proposés par
|
||||
ScoDoc 9 [sur cette page](BUTBulletins.md)
|
||||
|
||||
Avantage: toutes les informations importantes sont présentées.
|
||||
## Tenue des Jury BUT
|
||||
|
||||
Inconvénients (?): beaucoup de cases vides, peu synthétique, pas évident à
|
||||
exploiter pour un non spécialiste du BUT (poursuites d'études, employeurs).
|
||||
La tenue des jury BUT dans ScoDoc est en fait plus simple que celle des anciens
|
||||
DUTs, avec moins de décisions ad-hoc (compensations plus simples, moins de cas
|
||||
de mise en attente). Comme pour les formations LMD, il s'agit avant tout de
|
||||
constater ou valider manuellement les Unités d'Enseignements (UEs) associées à
|
||||
des ECTS.
|
||||
|
||||
<img src="/fig/but-bul-lille.png" width="50%">
|
||||
Avant de tenir un jury de BUT il est absolument indispensable que la formation
|
||||
et les semestre soient bien paramétrés. Voir [l'exemple complet du paramétrage
|
||||
d'un BUT](BUTExempleInfo.md).
|
||||
|
||||
## Modèle "Bordelais"
|
||||
Cette proposition a été reçue sous différentes formes de plusieurs collègues.
|
||||
L'idée est de présenter le bulletin en deux parties: d'abord les résultats de
|
||||
chaque ressource et SAE, puis les résultats de chaque UE.
|
||||
On va enregistrer:
|
||||
|
||||
Un exemple préliminaire:
|
||||
- Validations des UEs, comme pour toutes les formations LMD.
|
||||
- Validation des années: spécifique BUT (BUT1, BUT2 ou BUT3)
|
||||
- Validation des niveaux de compétences: ces derniers sont évalués grâce à la
|
||||
constitution du couple de deux UEs associées au même niveau de compétence.
|
||||
**Attention: un niveau ne peut être validé qu'une seule fois.** Cette
|
||||
validation peut changer d'état, par exemple si un étudiant redouble.
|
||||
|
||||
<img src="/fig/but-bul-bdx.png" width="50%">
|
||||
Exemple: un étudiant commence en 2021-2022, puis redouble son BUT1 en 2022-2023.
|
||||
Sa spécialité compte seulement deux UEs en BUT1, UE11 et UE21 en S1, puis UE12
|
||||
et UE22 en S2:
|
||||
|
||||
| S1 | S2 |
|
||||
| ---- | ---- |
|
||||
| UE11 | UE12 |
|
||||
| UE21 | UE22 |
|
||||
|
||||
Il ne valide pas ses UEs en BUT1 (tout `AJ`), ses RCUE1 et RCUE2 sont `AJ`.
|
||||
En redoublant, il acquiert de nouveaux codes d'UE (disons `ADM`), et change ses
|
||||
codes d'RCUE.
|
||||
|
||||
# Tenue des Jury BUT
|
||||
De même, les validations d'année BUT sont uniques: en cas de redoublement, on
|
||||
met à jour sa validation de BUT1, qui peut passer (si tout va bien) de
|
||||
`RED`(redoublement) à `ADM` (validée).
|
||||
|
||||
La tenue des jury BUT dans ScoDoc est très similaire à celle du DUT, avec moins
|
||||
de décisions ad-hoc (compensations plus simples, moins de cas de mise en attente).
|
||||
A la fin, les validations enregistrées pour cet étudiant sont:
|
||||
|
||||
- Validation des semestres (bien que cela ait peu de conséquences concrètes
|
||||
pour les semestres impairs.
|
||||
|
||||
- Règles de compensation au sein de chaque niveau, pour validation de l'année.
|
||||
- UE11/2021: AJ
|
||||
- UE12/2021: AJ
|
||||
- UE11/2022: ADM
|
||||
- UE12/2022: ADM
|
||||
- RCUE1: ADM
|
||||
- Années BUT1 : ADM
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Modélisation BUT: exemple de la spécialité Informatique](BUTExempleInfo.md)
|
||||
- [Les codes de jury en BUT](BUTCodesJury.md)
|
||||
- [Guide utilisateur](GuideUtilisateur.md)
|
||||
- [Guide du responsable de formation](GuideAdminFormation.md)
|
||||
- [Tutoriels vidéo](https://www.youtube.com/channel/UCb0JYCBRi0CsE4XFp4ByhXg)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Développeurs: Implémentation des parcours du BUT](ModelisationParcoursBUT.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
||||
|
||||
|
35
docs/BUTBulletins.md
Normal file
35
docs/BUTBulletins.md
Normal file
@ -0,0 +1,35 @@
|
||||
# Bulletins de notes pour le BUT
|
||||
|
||||
|
||||
|
||||
## Anciennes propositions
|
||||
|
||||
Exemples de propositions de formats de bulletins discutées au moment de la
|
||||
création de ScoDoc 9.
|
||||
|
||||
### Modèle "Lillois"
|
||||
|
||||
Proposition de l'IUT de Lille:
|
||||
|
||||
- en ligne, les ressources, puis les SAÉ;
|
||||
- en colonnes, les UE;
|
||||
- dans chaque case, le coefficient et la note obtenue;
|
||||
- on peut ajouter les évaluations (lignes);
|
||||
- on pourrait ajouter les infos habituelles en colonnes: min/max/moy/rangs/...
|
||||
|
||||
Avantage: toutes les informations importantes sont présentées.
|
||||
|
||||
Inconvénients (?): beaucoup de cases vides, peu synthétique, pas évident à
|
||||
exploiter pour un non spécialiste du BUT (poursuites d'études, employeurs).
|
||||
|
||||
<img src="/fig/but-bul-lille.png" width="50%">
|
||||
|
||||
### Modèle "Bordelais"
|
||||
|
||||
Cette proposition a été reçue sous différentes formes de plusieurs collègues.
|
||||
L'idée est de présenter le bulletin en deux parties: d'abord les résultats de
|
||||
chaque ressource et SAE, puis les résultats de chaque UE.
|
||||
|
||||
Un exemple préliminaire:
|
||||
|
||||
<img src="/fig/but-bul-bdx.png" width="50%">
|
137
docs/BUTCapitalisationUE.md
Normal file
137
docs/BUTCapitalisationUE.md
Normal file
@ -0,0 +1,137 @@
|
||||
# Capitalisation des Unités d'Enseignement en BUT
|
||||
|
||||
## Principe général
|
||||
|
||||
Une formation est constituée d'une succession de semestres (dans ScoDoc un
|
||||
"semestre" peut avoir une durée quelconque, mais pour le BUT ce sont de vrais
|
||||
semestres), eux-mêmes divisés en Unités d'Enseignement (UEs).
|
||||
|
||||
Les UEs sont constituées de modules (ressources et SAÉs en BUT). Les UEs sont
|
||||
*capitalisables* et associées à des crédits académiques (ECTS). Lorsqu'un
|
||||
étudiant interrompt ses études ou redouble, il conserve ses UEs capitalisées.
|
||||
|
||||
ScoDoc prend en compte cela par différents mécanismes:
|
||||
|
||||
- lorsqu'un étudiant redouble dans la même formation, ses UEs capitalisées sont
|
||||
automatiquement prises en compte. L'étudiant peut choisir de refaire une UE
|
||||
capitalisée. Dans ce cas, ScoDoc prendra automatiquement en compte celle ayant
|
||||
la meilleure note. Il peut aussi choisir de ne pas refaire cette UE (voir plus
|
||||
loin).
|
||||
- Il arrive que les programmes évoluent d'une année sur l'autre (changement de
|
||||
version, réformes). ScoDOc permet d'indiquer si des UEs de différents
|
||||
programmes sont équivalentes et peuvent se capitaliser.
|
||||
- Enfin, ScoDoc permet d'enregistrer la validation d'une UE obtenue par ailleurs
|
||||
(par exemple dans un autre établissement suite à un transfert, à l'étranger,
|
||||
etc.).
|
||||
|
||||
## Formations ScoDoc et UEs
|
||||
|
||||
Chaque UE possède un code interne ScoDoc que l'on peut modifier via la page
|
||||
d'édition des programmes:
|
||||
|
||||
<img src="/screens/ue-edit-code.png" width="70%"
|
||||
alt="Modification du code interne d'une UE">
|
||||
|
||||
On peut utiliser un code quelconque, y compris celui donné dans un autre
|
||||
logiciel comme Apogée. En bas de cette même page, ScoDoc affiche la liste des
|
||||
UEs ayant le même code, afin de vérifier facilement la compatibilité:
|
||||
|
||||
<img src="/screens/ue-edit-code-equiv.png" width="70%"
|
||||
alt="UEs partageant le même code">
|
||||
|
||||
Ne pas confondre ce code d'UE interne avec le code Apogée, qui n'est utilisé que pour
|
||||
les exports de résultats.
|
||||
|
||||
## La moyenne d'UE capitalisée
|
||||
|
||||
La note (moyenne) de l'UE est enregistrée ("photo instantanée") au moment de la
|
||||
saisie de la décision de jury la concernant (si cette décision est
|
||||
"capitalisante"), afin d'être utilisée dans la suite de la scolarité de
|
||||
l'étudiant (redoublement, ou construction de RCUE inter-annuels).
|
||||
|
||||
Attention, il faut veiller à ne jamais modifier les notes après décision du
|
||||
jury, c'est une évidence qui n'est pas toujours respectée. En effet, outre le
|
||||
fait que le jury serait alors sans valeur, si la moyenne d'une UE capitalisée
|
||||
change après son enregistrement, on observera des discordances entre les valeurs
|
||||
capitalisées (PV de jury, etc) et celles calculées et affichées sur les relevés
|
||||
de notes.
|
||||
|
||||
ScoDoc essaye de décourager cela:
|
||||
|
||||
- verrouillage de semestres conseillé immédiatement après le jury;
|
||||
- nombreux avertissements lors des tentatives de saisies de notes s'il existe
|
||||
une décision de jury.
|
||||
|
||||
Au besoin, il est toujours possible, avec les droits adéquats, après
|
||||
déverrouillage du semestre et avec en principe l'autorisation du président du
|
||||
jury (...) de resaisir la décision, afin d'enregistrer la nouvelle moyenne.
|
||||
|
||||
## Exemple BUT avec UE capitalisée
|
||||
|
||||
Soit une formation BUT, ici R&T, avec 3 UE. Certaines ressources (comme R101) sont communes à
|
||||
deux ou trois UEs.
|
||||
|
||||
<img src="/fig/but-uescap-coefs.png" width="25%">
|
||||
|
||||
L'étudiant "Mael REDOUBLE" a redoublé sa première année, mais avait capitalisé
|
||||
l'UE 1 de S1. Son parcours s'affiche ainsi:
|
||||
|
||||
<img src="/fig/but-uescap-fiche.png" width="60%">
|
||||
|
||||
Son bulletin montre l'UE 1 actuelle (moyenne 8,32/20) et celle capitalisée
|
||||
(moyenne 10,36/20):
|
||||
<img src="/fig/but-uescap-bul-avant.png" width="70%">
|
||||
|
||||
Il décide de ne pas refaire cette UE1. Pour cela, on le désinscrit de l'UE (menu
|
||||
**Inscriptions** / **Gérer les inscriptions aux UEs et modules**).
|
||||
|
||||
<img src="/fig/but-uescap-desincr.png" width="40%">
|
||||
|
||||
Maintenant, son UE1 capitalisée apparait seule sur son bulletin.
|
||||
|
||||
Dans cet exemple, la ressource `R101` (commune) est rattachée à l'UE 1 (mais ce
|
||||
rattachement technique n'a pas de conséquences pratiques). L'étudiant reste bien
|
||||
sûr inscrit à `R101` (et doit suivre ses cours), puisque cette ressource
|
||||
intervient dans les autres UE non capitalisées.
|
||||
|
||||
S'il y a des ressources dont les notes ne contribuent qu'à l'UE1, l'étudiant
|
||||
peut ne pas les suivre: il faut alors le désincrire sélectivement au niveau du
|
||||
tableau de bord module.
|
||||
|
||||
C'est dans cet exemple le cas pour la SAÉ `SAE11`.
|
||||
|
||||
<img src="/fig/but-uescap-inscrmodule.png" width="30%">
|
||||
|
||||
## Gestion des semestres à l'étranger
|
||||
|
||||
Certains étudiants suivent parfois des semestres à l'extérieur de leur
|
||||
établissement d'origine.
|
||||
|
||||
Le jury a décidé d'une équivalence entre certaines UEs suivies à l'extérieur et
|
||||
celles du la formation d'origine.
|
||||
|
||||
Il est important de reporter ces résultats dans ScoDoc afin que celui-ci puisse
|
||||
tenir compte des UEs validés, de leurs ECTS, et en fin de cursus délivrer
|
||||
correctement le diplôme.
|
||||
|
||||
Une façon simple de traiter ce cas et de le gérer comme les transferts
|
||||
d'étudiants en cours de cursus: à l'inscription dans le semestre $S_{n+1}$, on
|
||||
va enregistrer les validations d'UEs *antérieures* obtenues dans le semestre
|
||||
$S_n$, que celui ci est été effectué à l'étranger (équivalence des UEs) ou dans
|
||||
un autre établissement (transfert).
|
||||
|
||||
Note: il y aura alors un "trou" dans le cursus, par exemple $S_1, S_2, S_3, S_5$, si
|
||||
$S_4$ est effectué à l'étranger.
|
||||
|
||||
Dans cet exemple, l'étudiant a suivi son semestre $S_4$ à l'extérieur: il
|
||||
n'apparait pas sur sa fiche. Après inscription en S5, on valide ses UEs de S4.
|
||||
|
||||
<img src="/screens/validation-ues-anterieures-menu.png" width="70%"
|
||||
alt="Menu validation UEs antérieures">
|
||||
|
||||
Lors de la saisie d'une validation d'UE antérieure, on indique son code jury (en
|
||||
général `ADM` si il n'y a pas eu de problèmes), et la note obtenue (qui pourra
|
||||
servir comme UE capitalisée ou sur les avis de poursuite d'études):
|
||||
|
||||
<img src="/screens/validation-ues-anterieures-saisie.png" width="70%"
|
||||
alt="Formulaire validation UEs antérieures">
|
83
docs/BUTCodesJury.md
Normal file
83
docs/BUTCodesJury.md
Normal file
@ -0,0 +1,83 @@
|
||||
# Codes jury en Bachelor Universitaire de Technologie (BUT)
|
||||
|
||||
Les tableaux ci-dessous récapitulent les codes utilisés lors des jurys BUT. La
|
||||
signification de chaque code est expliquée, ainsi que la correspondance avec
|
||||
certains codes préconisés par l'AMUE et l'ADIUT pour Apogée.
|
||||
|
||||
## Codes d'année
|
||||
|
||||
*Les codes d'année BUT sont associés à la formation et non au semestre: on ne
|
||||
valide qu'une seule fois BUT1, BUT2 puis BUT3.*
|
||||
|
||||
| ScoDoc | AMUE | Signification |
|
||||
|--------|------|---------------|
|
||||
| `ABAN` | `ABAN` | ABANdon constaté (sans lettre de démission) |
|
||||
| `ABL` | `ABL` | Année Blanche |
|
||||
| `ADM` | | Admis |
|
||||
| `ADJ` | | Admis par décision jury |
|
||||
| `ATJ` | `nd` | Non validé pour une autre raison, voir règlement local |
|
||||
| `DEF` | | (défaillance) Non évalué par manque assiduité |
|
||||
| `DEM` | | Démission |
|
||||
| `EXCLU`| `EXC` | EXClusion, décision réservée à des décisions disciplinaires |
|
||||
| `NAR` | `REO` | Non admis, réorientation |
|
||||
| `PAS1NCI`| `PAS1NCI` | Non admis, mais passage par décision de jury (Passage en Année Supérieure avec au moins 1 Niveau de Compétence Insuffisant (RCUE<8)) |
|
||||
| `PASD` | `PASD` | Non admis, mais passage de droit |
|
||||
| `RAT` | | En attente d’un rattrapage |
|
||||
| `RED` | `RED` | Ajourné, mais autorisé à redoubler |
|
||||
|
||||
|
||||
## Codes RCUE (niveaux de compétences annuels)
|
||||
|
||||
*Les codes de RCUE sont associés à la formation: chaque niveau de compétence est
|
||||
validé une fois au maximum. En cas de redoublement, le code RCUE peut changer.*
|
||||
|
||||
| ScoDoc | AMUE | Signification |
|
||||
|--------|------|---------------|
|
||||
| `ABAN` | | Non évalué pour manque assiduité |
|
||||
| `ADM` | `VAL`| Acquis |
|
||||
| `ADJ` | `CODJ`| Acquis par décision du jury |
|
||||
| `ADSUP`| | Acquis parce que le niveau de compétence supérieur est acquis |
|
||||
| `AJ` | `AJ` | Attente pour problème de moyenne |
|
||||
| `ATJ` | `nd` | Non validé pour une autre raison, voir règlement local |
|
||||
| `CMP` | | Acquis par compensation annuelle |
|
||||
| `DEF` | | Défaillant |
|
||||
| `RAT` | | En attente d’un rattrapage |
|
||||
|
||||
|
||||
## Codes des Unités d'Enseignement (UE)
|
||||
|
||||
Les codes d'UE sont associés aux UE d'un semestre. En cas de redoublement,
|
||||
l'UE antérieure garde son code, non écrasé par le redoublement. Chaque UE suivie a son code.
|
||||
|
||||
| ScoDoc | AMUE | Signification |
|
||||
|---------|------|---------------|
|
||||
| `ABAN` | `ABAN` | Non évalué pour manque d’assiduité Non présentation des notes de l’étudiant au jury |
|
||||
| `ADM` | `VAL` | Acquis (ECTS acquis, UE capitalisée) |
|
||||
| `ADJ` | | Acquis par décision de jury (ECTS acquis) |
|
||||
| `ADJR` | | Acquis par décision de jury sur le RCUE (ECTS acquis) |
|
||||
| `ADSUP` | | Acquis parce que le niveau de compétence supérieur est acquis |
|
||||
| `AJ` | `AJ` | Attente pour problème de moyenne |
|
||||
| `ATJ` | `nd` | Non validé pour une autre raison, voir règlement local |
|
||||
| `CMP` | `COMP`| Acquis par compensation UE compensée avec l’UE de même compétence et de même année (ECTS acquis) |
|
||||
| `DEF` | `ABAN`| Défaillant Pas ou peu de notes par arrêt de la formation |
|
||||
| `DEM` | | Démission |
|
||||
| `RAT` | | En attente d’un rattrapage |
|
||||
| `UEBSL` | `UEBSL`| UE blanchie |
|
||||
|
||||
## Rappels de l'arrêté BUT (extraits)
|
||||
|
||||
- Au sein de chaque regroupement cohérent d’UE, la compensation est intégrale. Si une UE n’a pas été acquise en raison d’une moyenne inférieure à 10, cette UE sera acquise par compensation si et seulement si l’étudiant a obtenu la moyenne au regroupement cohérent auquel l’UE appartient.
|
||||
- La poursuite d'études dans un semestre pair d’une même année est de droit pour tout étudiant. La poursuite d’études dans un semestre impair est possible _si et seulement si_ l’étudiant a obtenu :
|
||||
- la moyenne à plus de la moitié des regroupements cohérents d’UE
|
||||
- et une moyenne égale ou supérieure à 8 sur 20 à chaque regroupement cohérent d’UE.
|
||||
- La poursuite d'études dans le semestre 5 nécessite de plus la validation de toutes les UE des semestres 1 et 2 dans les conditions de validation des points 4.3 et 4.4, ou par décision de jury.
|
||||
|
||||
### Textes de référence
|
||||
|
||||
- [Bulletin officiel spécial n°4 du 26 mai 2022](https://www.enseignementsup-recherche.gouv.fr/fr/bo/21/Special4/ESRS2114777A.htm)
|
||||
- [Version pdf de l'arrêté de mai 2022 sur la licence professionnelle « bachelor universitaire de technologie »](https://cache.media.education.gouv.fr/file/SP4-MESRI-26-5-2022/10/0/spe617_annexe1_1426100.pdf)
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Le BUT](BUT.md)
|
||||
- [Contacts](Contact.md)
|
@ -10,10 +10,14 @@ alt="Niveaux de compétences des parcours du BUT Informatique">
|
||||
Les coefficients des ressources et SAÉs en BUT sont définis localement par les
|
||||
établissement, ainsi que les crédits ECTS associés aux UE.
|
||||
|
||||
Dans cet exemple, nous allons voir comment traiter cette configuration cas, plus
|
||||
complexe que le cas d'une spécialité typique de BUT: on va supposer que les
|
||||
coefficients d'une même ressource varient suivant le parcours suivi par
|
||||
l'étudiant, et que les ECTS d'une même UE dépendent parfois du parcours.
|
||||
Cette page détaille un exemple de mise en place d'un BUT Info. Cette
|
||||
configuration est plus complexe que le cas d'une spécialité typique de BUT: on
|
||||
va supposer que les coefficients d'une même ressource varient suivant le
|
||||
parcours suivi par l'étudiant, et que les ECTS d'une même UE dépendent parfois
|
||||
du parcours.
|
||||
|
||||
Après mise en place de la formation, nous allons créer les semestres, y inscrire
|
||||
les étudiants et ternir un jury.
|
||||
|
||||
## Saisir ou importer le programme de formation
|
||||
|
||||
@ -77,7 +81,6 @@ De même, pour le S6, version simplifiée sans UE spécifiques:
|
||||
|
||||
<img src="/screens/but-info-choisir-nom-ue.png" width="50%">
|
||||
|
||||
|
||||
## Associer les UE et les niveaux de compétences
|
||||
|
||||
Chaque niveau de compétence (1, 2 ou 3) correspond à une année, donc à deux UEs
|
||||
@ -134,7 +137,7 @@ l'ensemble avant de poursuivre !
|
||||
Dans la plupart des cas, le nombre de crédits ECTS d'une UE est constant. Néanmoins,
|
||||
certaines spécialités ou établissement, on peut vouloir le faire varier selon le
|
||||
parcours. Une solution serait de dupliquer l'UE (comme on le fait pour décliner
|
||||
les coefficients), mais il est plus simple de déclarer les ETCT dans chaque
|
||||
les coefficients), mais il est plus simple de déclarer les ECTS dans chaque
|
||||
parcours:
|
||||
|
||||
<img src="/screens/but-info-ue-lien-ects.png" width="40%">
|
||||
@ -143,6 +146,100 @@ parcours:
|
||||
|
||||
## Coefficients des ressources et SAÉs
|
||||
|
||||
TODO (et bug à corriger)
|
||||
Imaginons qu'en S4, la ressource `R4.01` ait le coefficient 14 vers l'UE41 dans
|
||||
le parcours A, mais le coefficient 23 dans le parcours B. Nous avons vu plus
|
||||
haut que nous avions créé une UE par parcours, `UE41-A` et `UE41-B`. reste à
|
||||
leur attribuer leurs coefficients via le formulaire habituel:
|
||||
|
||||
<img src="/screens/but-info-edit-coefs-S4.png" width="40%">
|
||||
|
||||
L'intérêt de cette approche est qu'on a une seule ressource pour les deux
|
||||
parcours, ce qui simplifie la saisie et le suivi des évaluations et des notes.
|
||||
Bien sûr, si la ressource était pédagogiquement distincte dans les deux parcours
|
||||
(activités différentes, examens spécifiques...) il serait préférable de créer
|
||||
deux versions de la ressources (par exemple `R4.01-A`et `R4.01-B`).
|
||||
|
||||
## Mise en place des semestres
|
||||
|
||||
La création des semestres ne présentent aucune particularité dans ce cas. Il
|
||||
faut juste indiquer les parcours proposés dans le semestre. Dans notre exemple:
|
||||
|
||||
<img src="/screens/but-info-sem-parcours-A-B.png" width="50%">
|
||||
|
||||
Remarque: si la spécialité n'a que des compétences communes dans ce semestre
|
||||
(tronc commun, fréquent en BUT1), *ne pas cocher de parcours*.
|
||||
|
||||
## Affectation des étudiants aux parcours
|
||||
|
||||
Nous supposons dans la suite que nous avons les deux parcours A et B dans notre
|
||||
département, les étudiants des deux parcours étant dans les mêmes semestres
|
||||
ScoDoc. Les ressources et coefficients proposés sont là pour illustrer et ne
|
||||
correspondent pas à la réalité.
|
||||
|
||||
On affecte les étudiants aux parcours grâce à l'éditeur de groupes et partitions
|
||||
(accessible via le menu **Groupes**): la partition nommée *parcours* est
|
||||
spéciale et est utilisée par ScoDoc pour savoir à quel parcours appartient
|
||||
l'étudiant.
|
||||
|
||||
Dans l'exemple ci-dessous, on a deux étudiants dans chaque parcours A et B:
|
||||
|
||||
<img src="/screens/but-info-groupes-parcours.png" width="75%">
|
||||
|
||||
## Inscriptions des étudiants aux modules de leurs parcours
|
||||
|
||||
Il faut que chaque étudiant soit inscrit aux modules (ressources ou SAÉs) de
|
||||
tronc commun, à et à ceux spécifiques à son parcours. Pour cela, on passe par le
|
||||
menu "**Inscriptions / Gérer les inscriptions aux UEs et modules**".
|
||||
|
||||
Dans chaque module, on peut régler les inscriptions:
|
||||
|
||||
<img src="/screens/but-info-inscr-module.png" width="30%">
|
||||
|
||||
## Cas particulier: coefficients variables d'un parcours à l'autre
|
||||
|
||||
Dans certains, cas, les coefficients d'une ressource ou SAÉ ne sont pas les
|
||||
mêmes dans tous les parcours, ou bien diffèrent d'une modalité à l'autre
|
||||
(formation initiale et apprentissage). Il est possible de traiter cela en créant
|
||||
différentes copies de la ressource, par exemple
|
||||
|
||||
- Anglais_A
|
||||
- Anglais_B
|
||||
|
||||
<img src="/screens/formation-ressources-AB.png" width="30%">
|
||||
|
||||
Les deux vont apparaitre dans le tableau de coefficients où il sera possible de
|
||||
les différencier:
|
||||
|
||||
<img src="/screens/formation-coefs-AB.png" width="30%">
|
||||
|
||||
Ensuite, suivant les cas:
|
||||
|
||||
- si vos parcours ou modalité sont dans des *formsemestres* différents, choisir
|
||||
dans chacun la (ou les) ressources adaptées. Dans l'exemple ci-dessous, ce
|
||||
semestre n'utilise que les modules du parcours A et ceux de tronc commun
|
||||
(comme le stage):
|
||||
|
||||
<img src="/screens/formsemestre-choix-modules-parcours-A.png" width="50%">
|
||||
|
||||
- si le *formsemestre* regroupe des étudiants de parcours différents, cocher les
|
||||
modules des parcours concernés, et inscrire sélectivement les étudiants.
|
||||
Dans l'exemple ci-dessous on a inscrit les étudiants du groupe de parcours A
|
||||
au module "A", et B au module "B".
|
||||
|
||||
<img src="/screens/formsemestre-choix-modules-parcours.png" width="50%">
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Le BUT: détails et calculs](BUT.md)
|
||||
- [Guide du responsable de formation](GuideAdminFormation/md)
|
||||
- [Programmes de formation](Formations.md)
|
||||
- [Référentiel de compétence du BUT](BUTReferentielCompetences.md)
|
||||
- [Guide utilisateur](GuideUtilisateur.md)
|
||||
- [Tutoriels vidéo](https://www.youtube.com/channel/UCb0JYCBRi0CsE4XFp4ByhXg)
|
||||
- [Gestion des UE Bonus](https://www.youtube.com/watch?v=SVbjuDpq-lI)
|
||||
- [Mise en place des parcours BUT](https://www.youtube.com/watch?v=OnuOXJo-3ro)
|
||||
- [Saisie des codes Apogée](https://www.youtube.com/watch?v=MW0nNhbBjDM)
|
||||
- [Du DUT au BUT: comment transformer un programme](https://www.youtube.com/watch?v=9HizGTvYgck)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
22
docs/BUTJurys.md
Normal file
22
docs/BUTJurys.md
Normal file
@ -0,0 +1,22 @@
|
||||
# Les jurys de BUT
|
||||
|
||||
!!! warning Travaux en cours
|
||||
Cette page est en cours de rédaction.
|
||||
|
||||
Le Bachelor Universitaire de Technologie (BUT) institue des règles de
|
||||
progression et de validation spécifiques dont ScoDoc tient compte.
|
||||
|
||||
## Décisions de jury en BUT
|
||||
|
||||
*décrire sur quoi portent les décisions (UE, )
|
||||
|
||||
Voir détail des codes [Codes de jurys BUT](BUTCodesJury.md).
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Récapitulatif des opérations en fin de semestre](TransitionSemestre.md)
|
||||
- [Codes de jurys BUT](BUTCodesJury.md)
|
||||
- [Calculs spécifiques en BUT](BUT.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
70
docs/BUTReferentielCompetences.md
Normal file
70
docs/BUTReferentielCompetences.md
Normal file
@ -0,0 +1,70 @@
|
||||
# Le référentiel de compétence du BUT
|
||||
|
||||
Chaque spécialité de BUT est définie par un référentiel de compétence et un
|
||||
référentiel de formation. Ces documents sont publiés ici:
|
||||
[https://www.enseignementsup-recherche.gouv.fr/fr/bo/21/Special4/ESRS2114777A.htm](https://www.enseignementsup-recherche.gouv.fr/fr/bo/21/Special4/ESRS2114777A.htm)
|
||||
|
||||
Le référentiel de compétence définit notamment les compétences et leurs niveaux
|
||||
pour chaque parcours de la spécialité. Ce document publié par le ministère ne
|
||||
peut pas être modifié par les universités: les adaptations portent uniquement
|
||||
sur les modalités de formation (adaptations locales du référentiel de formation,
|
||||
validées par le CFVU de chaque établissement).
|
||||
|
||||
ScoDoc propose de charger les référentiels de compétences, qui ont été publiés
|
||||
en format XML par l'application Orébut de l'ADIUT.
|
||||
|
||||
Une fois chargées, ces données ne sont pas modifiables.
|
||||
|
||||
## Formation et référentiel de compétences
|
||||
|
||||
Rappel: dans ScoDoc, on appelle *formation* le programme pédagogique, qui
|
||||
définit l'ensemble des UEs, ressources, SAÉs et leurs coefficients respectifs.
|
||||
Voir détails [sur la page Formation](Formations.md).
|
||||
|
||||
Un formation de type BUT *doit* être associée à un référentiel de compétence.
|
||||
Sans cela, ScoDoc ne sait pas quels UEs et RCUEs doivent être validés. Voir
|
||||
détail de la configuration sur la page
|
||||
[Modélisation BUT: exemple de la spécialité Informatique](BUTExempleInfo.md).
|
||||
|
||||
## Changement de versions du référentiel de compétences
|
||||
|
||||
Il peut arriver que le référentiel de compétences d'une spécialité soit mis à
|
||||
jour: ainsi, en 2023 de nouvelles versions ont été publiées pour de nombreuses
|
||||
spécialités, corrigeant certains détails (intitulés de parcours, ...).
|
||||
|
||||
Les étudiants ayant commencé dans un référentiel devraient en principe continuer
|
||||
jusqu'au diplôme avec ce même référentiel.
|
||||
|
||||
Exemple de situation en Septembre 2023:
|
||||
|
||||
- S1 : formation v2, référentiel 2023
|
||||
- S3 : formation v1, référentiel 2021
|
||||
- S5 : formation v1, référentiel 2021
|
||||
|
||||
Ici "formation v2" aura été créé comme une nouvelle version de la formation v1,
|
||||
puis associée au nouveau référentiel.
|
||||
|
||||
Si toutefois le S3 était associé à la v2, avec le nouveau référentiel, ScoDoc
|
||||
considérait que les RCUEs du BUT1 ne sont pas valides pour la nouvelle version:
|
||||
en effet, RCUEs et compétences sont liés à un référentiel donné.
|
||||
Dans ce cas, il faudrait procéder, pour chaque étudiant, à la validation
|
||||
manuelle de ses RCUEs du nouveau référentiel comme des validation de RCUEs
|
||||
"antérieurs". C'est heureusement facile à faire sur la page de suivi de
|
||||
l'acquisition des niveaux de compétences:
|
||||
|
||||
<img src="/screens/but-validation-rcues.png" width="50%">
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Le BUT: détails et calculs](BUT.md)
|
||||
- [Guide du responsable de formation](GuideAdminFormation/md)
|
||||
- [Programmes de formation](Formations.md)
|
||||
- [Guide utilisateur](GuideUtilisateur.md)
|
||||
- [Tutoriels vidéo](https://www.youtube.com/channel/UCb0JYCBRi0CsE4XFp4ByhXg)
|
||||
- [Gestion des UE Bonus](https://www.youtube.com/watch?v=SVbjuDpq-lI)
|
||||
- [Mise en place des parcours BUT](https://www.youtube.com/watch?v=OnuOXJo-3ro)
|
||||
- [Saisie des codes Apogée](https://www.youtube.com/watch?v=MW0nNhbBjDM)
|
||||
- [Du DUT au BUT: comment transformer un programme](https://www.youtube.com/watch?v=9HizGTvYgck)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
315
docs/BonusMalus.md
Normal file
315
docs/BonusMalus.md
Normal file
@ -0,0 +1,315 @@
|
||||
|
||||
# Mise en œuvre de Bonus/Malus sur les notes
|
||||
|
||||
Scodoc permet l'application de bonus/malus sur les moyennes générales (formation
|
||||
non BUT) et/ou les moyennes d'UE. Il existe deux mécanismes complémentaires pour
|
||||
cela:
|
||||
|
||||
## Les bonus sport/culture
|
||||
|
||||
Le bonus sport/culture permet de calculer un modificateur sur la moyenne
|
||||
générale (formations non BUT) ou sur chacune des UE (BUT). La valeur du bonus
|
||||
est calculée à partir d'un note sur 20 et au moyen d'une formule propre à chaque
|
||||
IUT.
|
||||
|
||||
## Les modules de malus
|
||||
|
||||
Il est fréquent d'introduire des pénalités ou *malus* sur les moyennes calculées
|
||||
à partir des notes. Par exemple, dans certains établissements, l'absence de
|
||||
l'étudiant à des activités obligatoires peut entrainer des points de pénalités.
|
||||
Inversement, certaines activités facultatives pourraient donner lieu à des
|
||||
bonifications.
|
||||
|
||||
|
||||
Pour gérer cela ScoDoc propose de déclarer des modules de *malus*: les notes de
|
||||
malus sont directement *soustraites* à la moyenne générale de l'UE à laquelle
|
||||
elles appartiennent. Contrairement aux
|
||||
notes ordinaires dans ScoDoc, les notes de malus sont toujours comprises entre
|
||||
-20 et +20. Une note de malus de 1 va diminuer la moyenne de l'UE de 1. Une note
|
||||
négative augmenterait cette moyenne. Les moyennes d'UE sont toujours comprises
|
||||
entre 0 et 20: si l'application du malus donne une note supérieure à 20 (ou
|
||||
inférieure à zéro), elle est ramenée à 20 (ou à zéro).
|
||||
|
||||
- A la différence du bonus sport/culture, ces modifications ne portent pas
|
||||
uniformément sur la totalité des UEs. Si on veut que le malus s'applique à
|
||||
plusieurs UE, il faudra créer plusieurs modules de malus.
|
||||
|
||||
- De plus, aucune formule n'est implémentée et on saisira directement la valeur
|
||||
du malus (ou bonus)
|
||||
|
||||
- Les valeurs saisies ne sont pas affichées telles quelles sur les bulletins.
|
||||
Seule la somme des modificateurs est affichée (à coté de l'UE sur laquelle
|
||||
elle porte)
|
||||
|
||||
- Il est possible de décrire plusieurs évaluations (donc plusieurs saisies):
|
||||
c'est la moyenne (non pondérée) des valeurs de malus qui sera appliquée à l'UE.
|
||||
|
||||
- La valeur saisie peut être négative (et donnera alors un bonus);
|
||||
l'affichage est mis à jour en conséquence. C'est donc la possibilité
|
||||
d'inclure un bonus dont la valeur n'est pas calculée par la formule
|
||||
configurée (cf. [Intégration de la règle de calcul](#integration-de-la-regle-de-calcul)).
|
||||
|
||||
## Comparatif bonus/malus
|
||||
|
||||
Le tableau ci-dessous résume les différences entre les bonus sport/culture et
|
||||
les modules de malus.
|
||||
|
||||
| Critère | Bonus Sport/culture | Module de Malus |
|
||||
|:-------------------------------------|:--------------------------------------------------|:-------------------------------------------|
|
||||
| **Structure** | UE Spécifique et modules (type standard) attachés | Module spécifique (type malus) |
|
||||
| **Valeur du bonus/malus** | Calculé à partir d'une note | Saisie directe |
|
||||
| **Application sur toutes les UE** | Automatique | Autant de modules que d'UE modifiées |
|
||||
| **Application sur une seule UE** | Impossible | Un module par UE modifiée |
|
||||
| **Modification** | Bonus seulement | Malus ou Bonus |
|
||||
| **Affichage** | Affichage du bonus et du détail | Affichage du bonus/malus seulement |
|
||||
| **Cumul de plusieurs modificateurs** | voir [les remarques](#remarques) | Déclarer une évaluation par type de modif. |
|
||||
|
||||
## Bonus Sport & Culture
|
||||
|
||||
### Intégration de la règle de calcul
|
||||
|
||||
Il faut tout d'abord régler ScoDoc pour utiliser la formule propre à votre
|
||||
établissement. Cela est fait une fois pour toutes et pour tous les départements
|
||||
et affectera les semestres pour lesquels un bonus sport est utilisé.
|
||||
|
||||
Pour cela l'administrateur du site (lui seul y est autorisé) doit aller sur la
|
||||
page de configuration de Scodoc (bandeau en haut de la page d'accueil)
|
||||
|
||||
![configuration](screens/BonusMalus_01.png)
|
||||
|
||||
puis, dans la section '`Calcul des "bonus" définis par l'établissement`', sélectionner
|
||||
l'établissement dans le dans le menu déroulant.
|
||||
|
||||
![choix-bonus-sport](screens/BonusMalus_02.png)
|
||||
|
||||
Si l'établissement n'apparaît pas:
|
||||
|
||||
1. L'item '`Bonus "Direct"`' permet de saisir directement la valeur du
|
||||
modificateur (après un calcul préalable hors scodoc)
|
||||
|
||||
2. Vous pouvez demander la création de la formule spécifique à votre
|
||||
établissement sur le serveur Discord (voir [contacts](Contact.md)) en précisant:
|
||||
- Le nom de votre établissement,
|
||||
- l'extrait du règlement intérieur qui décrit cette bonification, (celui ci
|
||||
apparaîtra dans l'encadré explicatif)
|
||||
- Quelques cas d'usages (pour les tests)
|
||||
|
||||
### Ajout d'UE Sport/culture
|
||||
|
||||
#### Bonus sport/culture
|
||||
|
||||
L'opération suivante consiste à ajouter dans le programme l'UE Sport/Culture.
|
||||
|
||||
1. Éditer la formation. Pour cela vous pouvez passer par le menu `SEMESTRE >
|
||||
Voir la formation...` (ceci permet d'aller dans le programme associé au
|
||||
semestre.
|
||||
|
||||
2. Ajouter une UE 'Sport/Culture',
|
||||
- Donner un titre (en y incluant le semestre visé - toutes les UEs d'une
|
||||
formation doivent avoir leur propre nom et il y aura aussi probablement
|
||||
des UE sport pour les autres semestres)
|
||||
- Idem pour l'acronyme
|
||||
- Choisissez le Type `Sport/Culture (points bonus)`
|
||||
- Indiquez 0 ECTS (obligatoire bien que cette valeur n'ait pas d'importance)
|
||||
![ajout-UE-sport](screens/BonusMalus_03.png)
|
||||
|
||||
3. Ajouter un module à l'UE sport et l'attacher à l'UE Sport du semestre
|
||||
Attention ! ce module est un module standard (pas un module de malus, ni une
|
||||
ressource, ni une SAÉ) ![module-sport](screens/BonusMalus_04.png)
|
||||
|
||||
## Modules de Malus
|
||||
|
||||
Il faut ajouter à la formation un ou plusieurs modules de malus. Le module est
|
||||
rattaché à une UE et modifiera la moyenne de cette UE.
|
||||
|
||||
1. Entrer dans le semestre,
|
||||
|
||||
2. activer le menu `SEMESTRE > Modifier le semestre`
|
||||
![modifier-le-semestre](screens/BonusMalus_05.png)
|
||||
|
||||
A ce niveau, vous pouvez soit:
|
||||
|
||||
- ajouter les modules malus en une seule fois pour toutes les UEs par le lien
|
||||
`ajouter un module de malus dans chaque UE su S...`
|
||||
![ajout-global-malus](screens/BonusMalus_11.png)
|
||||
|
||||
- Ou, si une des UEs ne demande pas l'application d'un malus, ajouter seulement
|
||||
les modules nécessaires en les créant un par un:
|
||||
![ajout-simple-malus](screens/BonusMalus_12.png) en précisant le type `Malus`
|
||||
et en l'attachant à l'UE concernée.
|
||||
![ajout-simple-malus-détail](screens/BonusMalus_13.png)
|
||||
|
||||
L'étape [Ajout d'UE et de module
|
||||
Sport/Culture](#ajout-due-sportculture-etou-de-module-de-malus) doit être faite
|
||||
lors de la conception d'un programme, mais n'a pas a être réitérée lors de la
|
||||
création d'une nouvelle version d'un programme avec UE sport.
|
||||
|
||||
Une fois le module créé (et ajouté à un semestre), on peut y déclarer une
|
||||
évaluation et saisir les notes de bonus/malus. Ces notes sont par défaut *à prise
|
||||
en compte immédiate*, auquel cas il n'est pas nécessaire de saisir des notes de malus
|
||||
pour tous les étudiants.
|
||||
|
||||
|
||||
## Application à un semestre
|
||||
|
||||
Quel que soit le type de bonus utilisé, le semestre concerné doit intégrer le
|
||||
ou les modules créés précédemment, que ce soit les modules appartenant à l'UE
|
||||
sport/culture ou les modules de malus.
|
||||
|
||||
Si la création du semestre est postérieur à la modification du programme, ou si
|
||||
le semestre résulte du clonage d'un semestre déjà configuré, les éléments de
|
||||
bonus/malus sont déjà pris en compte et on peut passer directement à la partie
|
||||
[inscription des
|
||||
étudiants](finaliser-linscription-des-étudiants-concernés-si-inscription-sélective)
|
||||
|
||||
Dans le cas contraire (le bonus n'avait pas été prévu au départ et doit être
|
||||
ajouté en cours de semestre) la manipulation suivante permet l'application des
|
||||
éléments de bonus/malus aux au semestre existant:
|
||||
|
||||
### Stratégies d'inscription
|
||||
|
||||
Dans tous les cas de figure, l'objectif est d'inscrire aux modules de
|
||||
bonus/malus au moins les étudiants qui en bénéficient. On a deux stratégies
|
||||
possibles:
|
||||
|
||||
1. Inscription de tous les étudiants du semestre (inscription générale)
|
||||
et attribuer la note `EXC`aux étudiants non concernés. Stratégie à
|
||||
éviter pour le bonus sport/culture afin d'éviter l'affichage d'une
|
||||
section bonus vide dans les bulletins des étudiants non concernés.
|
||||
|
||||
2. N'inscrire que les étudiants concernés (inscription sélective). **Note**: si
|
||||
le bonus sport/culture peut résulter de plusieurs activités (par exemple
|
||||
sport et LV2) on peut tout de même être amené à placer des `EXC`.
|
||||
|
||||
### Application des modifications du programme à un semestre existant
|
||||
|
||||
1. Entrer dans le semestre,
|
||||
|
||||
2. activer le menu `SEMESTRE > Modifier le semestre`
|
||||
![modifier-le-semestre](screens/BonusMalus_05.png)
|
||||
|
||||
3. Les éléments de bonus/malus apparaissent mais ne sont pas activés
|
||||
![activation-module-sport](screens/BonusMalus_06.png)
|
||||
|
||||
4. Activer les modules utilisés et y affecter les étudiants selon la stratégie
|
||||
choisie (inscription générale: tous, inscription sélective: aucun)
|
||||
|
||||
5. Valider les modifications opérées
|
||||
|
||||
### Finaliser l'inscription des étudiants concernés (si inscription sélective)
|
||||
|
||||
**Note**: cette finalisation peut être faite juste avant la saisie des notes de sport.
|
||||
|
||||
1. Se placer dans le module bonus/malus
|
||||
![sélection-module-sport](screens/BonusMalus_07.png)
|
||||
ou
|
||||
![sélection-module-malus](screens/BonusMalus_14.png)
|
||||
|
||||
2. Affiner les inscriptions en cliquant sur le lien de modification:
|
||||
![inscriptions-module-sport](screens/BonusMalus_08.png)
|
||||
|
||||
### Saisie des notes
|
||||
|
||||
- Créer si besoin une évaluation dans le module courant
|
||||
|
||||
- Saisir les notes des étudiants.
|
||||
- Pour un bonus sport/culture : la valeur à saisir (valeur du bonus, note sur
|
||||
20, ...) dépend de la règle de l'établissement.
|
||||
- Pour un module de malus Saisir directement la valeur du *malus* (pour que
|
||||
l'étudiant bénéficie d'un bonus, entrer une valeur négative)
|
||||
|
||||
#### Remarques
|
||||
|
||||
- Le `Bonus "direct"` autorise des bonus de 0 à 20 mais plafonne les notes d'UE à 20
|
||||
- On peut avoir plusieurs évaluations dans le module sport: dans ce cas ScoDoc
|
||||
calcul la note de module comme habituellement (y compris en prenant en
|
||||
compte les éventuels coefficients), puis calcul la valeur du bonus à partir
|
||||
de cette note de module. On ne peut donc pas 'cumuler' (un bonus sport et un
|
||||
bonus LV2 par exemple) par ce biais.
|
||||
- On peut avoir plusieurs modules attachées à l'UE sport. Dans ce cas, ScoDoc
|
||||
calcule le bonus qui produirait chacun de ces modules et les additionne.
|
||||
Dans ce cas, les bonus sont cumulés, mais:
|
||||
|
||||
- Cette méthode n'est applicable que si les formules de calcul de chacun des bonus cumulés sont identiques.
|
||||
|
||||
- Dans tous les cas, les notes d'UE restent plafonnées entre 0 et 20.
|
||||
|
||||
#### Exemple
|
||||
|
||||
On a déclaré dans une UE sport 2 modules:
|
||||
|
||||
- `Sport` alimenté par 2 évaluations (Sport et Autre),
|
||||
|
||||
- `LV2` alimenté par une seule évaluation
|
||||
|
||||
Un étudiant participe aux deux activités et obtient les notes suivantes:
|
||||
![notes-sport-exemple](screens/BonusMalus_09.png)
|
||||
|
||||
Le calcul effectué par ScoDoc est le suivant:
|
||||
|
||||
- Calcul de la moyenne du module `Sport` ( 13.00 (coef. 1) et 10.00 (coef. 2)):
|
||||
résultat : 11.00 soit un bonus de 1 pt x 5% (calcul Villetaneuse) = 0.05 points
|
||||
|
||||
- Calcul de la moyenne `LV2`: 15.00 (une seule note) soit un bonus de 5 points x 5% = 0.25 points
|
||||
|
||||
- Le bonus total sera donc de 0.30 points
|
||||
|
||||
- L'UE1 qui est de base à 19.80 sera donc amenée à 20 (plafond) grâce au bonus de 0.30
|
||||
![notes-sport-exemple-UE1](screens/BonusMalus_10.png)
|
||||
Les autres UE bénéficient du bonus de 0.30 points
|
||||
|
||||
## Affichages
|
||||
|
||||
La forme que prend l'affichage du ou des bonus/malus varie en fonction des circonstances:
|
||||
|
||||
- Aucun bonus/malus
|
||||
|
||||
- Cas 1: Bonus sport/culture uniquement
|
||||
|
||||
- Cas 2: Malus
|
||||
|
||||
- Cas 3: Bonus formulé comme malus négatif
|
||||
|
||||
Les bonus/malus sont affichés principalement sur:
|
||||
|
||||
### Table récapitulative des notes
|
||||
|
||||
Deux colonnes sont affichées pour chaque UE. pour indiquer le bonus
|
||||
sport/culture d'une part et le malus (ou bonus complémentaire) comme indiqué
|
||||
ci-dessous ![Table-des-notes](screens/BonusMalus_15.png)
|
||||
|
||||
### Relevé de notes web d'un étudiant (y compris sur la passerelle)
|
||||
|
||||
La description de l'UE inclut la valeur des bonus et malus (même si nulle) comme
|
||||
indiqué dans les exemple ci-dessous. La moyenne avant altération figure en bas
|
||||
tandis que la valeur supérieure (en gras) affiche la moyenne après bonus/malus
|
||||
(plafonnée si besoin):
|
||||
|
||||
###### Cas 1. aucun bonus malus
|
||||
![relevé-web-cas1](screens/BonusMalus_16.png)
|
||||
###### Cas 2. Bonus sport/culture uniquement
|
||||
![relevé-web-cas2](screens/BonusMalus_17.png)
|
||||
###### Cas 3. Malus
|
||||
![relevé-web-cas3](screens/BonusMalus_18.png)
|
||||
###### Cas 4. Malus négatif
|
||||
![relevé-web-cas4](screens/BonusMalus_19.png)
|
||||
|
||||
### Relevé de notes en version pdf
|
||||
|
||||
###### Cas 1. aucun bonus malus
|
||||
![relevé-pdf-cas1](screens/BonusMalus_20.png)
|
||||
###### Cas 2. Bonus sport/culture uniquement
|
||||
![relevé-pdf-cas2](screens/BonusMalus_21.png)
|
||||
###### Cas 3. Malus
|
||||
![relevé-pdf-cas3](screens/BonusMalus_22.png)
|
||||
###### Cas 4. Malus négatif
|
||||
![relevé-pdf-cas4](screens/BonusMalus_23.png)
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Calcul des notes](CalculNotes.md#bonus-sportculture)
|
||||
- [Tutoriel vidéo: ajouter un bonus sport&culture](https://www.youtube.com/watch?v=SVbjuDpq-lI)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
@ -69,8 +69,8 @@ Les options sont:
|
||||
|
||||
* *faire figurer les UE validées sur les bulletins* : code jury des UE
|
||||
|
||||
* *publier le bulletin sur le portail étudiants*: contrôle l'export XML des
|
||||
bulletins, utilisé par le portail étudiant. Désactiver si vous ne voulez pas
|
||||
* *publier le bulletin sur le passerelle étudiants*: contrôle l'export XML des
|
||||
bulletins, utilisé par la passerelle étudiant. Désactiver si vous ne voulez pas
|
||||
que les étudiants puisse lire leurs bulletins.
|
||||
|
||||
* *Bannière "provisoire" sur les bulletins*: affiche la mention "Provisoire" (ou
|
||||
|
@ -26,13 +26,13 @@ Plus de détails ci-dessous.
|
||||
|
||||
Chaque évaluation produit des notes de différents types:
|
||||
|
||||
* note numérique (positive ou nulle): sera normalisée entre 0 et 20
|
||||
- note numérique (positive ou nulle): sera normalisée entre 0 et 20
|
||||
|
||||
* note absente: considérée comme zéro
|
||||
- note absente: considérée comme zéro
|
||||
|
||||
* note en attente: non prise en compte
|
||||
- note en attente: non prise en compte
|
||||
|
||||
* note excusée: non pris en compte
|
||||
- note excusée: non pris en compte
|
||||
|
||||
Chaque étudiant a donc un nombre variable de notes à prendre en compte dans
|
||||
chaque module. Chaque note est associée à un coefficient: le coefficient de
|
||||
@ -72,7 +72,7 @@ notes sont considérés.
|
||||
|
||||
Le malus appliqué à la moyenne d'UE est donné par la somme des notes du ou des
|
||||
modules de malus de cette UE (un type spécial de modules, voir
|
||||
[ModulesMalus](ModulesMalus.md)).
|
||||
[BonusMalus](BonusMalus.md)).
|
||||
|
||||
## Calcul de la moyenne générale
|
||||
|
||||
@ -104,35 +104,29 @@ générale n'est pas définie. Toutefois, ScoDoc calcule une *moyenne indicative
|
||||
qui est la moyenne des moyennes des UE du semestre pondérée par leurs ECTS. Voir
|
||||
détails [sur la page BUT](BUT.md#moyenne-generale)
|
||||
|
||||
## Notes de rattrapage
|
||||
## Notes de rattrapage, deuxième session et bonus
|
||||
|
||||
Dans chaque module, il est possible de définir une évaluation de "rattrapage".
|
||||
Lors de la création (ou modification) de l'évaluation, indiquer le type
|
||||
"Rattrapage":
|
||||
|
||||
![CreateEvaluationRat.png](screens/CreateEvaluationRat.png)
|
||||
|
||||
Pour chaque étudiant, la note obtenue à l'évaluation de rattrapage remplace la
|
||||
moyenne du module, seulement si elle est supérieure à celle-ci.
|
||||
Voir la section [modalité d'une évaluation](Evaluation.md#bloquage-et-date-de-prise-en-compte).
|
||||
|
||||
## Bonus sport/culture
|
||||
|
||||
Ce bonus s'applique directement sur la **moyenne générale** et/ou sur les
|
||||
moyennes d'UE (notamment en BUT).
|
||||
|
||||
Les notes des UEs de type spécial "Sport & Culture" sont utilisées pour calculer ce bonus.
|
||||
Les notes des UEs de type spécial "Sport & Culture" sont utilisées pour calculer
|
||||
ce bonus.
|
||||
|
||||
Pour qu'un étudiant bénéficie de ce bonus, il doit être inscrit à un module
|
||||
d'une UE de type "Sport&Culture". Cette UE et modules associés doivent donc être
|
||||
prévu dans le programme pédagogique.
|
||||
|
||||
La règle appliquée dépend de l'établissement. Par exemple, l'Université de
|
||||
Haute Alsace appliquait le règlement suivant: *Les étudiants de l'IUT peuvent
|
||||
suivre des enseignements optionnels de l'U.H.A. (sports, musique, deuxième
|
||||
langue, culture, etc) non rattachés à une unité d'enseignement. Les points
|
||||
au-dessus de 10 sur 20 obtenus dans chacune des matières optionnelles sont
|
||||
cumulés dans la limite de 10 points. 5% de ces points cumulés s'ajoutent à la
|
||||
moyenne générale du semestre déjà obtenue par l'étudiant.*
|
||||
La règle appliquée dépend de l'établissement. Par exemple, l'Université de Haute
|
||||
Alsace appliquait le règlement suivant: *Les étudiants de l'IUT peuvent suivre
|
||||
des enseignements optionnels de l'U.H.A. (sports, musique, deuxième langue,
|
||||
culture, etc) non rattachés à une unité d'enseignement. Les points au-dessus de
|
||||
10 sur 20 obtenus dans chacune des matières optionnelles sont cumulés dans la
|
||||
limite de 10 points. 5% de ces points cumulés s'ajoutent à la moyenne générale
|
||||
du semestre déjà obtenue par l'étudiant.*
|
||||
|
||||
L'administrateur peut changer la fonction de calcul du bonus sport via le
|
||||
formulaire de configuration accessible (aux admin) depuis la page d'accueil. Si
|
||||
@ -140,6 +134,8 @@ vous souhaitez disposer d'une nouvelle règle, il faut contacter l'équipe de
|
||||
développement en indiquant (en français) le règlement en vigueur dans votre
|
||||
établissement. Le code correspondant sera ajouté via une mise à jour.
|
||||
|
||||
Pour plus de détails, voir [BonusMalus](BonusMalus.md).
|
||||
|
||||
## Arrondis et affichages
|
||||
|
||||
ScoDoc calcule les notes en haute précision. On peut saisir des notes comme
|
||||
@ -158,7 +154,7 @@ Pour valider une RCUE, on vérifie que moy_rcue > sco_codes.BUT_RCUE_SUFFISANT
|
||||
|
||||
où est défini comme BUT_RCUE_SUFFISANT = 8.0 - NOTES_TOLERANCE.
|
||||
|
||||
avec
|
||||
avec
|
||||
NOTES_TOLERANCE = 0.00499999999999
|
||||
```
|
||||
|
||||
@ -178,6 +174,7 @@ n'a pas toute la précision.
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Guide utilisateur](GuideUtilisateur.md)
|
||||
- [Les évaluations](Evaluation.md)
|
||||
- [Calculs spécifiques en BUT](BUT.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
@ -1,86 +1,107 @@
|
||||
|
||||
## Capitalisation des UEs de DUT
|
||||
# Capitalisation des UEs de DUT
|
||||
|
||||
Brève note expliquant le système de capitalisation de UE dans le cadre des DUT.
|
||||
|
||||
### Principe
|
||||
Pour le Bachelor (BUT), voir [Capitalisation des Unités d'Enseignement en
|
||||
BUT](BUTCapitalisationUE.md).
|
||||
|
||||
## Principe
|
||||
|
||||
***Arrêté d'août 2005***
|
||||
|
||||
**Article 19** - *Les unités d'enseignement sont définitivement acquises et
|
||||
capitalisables dès lors que l'étudiant y a obtenu la moyenne.
|
||||
L'acquisition de l'unité d'enseignement emporte l'acquisition
|
||||
des crédits européens correspondants.*
|
||||
capitalisables dès lors que l'étudiant y a obtenu la moyenne. L'acquisition de
|
||||
l'unité d'enseignement emporte l'acquisition des crédits européens
|
||||
correspondants.*
|
||||
|
||||
*Toute unité d'enseignement capitalisée est prise en compte dans le
|
||||
dispositif de compensation, au même titre et dans les mêmes conditions
|
||||
que les autres unités d'enseignement.*
|
||||
*Toute unité d'enseignement capitalisée est prise en compte dans le dispositif
|
||||
de compensation, au même titre et dans les mêmes conditions que les autres
|
||||
unités d'enseignement.*
|
||||
|
||||
*Dans le cas de redoublement d'un semestre, si un étudiant ayant acquis
|
||||
une unité d'enseignement souhaite, notamment pour améliorer les
|
||||
conditions de réussite de sa formation, suivre les enseignements de
|
||||
cette unité d'enseignement et se représenter au contrôle des
|
||||
connaissances correspondant, la compensation prend en compte le
|
||||
résultat le plus favorable pour l'étudiant.*
|
||||
*Dans le cas de redoublement d'un semestre, si un étudiant ayant acquis une
|
||||
unité d'enseignement souhaite, notamment pour améliorer les conditions de
|
||||
réussite de sa formation, suivre les enseignements de cette unité d'enseignement
|
||||
et se représenter au contrôle des connaissances correspondant, la compensation
|
||||
prend en compte le résultat le plus favorable pour l'étudiant.*
|
||||
|
||||
(...)
|
||||
|
||||
**Article 25** - *Les unités d'enseignement dans lesquelles la moyenne de
|
||||
10 a été obtenue sont capitalisables en vue de la reprise d'études en
|
||||
formation continue.*
|
||||
**Article 25** - *Les unités d'enseignement dans lesquelles la moyenne de 10 a
|
||||
été obtenue sont capitalisables en vue de la reprise d'études en formation
|
||||
continue.*
|
||||
|
||||
### Exemple (cas simple)
|
||||
|
||||
#### Exemple (cas simple)
|
||||
Soit un étudiant qui suit un parcours S1, S2, S2D (redoublement en semestre
|
||||
décalé). En S2, il obtient 11.5 à l'UE 1. En S2D, il obtient 10.2 en UE 1: on
|
||||
calcule alors sa moyenne de S2D en remplaçant ce 10.2 par 11.5.
|
||||
|
||||
Soit un étudiant qui suit un parcours S1, S2, S2D (redoublement en semestre décalé). En S2, il obtient 11.5 à l'UE 1. En S2D, il obtient 10.2 en UE 1: on calcule alors sa moyenne de S2D en remplaçant ce 10.2 par 11.5.
|
||||
ScoDoc prend automatiquement en compte la capitalisation des UE et l'indique sur
|
||||
les bulletins.
|
||||
|
||||
ScoDoc prend automatiquement en compte la capitalisation des UE et l'indique sur les bulletins.
|
||||
## UE capitalisées et inscriptions aux modules
|
||||
|
||||
En général, les étudiants ayant capitalisé des UE et qui redoublent un ou deux
|
||||
semestres peuvent choisir de repasser ou non ces UE. ScoDoc conservera
|
||||
automatiquement la meilleure note moyenne.
|
||||
|
||||
### UE capitalisées et inscriptions aux modules
|
||||
Si l'étudiant décide de ne pas repasser l'UE, il est préférable de ne pas
|
||||
l'inscrire aux modules correspondant du semestre qu'il redouble. Le menu
|
||||
"Inscription / Voir les inscriptions aux modules" permet de gérer facilement
|
||||
cela.
|
||||
|
||||
En général, les étudiants ayant capitalisé des UE et qui redoublent un ou deux semestres peuvent choisir de repasser ou non ces UE. ScoDoc conservera automatiquement la meilleure note moyenne.
|
||||
### Cas des changements de programmes
|
||||
|
||||
Si l'étudiant décide de ne pas repasser l'UE, il est préférable de ne pas l'inscrire aux modules correspondant du semestre qu'il redouble. Le menu "Inscription / Voir les inscriptions aux modules" permet de gérer facilement cela.
|
||||
Il arrive que le programme pédagogique change et que l'étudiant redoublant suive
|
||||
un programme différent de celui de l'UE qu'il a capitalisé. Ici, les textes sont
|
||||
flous et la jurisprudence fait défaut pour déterminer quelles UE sont
|
||||
capitalisables. En pratique, les responsables de formation (chefs de
|
||||
département) décident au cas par cas des équivalences entre UE de l'ancien
|
||||
programme et du nouveau. ScoDoc permet de faire cela en spécifiant un code d'UE
|
||||
qui sera identique (ou non) dans les deux programmes. Il convient d'être
|
||||
particulièrement attentif à ce point: dans le passé récent des IUT, il est
|
||||
arrivé dans certaines spécialités que l'UE 1 devienne l'UE 2 du nouveau
|
||||
programme.
|
||||
|
||||
## Calcul des coefficients
|
||||
|
||||
#### Cas des changements de programmes
|
||||
Il arrive que le programme pédagogique change et que l'étudiant redoublant suive un programme différent de celui de l'UE qu'il a capitalisé. Ici, les textes sont flous et la jurisprudence fait défaut pour déterminer quelles UE sont capitalisables. En pratique, les responsables de formation (chefs de département) décident au cas par cas des équivalences entre UE de l'ancien programme et du nouveau. ScoDoc permet de faire cela en spécifiant un code d'UE qui sera identique (ou non) dans les deux programmes. Il convient d'être particulièrement attentif à ce point: dans le passé récent des IUT, il est arrivé dans certaines spécialités que l'UE 1 devienne l'UE 2 du nouveau programme.
|
||||
Le calcul des coefficients des UE capitalisées pour le calcul de la moyenne
|
||||
générale est un peu compliqué. En effet:
|
||||
|
||||
* les UE n'ont pas de coefficients propres: dans le programme pédagogique, les
|
||||
coefficients sont attribués aux modules et non aux UE;
|
||||
|
||||
### Calcul des coefficients
|
||||
* le coefficient d'une UE est donc la somme des coefficients des modules qui la composent;
|
||||
|
||||
Le calcul des coefficients des UE capitalisées pour le calcul de la moyenne générale est un peu compliqué. En effet:
|
||||
* remarque: en cas d'absences excusées (notes neutralisées sur tout un module),
|
||||
le coef. d'une UE peut fort bien varier d'un étudiant à l'autre (ou, pour un
|
||||
même étudiant, d'un semestre à l'autre s'il redouble).
|
||||
|
||||
* les UE n'ont pas de coefficients propres: dans le programme pédagogique, les coefficients sont attribués aux modules et non aux UE;
|
||||
* en cas de capitalisation, ScoDoc calcule actuellement le coef. de l'UE
|
||||
capitalisée comme la somme des coefficients des modules de cette UE dans
|
||||
lesquels l'étudiant était inscrit *dans le programme du semestre durant lequel
|
||||
il a capitalisé l'UE* (changement en janvier 2016). Il est aussi possible de
|
||||
forcer manuellement le coefficient utilisé (via la page "modification du
|
||||
semestre").
|
||||
|
||||
* le coefficient d'une UE est donc la somme des coefficients des modules qui la composent;
|
||||
|
||||
* remarque: en cas d'absences excusées (notes neutralisées sur tout un module), le coef d'une UE peut fort bien varier d'un étudiant à l'autre (ou, pour un même étudiant, d'un semestre à l'autre s'il redouble).
|
||||
|
||||
* en cas de capitalisation, ScoDoc calcule actuellement le coef. de l'UE capitalisée comme la somme des coefficients des modules de cette UE dans lesquels l'étudiant était inscrit *dans le programme du semestre durant lequel il a capitalisé l'UE* (changement en janvier 2016). Il est aussi possible de forcer manuellement le coefficient utilisé (via la page "modification du semestre").
|
||||
|
||||
|
||||
#### Exemple (cas compliqué)
|
||||
### Exemple (cas compliqué)
|
||||
|
||||
Soit un étudiant qui suit un parcours S1, S2, S2.2 (redoublement en semestre décalé) et capitalise l'UE 2.1 du S2.
|
||||
|
||||
* en S2, moy. UE = 11.03, coef 8
|
||||
* en S2, moy. UE = 11.03, coef. 8
|
||||
|
||||
* en S2,2, moy UE = 10.32, coef 5.7 car pas de notes en M322 et M324
|
||||
* en S2,2, moy. UE = 10.32, coef. 5.7 car pas de notes en M322 et M324
|
||||
|
||||
Mais supposons que le programme de S2,2 ne soit *pas le même* que celui de S2 !. Par exemple on pourrait avoir:
|
||||
|
||||
* En S2: UE2.1 = { M121, M221, M322, M324, AL2.1 } coef 8
|
||||
* En S2: UE2.1 = { M121, M221, M322, M324, AL2.1 } coef. 8
|
||||
|
||||
* En S2.2: UE2.1 = { M121, M221, M322, M324, TH21, ESP21, ESPDEB21 } coef 9
|
||||
* En S2.2: UE2.1 = { M121, M221, M322, M324, TH21, ESP21, ESPDEB21 } coef. 9
|
||||
|
||||
ScoDoc prend le coef 9, afin que l'UE2.1 pèse la même chose pour tous
|
||||
ScoDoc prend le coef. 9, afin que l'UE2.1 pèse la même chose pour tous
|
||||
les étudiants de S2,2.
|
||||
|
||||
|
||||
|
||||
#### Conclusion
|
||||
### Conclusion
|
||||
|
||||
Les textes officiels étant muets sur cette question, il n'y a pas de consensus sur la meilleure façon de calculer le coefficient
|
||||
affecté aux UEs capitalisées. Le mode de calcul par défaut de ScoDoc à l'avantage d'avoir les
|
||||
@ -88,13 +109,12 @@ mêmes coefficients d'UE pour tous les étudiants du semestre (sauf
|
||||
absences et options), et l'inconvénient de voir la même UE affectée
|
||||
de coefs différents dans des semestres successifs.
|
||||
|
||||
## Mise en œuvre dans ScoDoc
|
||||
|
||||
### Mise en œuvre dans ScoDoc
|
||||
|
||||
* ScoDoc offre depuis le 21 janvier 2008 la possibilité de forcer les coefficients des UE capitalisées. Passer par "Modifier le semestre".
|
||||
|
||||
* Pour entrer les moyennes d'UE capitalisées antérieurement (dans un semestre non géré par ScoDoc ou dans un autre établissement, etc), passer par le bulletin de note de l'étudiant, et dans le menu "Autres opérations", choisir ""Enregistrer une validation d'UE antérieure".
|
||||
|
||||
|
||||
|
||||
* ScoDoc offre depuis le 21 janvier 2008 la possibilité de forcer les
|
||||
coefficients des UE capitalisées. Passer par "Modifier le semestre".
|
||||
|
||||
* Pour entrer les moyennes d'UE capitalisées antérieurement (dans un semestre
|
||||
non géré par ScoDoc ou dans un autre établissement, etc), passer par le
|
||||
bulletin de note de l'étudiant, et dans le menu "Autres opérations", choisir
|
||||
""Enregistrer une validation d'UE antérieure".
|
||||
|
@ -77,12 +77,13 @@ Ici trois champs nous intéressent:
|
||||
- **Identifiant CAS**: nécessaire
|
||||
- **Autorise connexion via CAS**: spécifie si ce compte peut ou non se connecter via CAS.
|
||||
- **Autorise connexion via ScoDoc**: spécifie si cet utilisateur peut se connecter via
|
||||
ScoDoc, sans CAS, lorsque le CAS est activé et forcé. Ceci est nécessaire par
|
||||
ScoDoc, sans CAS, lorsque le CAS est activé. Ceci est nécessaire par
|
||||
exemple pour des comptes utilisés pour l'API, ou bien pour des personnes
|
||||
extérieures à l'établissement et qui ne seraient pas (encore) dans le CAS.
|
||||
|
||||
En cas de besoin, les comptes "super-admin" peuvent toujours se connecter à ScoDoc sans CAS: si le
|
||||
forçage est activé, il leur faut passer par une adresse spéciale:
|
||||
En cas de besoin, les comptes "super-admin" peuvent toujours se connecter à
|
||||
ScoDoc sans CAS: si le forçage est activé, il leur faut passer par une adresse
|
||||
spéciale:
|
||||
|
||||
```text
|
||||
https://votre.serveur.scodoc.fr/auth/login_scodoc
|
||||
@ -95,6 +96,34 @@ forçage est activé, il leur faut passer par une adresse spéciale:
|
||||
le CAS, pensez à autoriser les comptes de l'API à se connecter sur ScoDoc sans
|
||||
CAS.
|
||||
|
||||
### Règles de connexion
|
||||
|
||||
Résumé pour s'y retrouver dans les paramètres:
|
||||
|
||||
- Au niveau de la config globale de ScoDoc:
|
||||
- CAS peut être *activé* ou non.
|
||||
- S'il est activé, il peut être *forcé* ou non.
|
||||
- Au niveau de chaque compte utilisateur:
|
||||
- on a (ou non) un "Identifiant CAS" (`cas_id`);
|
||||
- on autorise ou non la connexion via CAS (`cas_allow_login`)
|
||||
- on autorise ou non la connexion via l'identifiant ScoDoc quand CAS est activé (`cas_allow_scodoc_login`)
|
||||
|
||||
L'utilisateur pourra se connecter **via un identifiant ScoDoc** (rappel: *c'est
|
||||
nécessaire pour les comptes API*), si et seulement si:
|
||||
|
||||
- CAS non activé
|
||||
- ou compte super-admin
|
||||
- ou `cas_allow_scodoc_login` et pas (`cas_id` renseigné et `cas_allow_login` et CAS forcé)
|
||||
|
||||
(donc si il a `cas_allow_scodoc_login` mais pas de `cas_id`, il pourra se
|
||||
connecter via ScoDoc même si on a *forcé* le CAS).
|
||||
|
||||
L'utilisateur pourra se connecter **en CAS** si et seulement si:
|
||||
|
||||
- CAS activé et `cas_id` renseigné (ou règle de config. automatique)
|
||||
|
||||
|
||||
|
||||
## Sécurité: permissions et informations
|
||||
|
||||
L'utilisateur connecté via CAS a exactement les mêmes permissions que s'il
|
||||
@ -151,9 +180,10 @@ INFO: CAS login denied for cas_id=prenom.nom (unknown or inactive)
|
||||
L'authentification des clients de l'API utilise un jeton (*token*), qui est
|
||||
demandé par l'appel `/ScoDoc/api/tokens` (qui lui même appelle
|
||||
`User.get_token()`). Ce mécanisme ne passe jamais par le CAS, à condition que le
|
||||
compte utilisateur utilisé par l'API soit "*Autorisé à se connecter via ScoDoc*"
|
||||
(voir le formulaire plus haut, [configuration des
|
||||
utilisateurs](#configuration-des-utilisateurs)).
|
||||
compte utilisateur utilisé par l'API soit "*Autorisé à se connecter via
|
||||
ScoDoc*", et pas autorisé à utiliser le CAS (`cas_allow_login` faux). (voir le
|
||||
formulaire plus haut, [configuration des
|
||||
utilisateurs](#configuration-des-utilisateurs))
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
@ -35,8 +35,8 @@ réglées via via la page **Paramétrage** de chaque département:
|
||||
![Réglage des notifications](fig/config-dept-abs.png)
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
|
||||
- Configuration système: [Envoi des courriers électroniques](ProblemesMail.md)
|
||||
- Installation, flux réseaux et configuration: [Guide d'installation](GuideInstallDebian11.md)
|
||||
- Installation, flux réseaux et configuration: [Guide d'installation](GuideInstallDebian12.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
||||
|
@ -1,96 +1,84 @@
|
||||
|
||||
# Rôles définis dans l'installation standard
|
||||
# Rôles et permissions définis dans l'installation standard
|
||||
|
||||
🚧 *cette page est ancienne et à revoir*.
|
||||
La page [ConfigPermissionsDept](ConfigPermissionsDept.md) introduit les notions
|
||||
de rôles et de permissions.
|
||||
|
||||
Voir aussi sur les rôles et leur utilisation la page [ConfigPermissionsDept](ConfigPermissionsDept.md)
|
||||
Ci-dessous la liste des permissions, qui est utile notamment pour les
|
||||
utilisateurs de l'API.
|
||||
|
||||
Les informations ci-dessous ne sont utiles que pour les développeurs ou pour des usages avancés de ScoDoc.
|
||||
## Liste des permissions
|
||||
|
||||
## Principales permissions et fonctions associées
|
||||
* **AbsAddBillet** : Saisir des billets d'absences
|
||||
* **AbsChange** : Saisir des absences
|
||||
* **AbsJustifView** : Visualisation des fichiers justificatifs
|
||||
* **EditAllEvals** : Modifier toutes les évaluations
|
||||
* **EditAllNotes** : Modifier toutes les notes
|
||||
* **EditApogee** : Gérer les exports Apogée
|
||||
* **EditFormSemestre** : Mettre en place une formation (créer un semestre)
|
||||
* **EditFormation** : Changer les formations
|
||||
* **EditFormationTags** : Tagguer les formations
|
||||
* **EditPreferences** : Modifier les préférences
|
||||
* **EnsView** : Voir les parties pour les enseignants
|
||||
* **EtudAddAnnotations** : Éditer les annotations
|
||||
* **EtudChangeAdr** : Changer les adresses d'étudiants
|
||||
* **EtudChangeGroups** : Modifier les groupes
|
||||
* **EtudInscrit** : Inscrire des étudiants
|
||||
* **JustifValidate** : Définir la validité d'un justificatif (valide, invalide, modifié)
|
||||
* **Observateur** : Observer (accès lecture restreint aux bulletins)
|
||||
* **RelationsEntrepEdit** : Modifier les entreprises
|
||||
* **RelationsEntrepExport** : Exporter les données de l'application relations entreprises
|
||||
* **RelationsEntrepSend** : Envoyer des offres
|
||||
* **RelationsEntrepValidate** : Valide les entreprises
|
||||
* **RelationsEntrepView** : Voir l'application relations entreprises
|
||||
* **RelationsEntrepViewCorrs** : Voir les correspondants
|
||||
* **ScoSuperAdmin** : Super Administrateur
|
||||
* **ScoView** : Voir
|
||||
* **UsersAdmin** : Gérer les utilisateurs (de son département)
|
||||
* **UsersChangeCASId** : Paramétrer l'id CAS
|
||||
* **UsersView** : Voir les utilisateurs (de tous les départements)
|
||||
|
||||
### Liste des permissions Zope
|
||||
## Rôles
|
||||
|
||||
Les permissions utilisées par ScoDoc ont des noms qui commencent par "Sco", de façon à les grouper dans l'interface de Zope (ZMI), qui est peu pratique.
|
||||
Les rôles peuvent êtres associés à un nombre quelconque de permissions.
|
||||
|
||||
Pour changer ces permissions (plus précisément pour associer les permissions à des rôles), aller dans l'onglet "Security" du dossier "Dept" (celui qui *contient* l'instance de ScoDoc, habituellement nommée "Scolarite").
|
||||
ScoDoc définit un certain nombre de rôles *standards* (`Ens`, `Secr`, ...) mais
|
||||
l'administrateur peut facilement définir de nouveaux rôles et leur associer un
|
||||
ensemble de permissions.
|
||||
|
||||
Voici les permissions utilisées:
|
||||
## Gestion des utilisateurs
|
||||
|
||||
* **Sco View** : voir les pages de ScoDoc (à réserver aux enseignants et administratifs)
|
||||
|
||||
* **Sco View Ens** : voir les parties réservées aux enseignants (à l'exclusion des secrétariats)
|
||||
|
||||
* **Sco Modifier toutes notes** : modifier toutes les notes (dans tous les semestres)
|
||||
|
||||
* **Sco Modifier toutes les evaluations** : créer/modifier/supprimer des évaluations dans tous les semestres (mais pas saisir des notes)
|
||||
|
||||
* **Sco Change Formation** : créer/modifier/supprimer des formations (programmes pédagogiques)
|
||||
|
||||
* **Sco Implement Formation** : mettre en place des semestres (sessions) de formation
|
||||
|
||||
* **Sco Change Absences** : saisir des absences
|
||||
|
||||
* **Sco Change Etud Address** : changer les adresses des étudiants
|
||||
|
||||
* **Sco Change Etud Groups** : changer les groupes des étudiants
|
||||
|
||||
* **Sco Inscrire Etud** : inscrire des étudiants
|
||||
|
||||
* **Sco Etud Add Annotations** : ajouter des annotations sur les étudiants
|
||||
|
||||
* **Sco View Entreprises** : accéder au fichier d'entreprises
|
||||
|
||||
* **Sco Change Entreprises** : modifier le fichier d'entreprises
|
||||
|
||||
* **Sco Users Admin** : voir et modifier les utilisateurs ScoDoc
|
||||
|
||||
* **Sco Users View** : voir les utilisateurs ScoDoc
|
||||
|
||||
* **Sco Change Preferences** : modifier les préférences du département
|
||||
|
||||
* **Sco Super Admin** : réservé à l'administrateur (création de départements)
|
||||
|
||||
Pour la liste à jour des permissions et leur nom complet, et les associations initiales rôles/permissions, voir le fichier `sco_permissions.py` dans les sources.
|
||||
|
||||
|
||||
### Rôles associés à chaque permission dans chaque département
|
||||
Les rôles listés ici sont ceux définis dans chaque département (`Admin` réfère donc à l'`AdminXXX` du département `XXX`, à ne pas confondre avec l'utilisateur `admin`).
|
||||
|
||||
Permission | Rôles... | | |
|
||||
-----------------------------|--------------|--------|---------|
|
||||
**`ScoView`** | `Ens` | `Secr` | `Admin` |
|
||||
**`ScoEnsView`** | `Ens` | | `Admin` |
|
||||
**`ScoUsersView`** | `Ens` | `Secr` | `Admin` |
|
||||
**`ScoEtudAddAnnotations`** | `Ens` | `Secr` | `Admin` |
|
||||
**`ScoAbsChange`** | `Ens` | `Secr` | `Admin` |
|
||||
**`ScoEntrepriseView`** | `Ens` | `Secr` | `Admin` |
|
||||
**`ScoEntrepriseChange`** | | `Secr` | `Admin` |
|
||||
**`ScoEtudChangeAdr`** | | `Secr` | `Admin` |
|
||||
**`ScoChangeFormation`** | | | `Admin` |
|
||||
**`ScoEditAllNotes`** | | | `Admin` |
|
||||
**`ScoEditAllEvals`** | | | `Admin` |
|
||||
**`ScoImplement`** | | | `Admin` |
|
||||
**`ScoEtudChangeGroups`** | | | `Admin` |
|
||||
**`ScoEtudInscrit`** | | | `Admin` |
|
||||
**`ScoUsersAdmin`** | | | `Admin` |
|
||||
**`ScoChangePreferences`** | | | `Admin` |
|
||||
|
||||
|
||||
## Gestion des utilisateurs
|
||||
Les utilisateurs sont associés à un département principal et à des rôles.
|
||||
|
||||
Le fait d'être, ou non, associé à un département est important:
|
||||
* pour tous les utilisateurs: hormis le SuperAdmin, seuls les administrateurs du département d'appartenance sont habilités à modifier les caractéristiques principales (nom, prenom, email, mot de passe) de cet utilsateur
|
||||
* pour les responsables (rôle `AdminXXX`. En effet, si le responsable est associé à un département, *il ne pourra créer des utilisateurs que dans ce département*
|
||||
(c'est en général ce qu'on veut pour un chef de département, qui "recrute" des enseignant uniquement dans son département).
|
||||
|
||||
Pour la gestion des rôles, l'administrateur d'un département peut ajouter ou supprimer les rôles *de ce département* à n'importe quel utilisateur, y compris à ceux qui ne sont pas du même département
|
||||
* pour tous les utilisateurs: hormis le SuperAdmin, seuls les administrateurs du
|
||||
département d'appartenance sont habilités à modifier les caractéristiques
|
||||
principales (nom, prenom, email, mot de passe) de cet utilisateur.
|
||||
* pour les responsables (rôle `Admin_XXX`). En effet, si le responsable est
|
||||
associé à un département, *il ne pourra créer des utilisateurs que dans ce
|
||||
département* (c'est en général ce qu'on veut pour un chef de département, qui
|
||||
"recrute" des enseignant uniquement dans son département).
|
||||
|
||||
Exemple: si PAUL est du département GEII et a les rôles AdminGEII et AdminCJ
|
||||
* Il pourra créer des utilisateurs uniquement dans le département GEII
|
||||
* il pourra ajouter ou retirer les rôles EnsGEII, SecrGEII, AdminGEII à tout utilisateur de scodoc
|
||||
* il pourra ajouter ou retirer les rôles EnsCJ, SecrCJ, AdminCJ à tout utilisateur de scodoc
|
||||
Pour la gestion des rôles, l'administrateur d'un département peut ajouter ou
|
||||
supprimer les rôles *de ce département* à n'importe quel utilisateur, y compris
|
||||
à ceux qui ne sont pas du même département.
|
||||
|
||||
Exemple: si Paul est du département GEII et a les rôles `Admin_GEII` et `Admin_CJ`
|
||||
|
||||
* Il pourra *créer* des utilisateurs *uniquement dans son département d'origine*, GEII;
|
||||
* Il pourra ajouter ou retirer les rôles `Ens_GEII`, `Secr_GEII`, `Admin_GEII` à tout
|
||||
utilisateur de ScoDoc;
|
||||
* Il pourra ajouter ou retirer les rôles `Ens_CJ`, `Secr_CJ`, `Admin_CJ` à tout
|
||||
utilisateur de ScoDoc.
|
||||
|
||||
Plus d'informations techniques sur la page [AdminUsers](AdminUsers.md).
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Introduction aux rôles et permissions](ConfigPermissionsDept.md)
|
||||
- [Gestion des utilisateurs](AdminUsers.md)
|
||||
- [Config. des rôles et permissions en ligne de commande](GuideConfig.md#creation-dun-nouveau-role)
|
||||
- [Guide administrateur ScoDoc](GuideAdminSys.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
@ -1,14 +1,12 @@
|
||||
# Rôles et permissions dans ScoDoc
|
||||
|
||||
ScoDoc défini par défaut quatre rôles principaux (d'autres sont prévus,
|
||||
notamment pour le module relations entreprises):
|
||||
|
||||
ScoDoc défini par défaut quatre rôles principaux (d'autres sont prévus, notamment pour le module
|
||||
relations entreprises):
|
||||
|
||||
- Administrateur
|
||||
- Secrétariat
|
||||
- Enseignant
|
||||
- Observateur
|
||||
|
||||
* Administrateur
|
||||
* Secrétariat
|
||||
* Enseignant
|
||||
* Observateur
|
||||
|
||||
Par ailleurs, le contexte d'utilisation donne certains privilèges (par exemple
|
||||
la faculté de saisir des notes, de justifier des absences, de modifier la
|
||||
@ -16,16 +14,15 @@ définition des programmes, ...).
|
||||
|
||||
## Exemple
|
||||
|
||||
L'utilisateur 'Dupont' est responsable ScoDoc pour son département *RT* mais
|
||||
intervient également en enseignement au département *GEII*.
|
||||
On pourra lui attribuer les rôles `AdminRT` et `EnsGEII`, ce qui lui permettra :
|
||||
L'utilisateur *Dupont* est responsable ScoDoc pour son département *RT* mais
|
||||
intervient également en enseignement au département *GEII*. On pourra lui
|
||||
attribuer les rôles `Admin_RT` et `Ens_GEII`, ce qui lui permettra :
|
||||
|
||||
- de gérer les utilisateurs du (seul) département RT :
|
||||
Privilèges associés : `Gérer les utlisateurs (Sco Users Manage)`, `Changer les
|
||||
formations (Sco Change Formation)`, ...
|
||||
- d'accéder aux vues enseignant pour le département GEII :
|
||||
Privilèges associés : `Voir les parties pour les enseignants (Sco View Ens)`,
|
||||
`Saisir des absences (Sco Change Absences)`, ...
|
||||
* de gérer les utilisateurs du (seul) département RT :
|
||||
Privilèges associés : `Gérer les utilisateurs`, `Changer les formations`, ...
|
||||
* d'accéder aux vues enseignant pour le département GEII :
|
||||
Privilèges associés : `Voir les parties pour les enseignants`,
|
||||
`Saisir des absences`, ...
|
||||
|
||||
Pour une description plus fine des permissions, voir
|
||||
[ConfigPermissions](ConfigPermissions.md).
|
||||
@ -34,34 +31,52 @@ Pour une description plus fine des permissions, voir
|
||||
|
||||
`XXX` désigne typiquement le nom du département ("RT" ou "GEA").
|
||||
|
||||
* `AdminXXX`: toutes opérations ScoDoc (chef de département, et éventuellement un ou deux collaborateurs de confiance);
|
||||
* `Admin_XXX`: toutes opérations ScoDoc (chef de département, et éventuellement
|
||||
un ou deux collaborateurs de confiance);
|
||||
|
||||
* `EnsXXX`: enseignant du département;
|
||||
* `Ens_XXX`: enseignant du département;
|
||||
|
||||
* `SecrXXX`: secrétaire du département.
|
||||
* `Secr_XXX`: secrétaire du département.
|
||||
|
||||
L'installation standard défini aussi un utilisateur "*admin*", qui a le rôle "Manager", ce qui lui confère normalement tous les droits sur toutes les parties du site. L'usage de cet utilisateur particulier devrait être réduit à la création de nouveaux départements, et son mot de passe ne devrait pas être divulgué aux utilisateurs de ScoDoc.
|
||||
L'installation standard défini aussi un utilisateur "*admin*", qui a le rôle
|
||||
"Manager", ce qui lui confère normalement tous les droits sur toutes les parties
|
||||
du site. L'usage de cet utilisateur particulier devrait être réduit à la
|
||||
création de nouveaux départements, et son mot de passe ne devrait pas être
|
||||
divulgué aux utilisateurs de ScoDoc.
|
||||
|
||||
Les utilisateurs sont associés à des rôles et à un (et un seul) département principal.
|
||||
Les utilisateurs sont associés à des rôles et à un (et un seul) département
|
||||
principal.
|
||||
|
||||
Un utilisateur peut avoir un nombre quelconque de rôles dans différents départements.
|
||||
Un utilisateur peut avoir un nombre quelconque de rôles dans différents
|
||||
départements.
|
||||
|
||||
Le département de rattachement est utile pour indiquer qui (quel administrateur) a le droit de modifier l'utilisateur (lui changer son mot de passe, etc), mais n'influe pas sur les permissions accordées à l'utilisateur (sauf pour les administrateurs).
|
||||
Le département de rattachement est utile pour indiquer qui (quel administrateur)
|
||||
a le droit de modifier l'utilisateur (lui changer son mot de passe, etc), mais
|
||||
n'influe pas sur les permissions accordées à l'utilisateur (sauf pour les
|
||||
administrateurs).
|
||||
|
||||
Le fait d'être, ou non, associé à un département est important pour les responsables (rôle `AdminXXX`. En effet, si le responsable est associé à un département, il ne pourra créer des utilisateurs que dans ce département (c'est en général ce qu'on veut pour un chef de département, qui "recrute" des enseignant uniquement dans son département).
|
||||
Le fait d'être, ou non, associé à un département est important pour les
|
||||
responsables (rôle `Admin_XXX`. En effet, si le responsable est associé à un
|
||||
département, il ne pourra créer des utilisateurs que dans ce département (c'est
|
||||
en général ce qu'on veut pour un chef de département, qui "recrute" des
|
||||
enseignant uniquement dans son département).
|
||||
|
||||
## Permissions dépendantes du contexte
|
||||
|
||||
Outre les rôles associés à chaque utilisateur, le calcul des autorisations dépend du contexte de l'opération. Par exemple, un responsable de semestre a des droits particulier sur ce semestre, ou encore un responsable de module sur la saisie des notes dans ce module.
|
||||
Outre les rôles associés à chaque utilisateur, le calcul des autorisations
|
||||
dépend du contexte de l'opération. Par exemple, un responsable de semestre a des
|
||||
droits particulier sur ce semestre, ou encore un responsable de module sur la
|
||||
saisie des notes dans ce module.
|
||||
|
||||
### Qui peut saisir des notes ?
|
||||
### Qui peut saisir des notes ?
|
||||
|
||||
Peuvent saisir des notes dans une évaluation située dans un module:
|
||||
|
||||
* le ou les administrateurs (rôle `AdminXXX`, où `XXX` est le département);
|
||||
* le ou les administrateurs (rôle `Admin_XXX`, où `XXX` est le département);
|
||||
* le responsable du semestre (directeur des études);
|
||||
* le responsable du module;
|
||||
* les enseignants "associés" au module (en général des collègues désignés par le responsable de module ou le directeur des études).
|
||||
* les enseignants "associés" au module (en général des collègues désignés par le
|
||||
responsable de module ou le directeur des études).
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
|
@ -5,16 +5,16 @@ Quelques indications pour développer avec ScoDoc, à adapter à vos goûts et o
|
||||
Commencez par lire
|
||||
[Installation du code pour les développeurs](https://scodoc.org/git/ScoDoc/ScoDoc#pour-les-d%C3%A9veloppeurs)
|
||||
|
||||
# Machine virtuelle
|
||||
## Machine virtuelle
|
||||
|
||||
Il est confortable de développer dans une VM (un container Docker ferait
|
||||
aussi bien l'affaire).
|
||||
|
||||
## Conseils pour la machine virtuelle
|
||||
### Conseils pour la machine virtuelle
|
||||
|
||||
[VirtualBox](https://www.virtualbox.org/) est facile à installer sur Linux ou
|
||||
Windows. Créer une VM avec Debian 10, et suivre la [procédure habituelle
|
||||
d'installation de ScoDoc](GuideInstallDebian11.md).
|
||||
Windows. Créer une VM avec Debian 12, et suivre la
|
||||
[procédure habituelle d'installation de ScoDoc](GuideInstallDebian12.md).
|
||||
|
||||
Sur les Macs anciens (processeurs Intel), VirtualBox fonctionne bien. Sur les
|
||||
modèles "M1" (Apple Silicon), je conseille d'utiliser
|
||||
@ -70,9 +70,10 @@ la VM:
|
||||
|
||||
ici `enp0s8` correspond à l'`Adapter 2`. Si vous travaillez sur une machine fixe
|
||||
avec connexion permanente, vous pouvez dans Debian activer cette interface
|
||||
constamment (modifier `/etc/network/interfaces`).
|
||||
constamment (modifier `/etc/network/interfaces`).
|
||||
|
||||
### Noms des machines
|
||||
|
||||
Modifier le `/etc/hosts` (ou équivalent) de l'hôte, et y ajouter l'IP de votre
|
||||
VM, par exemple (adapter l'IP !):
|
||||
|
||||
@ -80,7 +81,19 @@ VM, par exemple (adapter l'IP !):
|
||||
|
||||
### Partage de fichiers
|
||||
|
||||
Pour éditer votre code au chaud sur votre hôte, il y a plein de solutions.
|
||||
Pour éditer votre code au chaud sur votre hôte, il y a plein de solutions.
|
||||
La plus simple, déjà mentionnée, consiste à passer par une connexion SSH (VS
|
||||
Code propose un module dédié très simple et performant, mais tout montage de
|
||||
type `sshfs`peut aussi faire l'affaire).
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Conventions de codage](DevConventions.md)
|
||||
- [API ScoDoc 9](ScoDoc9API.md)
|
||||
- [Guide installation](GuideInstallDebian12.md)
|
||||
- [Gestion des utilisateurs](AdminUsers.md)
|
||||
- [Guide administrateur ScoDoc](GuideAdminSys.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
||||
-
|
@ -33,7 +33,7 @@ permet d'indiquer le semestre et l'étudiant à regarder.
|
||||
|
||||
Vous trouverez les sources du projet, les tickets (*issues*) et autres outils sur
|
||||
|
||||
* [gitea](https://scodoc.org/git/)
|
||||
* [gitea](https://git.scodoc.org)
|
||||
|
||||
Vous pouvez demander un compte sur cette plate-forme pour ajouter des tickets,
|
||||
proposer votre code (*pull requests*).
|
||||
|
@ -7,7 +7,7 @@ collègues, ou en développant ou testant le logiciel.
|
||||
|
||||
Les canaux de communication entre développeurs sont
|
||||
[indiqués sur cette page](Contact.md). Vous pouvez demander un compte sur le [git du
|
||||
projet](https://scodoc.org/git), consulter/ajouter des tickets, proposer votre
|
||||
projet](https://git.scodoc.org), consulter/ajouter des tickets, proposer votre
|
||||
code (*pull requests*).
|
||||
|
||||
## Contribuer à la documentation
|
||||
@ -21,11 +21,11 @@ La documentation est constituée de deux parties:
|
||||
- Les pages Web comme celle que vous lisez actuellement. La documentation est
|
||||
générée via `MkDocs`, un système très simple basé sur le format
|
||||
[Markdown](https://www.markdownguide.org/basic-syntax/). Toutes les sources
|
||||
sont sur le [dépôt git DocScoDoc](https://scodoc.org/git/viennet/DocScoDoc).
|
||||
sont sur le [dépôt git DocScoDoc](https://git.scodoc.org/viennet/DocScoDoc).
|
||||
|
||||
## Contribuer au logiciel
|
||||
|
||||
Le [dépôt principal](https://scodoc.org/git/viennet/ScoDoc) comporte plusieurs
|
||||
Le [dépôt principal](https://git.scodoc.org/viennet/ScoDoc) comporte plusieurs
|
||||
branches. Voir le [guide pour les développeurs](GuideDeveloppeurs.md).
|
||||
|
||||
|
||||
|
@ -6,9 +6,11 @@ Dans ScoDoc, les permissions sont liées à des rôles. Un utilisateur a un ou p
|
||||
rôles, dans un ou tous les départements (si le département est null, on
|
||||
considère que le rôle est donnés dans tous les départements).
|
||||
|
||||
Dans ScoDoc Web, toutes les routes sont liées à des départements
|
||||
Dans ScoDoc Web, toutes les routes sont liées à des départements
|
||||
|
||||
```txt
|
||||
/ScoDoc/<str:dept_acronym>/Scolarite/
|
||||
```
|
||||
|
||||
sauf la page d'accueil (`/ScoDoc/index`), les pages de configuration générale
|
||||
(`ScoDoc/configuration`) et les pages "entreprises" (`ScoDoc/entreprises/`).
|
||||
@ -19,6 +21,7 @@ et peuvent se retrouver dans plusieurs départements, notamment en cas de
|
||||
transfert d'un étudiant d'un département à un autre).
|
||||
|
||||
## Contrôle des permissions par l'API et départements
|
||||
|
||||
Ainsi, une route API comme `/partition/<int:partition_id>` n'est pas ambigüe.
|
||||
Toutefois, ScoDoc doit déterminer si l'utilisateur a le droit d'accéder (ou de
|
||||
modifier) cet objet. Pour cela, ScoDoc a besoin de connaitre le département.
|
||||
@ -28,7 +31,8 @@ relation avec `formsemestre`, lui même lié à son département: on écrit
|
||||
|
||||
Cependant, le contrôle de l'accès est plus facile à exprimer (donc plus sûr,
|
||||
moins de risque d'erreurs) avec un décorateur: on écrit typiquement les vues:
|
||||
```
|
||||
|
||||
```py
|
||||
@permission_required(Permission.ScoView)
|
||||
def ma_vue( arg ):
|
||||
...
|
||||
@ -36,32 +40,38 @@ def ma_vue( arg ):
|
||||
|
||||
Comme nous l'avons dit, pour les vues Web (voir sources dans `app/view/*.py`),
|
||||
le département est dans la route (URL): ainsi le tableau de bord d'un
|
||||
fomsemestre est
|
||||
```
|
||||
formsemestre est
|
||||
|
||||
```txt
|
||||
ScoDoc/<str:dept_acronym>/Scolarite/Notes/formsemestre_status
|
||||
```
|
||||
|
||||
La vue s'écrit
|
||||
```
|
||||
```py
|
||||
@bp.route("/formsemestre_status")
|
||||
@scodoc
|
||||
@permission_required(Permission.ScoView)
|
||||
def formsemestre_status(formsemestre_id:int):
|
||||
...
|
||||
```
|
||||
|
||||
Le décorateur `scodoc` (défini dans `app/scodoc/decorators.py`) récupère le
|
||||
département présent dans la route et affecte deux attributs dans la requête
|
||||
```
|
||||
département présent dans la route et affecte deux attributs dans la requête
|
||||
|
||||
```py
|
||||
g.scodoc_dept = "RT" # l'acronyme du dept
|
||||
g.scodoc_dept_id = 5 # l'id du dept
|
||||
```
|
||||
|
||||
Le décorateur suivant, `permission_required` peut ainsi vérifier que la
|
||||
permission est bien accordée dans ce département.
|
||||
permission est bien accordée dans ce département.
|
||||
|
||||
Pour l'API, on a deux routes:
|
||||
```
|
||||
|
||||
```py
|
||||
/ScoDoc/api/partition/<int:partition_id>
|
||||
```
|
||||
|
||||
Dans ce cas, le décorateur `scodoc` ne récupère pas de département
|
||||
(`g.scodoc_dept`est mis à `None`), et `permission_required`exige alors que la
|
||||
permission soit accordé dans *tous les départements* (`dept`à `None`).
|
||||
@ -69,27 +79,34 @@ permission soit accordé dans *tous les départements* (`dept`à `None`).
|
||||
Lorsque l'API est utilisée depuis une vue web de ScoDoc, donc par un utilisateur
|
||||
ordinaire n'ayant de rôles que dans son (ou ses) départements, ce mécanisme
|
||||
échoue. On propose donc une autre route, de la forme
|
||||
```
|
||||
|
||||
```txt
|
||||
/ScoDoc/<str:dept_acronym>/api/partition/<int:partition_id>
|
||||
```
|
||||
|
||||
Les décorateurs fonctionnent alors bien.
|
||||
|
||||
## Écriture d'une vue API
|
||||
|
||||
Il reste à la charge des fonctions de l'API d'effectuer la vérification que les
|
||||
objets demandés sont bien dans le département donné par la route (point de
|
||||
vigilance: risque de fuite de données si mal codé). Dans la plupart des cas, il
|
||||
faut pour cela ajouter une jointure. par exemple, pour demander une partition,
|
||||
on écrira non pas
|
||||
```
|
||||
|
||||
```py
|
||||
p = Partition.query.get(partition_id)
|
||||
```
|
||||
|
||||
mais plutôt
|
||||
```
|
||||
|
||||
```py
|
||||
p = Partition.query.filter_by(id=partition_id).join(FormSemestre).filter_by(dept_id=g.scodoc_dept_id)
|
||||
```
|
||||
|
||||
Écriture d'une vue de l'API accessible en mode web et API:
|
||||
```
|
||||
|
||||
```py
|
||||
@api_bp.route("/api_function/<int:arg>")
|
||||
@api_web_bp.route("/api_function/<int:arg>")
|
||||
@login_required
|
||||
@ -103,11 +120,11 @@ def api_function(arg: int):
|
||||
## Fonctionnement interne du contrôle d'accès ScoDoc
|
||||
|
||||
Les accès ScoDoc sont gérés avec `flask-login`. L'authentification est faite
|
||||
soit par un cookie de session (web), soit par un jeton jwt (API).
|
||||
soit par un cookie de session (web), soit par un jeton `jwt` (API).
|
||||
|
||||
Ce décodage/contrôle est fait par la fonction
|
||||
Ce décodage/contrôle est fait par la fonction
|
||||
`app.auth.logic.load_user_from_request()`.
|
||||
|
||||
En cas de refus (jeton ou cookie absent ou invalide), on a une redirection vers
|
||||
la page de login (en mode web), ou un message d'erreur JSON 401 pour l'API
|
||||
(voir `app.auth.logic.unauthorized_handler`).
|
||||
(voir `app.auth.logic.unauthorized_handler`).
|
||||
|
107
docs/DevAbsencesCalendrier.md
Normal file
107
docs/DevAbsencesCalendrier.md
Normal file
@ -0,0 +1,107 @@
|
||||
# Absences et emplois du temps (développeurs)
|
||||
|
||||
Notes/idées pour les développeurs. WIP, en vrac.
|
||||
|
||||
## Calendriers et évènements
|
||||
|
||||
Un calendrier est ici une liste d'évènements, chaque cours étant un évènement. L'évènement
|
||||
comporte:
|
||||
|
||||
- dates début et fin;
|
||||
- identifiant du groupe d'étudiants concerné (dans la formation, par ex. groupe
|
||||
de TD);
|
||||
- identifiant du module (enseignement): par exemple, l'élément Apogée.
|
||||
- identifiant de l'enseignant concerné.
|
||||
|
||||
On suppose qu'on a un calendrier par "formation" (`FormSemestre` ScoDoc),
|
||||
identifié par un code (par exemple, code étape Apogée) que l'on appellera `edt_id`.
|
||||
|
||||
### Exemple: cas de l'USPN
|
||||
|
||||
Cet établissement utilise HyperPlanning. Les calendrier sont exportés
|
||||
régulièrement, on a un fichier ics par formation (code Apogée).
|
||||
|
||||
```ics
|
||||
BEGIN:VEVENT
|
||||
CATEGORIES:HYPERPLANNING
|
||||
DTSTAMP:20231101T140300Z
|
||||
LAST-MODIFIED:20230905T094241Z
|
||||
UID:Cours-423101-5-BUT2_RT_pa._CYBER-Index-Education
|
||||
DTSTART:20230920T060000Z
|
||||
DTEND:20230920T083000Z
|
||||
SUMMARY;LANGUAGE=fr:TP2 GPR1 - VCYR303 - Services reseaux ava (VCYR303) - 1234 - M. VIENNET EMMANUEL - V2ROM - BUT2 RT pa. ROM - Groupe 1
|
||||
LOCATION;LANGUAGE=fr:P202 CRIT - P202 CRIT.RESEAUX
|
||||
DESCRIPTION;LANGUAGE=fr:Matière : VCYR303 - Services reseaux ava (VCYR303)\nEnseignant : 1234 - M. VIENNET EMMANUEL\nPromotion : V2ROM - BUT2 RT pa. ROM\nTD : Groupe 1\nSalle : P202 CRIT - P202 CRIT.RESEAUX\nMémo : TP2 GPR1\n
|
||||
X-ALT-DESC;FMTTYPE=text/html:Matière : VCYR303 - Services reseaux ava (VCYR303)<br/>Enseignant : 1234 - M. VIENNET EMMANUEL<br/>Promotion : V2ROM - BUT2 RT pa. ROM<br/>TD : Groupe 1<br/>Salle : P202 CRIT - P202 CRIT.RESEAUX<br/>Mémo : TP2 GPR1<br/>
|
||||
END:VEVENT
|
||||
```
|
||||
|
||||
On a ici:
|
||||
|
||||
- identifiant de la formation: dans le nom du fichier calendrier (ici `V2CYB.ics`);
|
||||
- identifiant du groupe: dans `SUMMARY`, `* - <groupe>`
|
||||
- identifiant du module: on a le code `VCYR303` à trois endroits: `SUMMARY`,
|
||||
`DESCRIPTION`, `X-ALT-DESC`.
|
||||
- identifiant de l'enseignant: `SUMMARY`, `DESCRIPTION`, `X-ALT-DESC`.
|
||||
|
||||
## Transcodage des identifiants
|
||||
|
||||
ScoDoc n'utilise évidemment pas les mêmes identifiants que ceux trouvés dans les
|
||||
calendriers.
|
||||
|
||||
### "Formation"
|
||||
|
||||
Il s'agit du `FormSemestre`. On a déjà les codes étapes Apogée. On
|
||||
proposera un champs "identifiant emploi du temps" (`edt_id`), et à défaut on
|
||||
utilisera le premier code étape Apogée.
|
||||
|
||||
### Groupes
|
||||
|
||||
Chaque groupe ScoDoc peut indiquer son ou ses identifiants edt (`edt_id`). A défaut, on
|
||||
utilisera son nom (il sera donc conseillé aux utilisateurs d'adopter les mêmes
|
||||
noms de groupes dans ScoDoc et dans leur logiciel d'emploi du temps).
|
||||
|
||||
### Module
|
||||
|
||||
Ajouter `etd_id` dans `Module`, avec utilisation de `code_apogee` si absent.
|
||||
|
||||
### Enseignant
|
||||
|
||||
`edt_id` (dans l'exemple précédent `"1234"`), doit être renseigné dans ScoDoc. A
|
||||
l'USPN, on peut récupérer cette information dans le CAS (dans `supannEmpId` et
|
||||
`employeeNumber`).
|
||||
|
||||
Champ `edt_id` dans `User`. Affecté par l'authentification CAS, qui peut
|
||||
récupérer une information dans la réponse XML du serveur CAS, grâce à
|
||||
l'expression `cas_edt_id_from_xml_regexp` de la config générale. SuperAdmin peut
|
||||
aussi forcer manuellement l'`edt_id` des comptes utilisateurs.
|
||||
|
||||
## Architecture technique
|
||||
|
||||
### Principes généraux
|
||||
|
||||
- ScoDoc consomme la donnée "emploi du temps" mais n'a pas vocation à la
|
||||
republier (on ne proposera aucune API pour ce faire, les clients intéressés
|
||||
devant s'adresser à l'API (ou équivalent) du logiciel d'emplois du temps).
|
||||
|
||||
- ScoDoc est agnostique sur le logiciel d'emploi du temps et n'effectue aucune
|
||||
requête API vers celui-ci. Il se contente de consommer des calendriers (ics) copiés
|
||||
(par exemple chaque heure) dans un répertoire accessible au serveur ScoDoc.
|
||||
|
||||
- Chaque `FormSemestre` va chercher à s'associer à un (et un seul ?) calendrier.
|
||||
|
||||
## Fonctions proposées aux utilisateurs
|
||||
|
||||
L'objectif est de simplifier la saisie des absences: afficher l'emploi du temps
|
||||
par semaine, et permettre la saisie des absences d'un cours donné en ayant
|
||||
automatiquement pré-rempli le module, la date, l'heure de début et l'heure de
|
||||
fin.
|
||||
|
||||
En option, restreindre la saisie des absences par les enseignants aux seules
|
||||
plages/groupes qui les concernent.
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- Emplois du temps: [doc utilisateur](EmploisDuTemps.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
272
docs/DevConventions.md
Normal file
272
docs/DevConventions.md
Normal file
@ -0,0 +1,272 @@
|
||||
# Conventions de codage pour ScoDoc
|
||||
|
||||
Le projet étant très ancien, le code est passé par différentes conventions et
|
||||
frameworks. Le style de python et celui du _frontend_ web ont considérablement
|
||||
évolués ces dernières décennies.
|
||||
|
||||
Pour les nouveaux codes, respecter les principes suivants:
|
||||
|
||||
- ScoDoc est avant tout une application serveur écrite en Python, qui offre des
|
||||
services via une interface Web, une API, et accessoirement la ligne de
|
||||
commande unix.
|
||||
|
||||
- Les pages Web générées doivent l'être en Python côté serveur. On peut utiliser
|
||||
du JS pour les pages dynamiques complexes (eg éditeur de partition) mais
|
||||
éviter d'utiliser du JS pour générer des éléments statiques: l'abus de JS
|
||||
conduit à dupliquer du code (qui existe en général dans le serveur) et
|
||||
augmente les coûts de maintenance.
|
||||
|
||||
## Conventions de codage
|
||||
|
||||
### Formatage du code
|
||||
|
||||
- l'usage de **[black](https://black.readthedocs.io/en/stable/)** est obligatoire
|
||||
- l'usage de pylint et mypy est fortement recommandé
|
||||
- Pour le code JS, indentation avec 2 espaces (sous VS Code, utiliser _Prettier_).
|
||||
|
||||
### Conventions standard Python
|
||||
|
||||
On se tient à la PEP8, c'est à dire en résumé:
|
||||
`UneClasse`, `une_fonction`, `_une_fonction_privee`, `une_variable`, `UNE_CONSTANTE_GLOBALE`.
|
||||
|
||||
Les noms de fichiers sont en minuscules sans accents ni espaces, `comme_ceci.py`.
|
||||
|
||||
### Annotations de type (typehints)
|
||||
|
||||
On annote les paramètres et résultats des fonctions.
|
||||
|
||||
```py
|
||||
def _upload_justificatif_files(
|
||||
just: Justificatif, form: AjoutJustificatifEtudForm
|
||||
) -> bool:
|
||||
...
|
||||
```
|
||||
|
||||
## Pages et templates
|
||||
|
||||
Les vues utilisent un template _Jinja2_, fichier avec extension j2.
|
||||
|
||||
On s'astreint, sauf cas particulier, à un nommage identique de la route, la vue et du template.
|
||||
|
||||
```py
|
||||
@bp.route("/un_exemple")
|
||||
def un_exemple(...):
|
||||
...
|
||||
return render_template(".../un_exemple.j2")
|
||||
```
|
||||
|
||||
Le template aura typiquement avec la structure suivante:
|
||||
|
||||
```jinja
|
||||
{% extends "sco_page.j2" %}
|
||||
|
||||
{% block app_content %}
|
||||
<h1>Titre</h1>
|
||||
{% endblock app_content %}
|
||||
```
|
||||
|
||||
Pour les pages dans un semestre (avec barre menu etc.), on utilisera `<h2>` au
|
||||
lieu de `<h1>`.
|
||||
|
||||
### Templates habituels
|
||||
|
||||
Les templates suivants sont les plus utilisés pour les pages:
|
||||
|
||||
- `base.j2` pages hors département (accueil, configuration, ...)
|
||||
|
||||
- `sco_page.j2` page standard dans un formsemestre: avec sidebar et barre de
|
||||
menu du semestre. Le contenu de la variable `content` est placé comme HTML
|
||||
brut (_safe_) dans la partie contenu. Passer `sco=ScoData(formsemestre=formsemestre)`
|
||||
en argument au template.
|
||||
|
||||
- `sco_page_dept.j2` page dans un département (avec sidebar) mais sans formsemestre (pas de
|
||||
barre de menu)
|
||||
|
||||
### Constantes définies dans les templates ScoDoc
|
||||
|
||||
Le `context_processor` `inject_sco_utils()` ajoute des objets pour accès à tous
|
||||
les templates ScoDoc:
|
||||
|
||||
- `scu` : le module `sco_utils.py` (diverses fonctions utilitaires et variables
|
||||
de config.)
|
||||
- `sco` : des données sur le contexte, notamment les préférences, le
|
||||
formsemestre et l'étudiant courants (resp. `sco.formsemestre` et `sco.etud`)
|
||||
|
||||
### Appel d'un template page
|
||||
|
||||
Pour mémoire, l'appel d'un template dans une vue se fait ainsi:
|
||||
|
||||
```py
|
||||
render_template( "votre_template.j2",
|
||||
title="Changer de référentiel de compétences",
|
||||
autre_variable=...
|
||||
)
|
||||
```
|
||||
|
||||
### Passage des anciennes pages ScoDoc 7 aux templates Jinja
|
||||
|
||||
Les anciennes pages étaient générées en python selon la structure:
|
||||
|
||||
```py
|
||||
html_sco_header.sco_header(
|
||||
cssstyles=["css/....css"],
|
||||
javascripts=[
|
||||
"js/....js",
|
||||
],
|
||||
page_title="titre de la page",
|
||||
)
|
||||
... contenu ...
|
||||
html_sco_header.sco_footer()
|
||||
```
|
||||
|
||||
La migration la plus simple consiste à utilise `sco_page.j2`:
|
||||
|
||||
```py
|
||||
render_template(
|
||||
"sco_page.j2",
|
||||
content=contenu,
|
||||
title="titre de la page",
|
||||
cssstyles=["..."],
|
||||
javascripts=["..."],
|
||||
)
|
||||
```
|
||||
|
||||
Mais si on souhaite générer le contenu dans un template, cela prendra la forme:
|
||||
|
||||
```jinja-html
|
||||
{% extends "sco_page.j2" %}
|
||||
|
||||
{% block title %}
|
||||
...titre...
|
||||
{% endblock title %}
|
||||
|
||||
{% block styles %}
|
||||
{{ super() }}
|
||||
<link rel="stylesheet" href="{{scu.STATIC_DIR}}/css/un_style_scodoc.css">
|
||||
<style>
|
||||
... styles locaux ...
|
||||
</style>
|
||||
{% endblock styles %}
|
||||
|
||||
{% block app_content %}
|
||||
<div class="pageContent">
|
||||
<h2>titre page</h2>
|
||||
... contenu ...
|
||||
</div>
|
||||
{% endblock %}
|
||||
|
||||
{% block scripts %}
|
||||
{{ super() }}
|
||||
<script src="{{scu.STATIC_DIR}}/js/un_script_scodoc.js"></script>
|
||||
<script>
|
||||
... script js local ...
|
||||
</script>
|
||||
{% endblock %}
|
||||
```
|
||||
|
||||
### Classes css
|
||||
|
||||
`scodoc.css` (et à partir de 9.7, `scodoc97.css`) définissent quelques classes à usage général:
|
||||
|
||||
- `div.scobox`: boite (bords arrondis, fond uni) regroupant des éléments.
|
||||
|
||||
- `div.scobox-title` le titre de la boite
|
||||
- `div.scobox-buttons` boutons en bas de boite.
|
||||
|
||||
- `p.help`, `div.help`: explications, aide.
|
||||
- ...
|
||||
|
||||
## Accès à la base de donnée
|
||||
|
||||
Sauf exception (requêtes exotiques, problèmes de performance) à discuter, les
|
||||
accès à la base se font à travers l'ORM _SQLAlchemy_. Les modèles sont définis
|
||||
dans `app/models`, sauf les comptes utilisateurs qui sont dans
|
||||
`/app/auth/models.py`.
|
||||
|
||||
Au moment de la définition de nouveaux modèles, éviter si possible les champs
|
||||
_nullables_, penser à créer là où ce sera utile des index.
|
||||
|
||||
## Tableaux
|
||||
|
||||
ScoDoc génère beaucoup de tableaux, sauf exception destinés à l'affichage Web et à l'export xlsx.
|
||||
|
||||
On utilise la super-classe `Table` de `app/tables/table_builder.py`.
|
||||
|
||||
Le rendu HTML utilise _DataTables_.
|
||||
|
||||
## Dates et heures
|
||||
|
||||
ScoDoc, contrairement à de nombreuses applications, est centré sur les
|
||||
_étudiants_ et les enseignements, qui sont censés opérer dans le fuseau horaire
|
||||
du serveur. Cela signifie que, quelle que soit l'emplacement de l'utilisateur,
|
||||
les heures affichées et saisies par ScoDoc seront données dans le fuseau horaire
|
||||
du serveur.
|
||||
|
||||
L'API publie et reçoit des heures au format ISO avec fuseau horaire (_timezone_) et n'est pas
|
||||
concernée par cette remarque.
|
||||
|
||||
## Sélection de groupes
|
||||
|
||||
De nombreuses pages ont besoin d'offrir un moyen de sélectionner un ou plusieurs
|
||||
groupes d'étudiants, comme dans cet exemple:
|
||||
|
||||
![menu multiselect des groupes](screens/multiselect_groups.png)
|
||||
|
||||
La vue doit récupérer la liste des groupes sélectionnés ainsi:
|
||||
|
||||
```py
|
||||
group_ids = request.args.getlist("group_ids")
|
||||
```
|
||||
|
||||
ou s'il s'agit un `POST`:
|
||||
|
||||
```py
|
||||
group_ids = request.form.getlist("group_ids")
|
||||
```
|
||||
|
||||
On converti ensuite les arguments en entiers:
|
||||
|
||||
```py
|
||||
try:
|
||||
group_ids = [int(gid) for gid in group_ids]
|
||||
except ValueError as exc:
|
||||
raise ScoValueError("group_ids invalide") from exc
|
||||
```
|
||||
|
||||
et on peut utiliser le code ancien `sco_groups_view`:
|
||||
|
||||
```py
|
||||
groups_infos = sco_groups_view.DisplayedGroupsInfos(
|
||||
group_ids,
|
||||
formsemestre_id=formsemestre.id,
|
||||
select_all_when_unspecified=True,
|
||||
)
|
||||
```
|
||||
|
||||
`groups_infos` est un objet qui permet de récupérer les informations et de générer le menu.
|
||||
|
||||
Par exemple:
|
||||
|
||||
```py
|
||||
Choix des groupes :
|
||||
{sco_groups_view.menu_groups_choice(groups_infos, submit_on_change=True)
|
||||
if groups_infos else ''}
|
||||
```
|
||||
|
||||
La fonction `form_groups_choice` génère un formulaire complet.
|
||||
|
||||
Autres attributs/méthodes utiles de `groups_infos`:
|
||||
|
||||
- `get_etudids():list[int]` : les ids des étudiants des groupes sélectionnés;
|
||||
- `groups_titles:str` : titres des groupes;
|
||||
- `groups_filename:str`: un (morceau de) nom de fichier pour ces groupes.
|
||||
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Introduction au développement ScoDoc](DevInternals.md)
|
||||
- [Guide développeurs](GuideDeveloppeurs.md)
|
||||
- [API ScoDoc 9](ScoDoc9API.md)
|
||||
- [Modélisation du BUT](ModelisationParcoursBUT.md)
|
||||
- [Contacts](Contact.md)
|
@ -1,4 +1,3 @@
|
||||
|
||||
# Cursus ScoDoc
|
||||
|
||||
Les cursus pédagogiques sont définis dans ScoDoc par des classes de "cursus" qui
|
||||
@ -43,7 +42,7 @@ ALLOW_SEM_SKIP| `bool` | passage: autorise-t-on les sauts de semestres ? (`False
|
||||
SESSION_NAME| `string` | nom des sessions (`'semestre'`)
|
||||
SESSION_ABBRV | `string` | `'S' -> S1, S2, ...`
|
||||
UNUSED_CODES | `set` | ensemble des codes jury non autorisés dans ce parcours (`set()`)
|
||||
UE_IS_MODULE| `bool` | un seul module par UE (si plusieurs modules, etudiants censéments inscrits à un seul d'entre eux) (`False`)
|
||||
UE_IS_MODULE| `bool` | un seul module par UE (si plusieurs modules, étudiants censéments inscrits à un seul d'entre eux) (`False`)
|
||||
ECTS_ONLY| `bool` | parcours avec progression basée uniquement sur les ECTS (`False`)
|
||||
ALLOWED_UE_TYPES | `set` | types d'UE autorisés dans ce parcours
|
||||
|
396
docs/DevGit.md
Normal file
396
docs/DevGit.md
Normal file
@ -0,0 +1,396 @@
|
||||
# Utilisation de git pour ScoDoc
|
||||
|
||||
Le dépôt est <https://git.scodoc.org/viennet/ScoDoc>
|
||||
|
||||
La branche `master` est celle de ScoDoc 9, d'où sont issues les paquets
|
||||
distribués (*releases*). Les développements ont lieu sur d'autres branches
|
||||
(`api`, `dev92`, `entreprises`, ...) avant d'être intégrés après tests. La
|
||||
branche `Scodoc7` était l'ancienne (jusqu'à septembre 2021) version de ScoDoc.
|
||||
|
||||
Ci-dessous quelques pense-bête qui peuvent servir.
|
||||
|
||||
## Hot fixes (internes)
|
||||
|
||||
Pour les développeurs internes (écriture sur le dépôt master), un exemple
|
||||
basique illustrant le cycle de développement:
|
||||
|
||||
```bash
|
||||
# Créer une branche
|
||||
# si besoin (travail en cours), utiliser git stash avant
|
||||
git checkout master
|
||||
git branch hotfix
|
||||
git checkout hotfix
|
||||
... dev, test ...
|
||||
git add ...
|
||||
git commit -m "fixed ..."
|
||||
git checkout master
|
||||
git merge hotfix
|
||||
git branch -d hotfix
|
||||
# publication
|
||||
|
||||
# éventuellement: git stash pop
|
||||
```
|
||||
|
||||
Dans la plupart des cas, on travaillera sur son propre dépôt (clone du dépôt
|
||||
origine), et on proposera une *pull request* (PR, *demande d'ajout* en français).
|
||||
|
||||
## Mettre à jour votre branche
|
||||
|
||||
Quand vous travaillez dans votre branche `ma_branche`, pour lui appliquer les
|
||||
mises à jour de `master` (remote), faire:
|
||||
|
||||
```bash
|
||||
git pull origin master
|
||||
```
|
||||
|
||||
## Autre exemple
|
||||
|
||||
Vous travaillez sur un clone du dépôt principal ("origin"), obtenu par exemple via
|
||||
|
||||
```bash
|
||||
git clone https://git.scodoc.org/ScoDoc/ScoDoc.git
|
||||
```
|
||||
|
||||
remplacer par l'URL de votre dépôt sur gitea au besoin. Si vous avez votre
|
||||
propre dépôt sur gitea, utilisez deux "remote": l'un pour votre dépôt gitea (ici
|
||||
nommé `mon_origin`), l'autre pour le dépôt principal ScoDoc (ici nommé
|
||||
`origin`).
|
||||
|
||||
```bash
|
||||
git remote add origin https://git.scodoc.org/viennet/ScoDoc.git
|
||||
git remote -v
|
||||
mon_origin https://xxx.xxx (fetch)
|
||||
mon_origin https://xxx.xxx (push)
|
||||
origin https://git.scodoc.org/viennet/ScoDoc.git (fetch)
|
||||
origin https://git.scodoc.org/viennet/ScoDoc.git (push)
|
||||
```
|
||||
|
||||
Ensuite, tout est prêt, vous créez votre branche:
|
||||
|
||||
```bash
|
||||
git checkout -b ma_branche
|
||||
```
|
||||
|
||||
et la poussez sur votre dépôt: (remplacer `mon_origin`au besoin)
|
||||
|
||||
```bash
|
||||
git push -u mon_origin ma_branche
|
||||
```
|
||||
|
||||
Ajoutez au fur et à mesure vos commits comme d'habitude. Mais régulièrement
|
||||
(chaque jour), mettez à jour pour éviter de diverger de la branche `master` (ou
|
||||
autre suivant les cas) de ScoDoc:
|
||||
|
||||
```bash
|
||||
git pull origin master
|
||||
```
|
||||
|
||||
Vous pouvez alors à tout moment soumettre une PR propre.
|
||||
|
||||
## Commandes utiles, en vrac
|
||||
|
||||
- `git log -L:fonction_python:fichier.py`
|
||||
- Commits locaux: `git log @{u}..`
|
||||
|
||||
### Refactoring
|
||||
|
||||
Lint tous les fichiers modifiés:
|
||||
|
||||
```bash
|
||||
git status | grep modified | grep .py | awk '{print $2}' | xargs pylint -E
|
||||
```
|
||||
|
||||
Affiche les variables non définies dans un fichier:
|
||||
|
||||
```bash
|
||||
pylint --disable=all -e E sco_parcours_dut.py | grep undefined-variable | awk '{print $4;}' | sort | uniq | tr -d \'
|
||||
```
|
||||
|
||||
Prépare un sed pour renommer les variables non définies:
|
||||
|
||||
```bash
|
||||
for f in *.py
|
||||
do
|
||||
pylint --disable=all -e E "$f" | grep undefined-variable | awk '{print "sed -i .bak s/"$4"/scu."$4"/ '$f'";}' | sort | uniq | tr -d \'
|
||||
done
|
||||
```
|
||||
|
||||
Restore les modes au besoin (SAMBA les changent parfois):
|
||||
|
||||
```bash
|
||||
git diff -p -R --no-color | grep -E "^(diff|(old|new) mode)" --color=never | git apply
|
||||
```
|
||||
|
||||
Note pour travailler sur VirtualBox:
|
||||
|
||||
```text
|
||||
addgroup scodoc vboxsf
|
||||
```
|
||||
|
||||
## Préparation d'une PR (Pull Request) (niveau avancé)
|
||||
|
||||
### Principes généraux
|
||||
|
||||
Les remarques de cette section visent à obtenir une relecture facile de votre
|
||||
demande d'ajout (*pull request*, dite "PR"):
|
||||
|
||||
- Éviter les modifications de forme qui ne changent pas le sens du code. L'utilisation de
|
||||
[`black`](https://black.readthedocs.io/) est obligatoire : elle permet de normaliser la présentation
|
||||
du code. Cela évite de générer des différences ne représentant que des
|
||||
changements de mise en forme (indentation, passages à la ligne). Cela évite
|
||||
aussi au développeur d'avoir à y réfléchir, autant de temps gagné !
|
||||
|
||||
- Avoir un nombre d'étapes de validation faible (idéalement un seul commit pour
|
||||
les PR courantes - peu volumineuses).
|
||||
|
||||
- La PR doit toujours être énoncée par rapport au dernier commit de la branche
|
||||
que vous visez (en général `master` du dépôt original).
|
||||
|
||||
### Manipulations
|
||||
|
||||
Les manipulations sont décrites selon quatre phases du développement : l'installation,
|
||||
la mise en place, le suivi et la livraison.
|
||||
|
||||
#### L'installation
|
||||
|
||||
Il est pratique d'avoir en ligne les deux dépôts git distants que vous pouvez
|
||||
utiliser : votre dépôt personnel (`https://git.scodoc.org/<user>/<dépôt>.git`) et
|
||||
le dépôt officiel (`https://git.scodoc.org/ScoDoc/ScoDoc.git`).
|
||||
|
||||
pour ajouter une référence (et lui donner un nom) vers un dépôt distant, entrez
|
||||
la commande:
|
||||
|
||||
```bash
|
||||
git remote add nom_remote https://git.scodoc.org/ScoDoc/<dépôt>.git
|
||||
```
|
||||
|
||||
Par la suite vous aurez donc une référence vers votre dépôt personnel (`perso`)
|
||||
et une référence vers le dépôt officiel (`officiel`). Si vous avez initialement
|
||||
cloné l'un des deux dépôts, la référence vers le dépôt d'origine existe et a pour nom
|
||||
`origin`.
|
||||
|
||||
La commande vous exposant tous les dépôts connus est :
|
||||
|
||||
```bash
|
||||
git remote -v
|
||||
```
|
||||
|
||||
### Mise en place
|
||||
|
||||
L'objectif de ce paragraphe est de créer une branche locale basée sur le master
|
||||
du dépôt officiel et bien sur de lui donner un nom.
|
||||
|
||||
pour cela (**attention cela va écraser les éventuels fichiers modifiés**. Si
|
||||
vous souhaitez conserver les modifications en cours, encadrez les lignes
|
||||
suivantes par `git stash` (avant) et `git stash apply` (après) :
|
||||
|
||||
```bash
|
||||
git reset --hard officiel/master
|
||||
git checkout -b ma_modif
|
||||
```
|
||||
|
||||
À partir de là, vous pouvez modifier, tester, développer et commit votre travail.
|
||||
|
||||
### Suivi
|
||||
|
||||
Si votre développement prend plusieurs jours, il est probable que la branche
|
||||
principale évolue pendant ce temps.
|
||||
|
||||
Pour garder la cohérence, il est nécessaire de réintégrer en local les
|
||||
modifications de la branche principale. Ceci peut se faire de deux façons.
|
||||
|
||||
- Une fusion (`merge`) applique toutes les modifications en un seul commit).
|
||||
C'est la méthode couramment utilisée.
|
||||
|
||||
- Un `rebase` rejoue tous les commits de la nouvelle branche par dessus l'état
|
||||
le plus à jour de la branche principale (il en résulte un historique plus
|
||||
linéaire).
|
||||
|
||||
Les commandes git correspondantes :
|
||||
|
||||
```bash
|
||||
git pull officiel master
|
||||
```
|
||||
|
||||
ou encore
|
||||
```bash
|
||||
git fetch officiel
|
||||
git merge officiel/master
|
||||
```
|
||||
|
||||
Pour un rebase (à éviter en temps normal):
|
||||
|
||||
```bash
|
||||
git fetch officiel
|
||||
git rebase officiel/merge
|
||||
```
|
||||
|
||||
### La livraison
|
||||
|
||||
Ça y est. Vous avez terminé le développement. IL n'y a plus qu'à demander
|
||||
l'intégration. Ceci se fait en plusieurs étapes (vous êtes bien sûr toujours sur
|
||||
la branche locale `ma_modif` et toutes vos modifications ont été commitées).
|
||||
|
||||
#### Étape 1 : faire l'inventaire des fichiers impliqués
|
||||
|
||||
```bash
|
||||
git fetch officiel/master
|
||||
git diff --name-only officiel/master
|
||||
```
|
||||
|
||||
#### Étape 2 : passer black sur les fichiers modifiés
|
||||
|
||||
Cette étape est automatique avec les bons réglages sous VSCode (pas trouvé
|
||||
l'équivalent sous *pyCharm*).
|
||||
|
||||
À défaut les lignes suivantes réalisent le même travail :
|
||||
|
||||
```bash
|
||||
for fn in $(git diff --name-only officiel/master)
|
||||
do
|
||||
python3 -m black $fn
|
||||
done
|
||||
```
|
||||
|
||||
Faire une première lecture rapide pour vérifier qu'il ne reste pas de fichiers
|
||||
modifiés accidentellement.
|
||||
|
||||
Pour obtenir la modification sur un fichier spécifique (`app/fichier.py` par
|
||||
exemple):
|
||||
|
||||
```bash
|
||||
git diff officiel/master app/fichier.py
|
||||
```
|
||||
|
||||
Utilisateurs Windows : Vérifiez bien que les réglages de fin de ligne suivent
|
||||
bien les règles Linux: pas de retour chariot (noté CR ou `\r`) en fin de ligne
|
||||
mais un seul caractère line feed (noté LF ou `\n`). Le cas échéant, réglez
|
||||
votre IDE pour cela.
|
||||
|
||||
À ce niveau là de la procédure, vous n'avez plus dans votre branche locale que
|
||||
les différences strictement nécessaires à votre correctif.
|
||||
|
||||
#### Étape 3 : résumez tous les commits depuis le point de divergence en un seul commit
|
||||
|
||||
**Rarement nécessaire, uniquement si vous avez de nombreux petits commits.**
|
||||
|
||||
Repérez le point de divergence de votre branche locale avec officiel/master
|
||||
(normalement `git merge-base HEAD officiel/master`)
|
||||
|
||||
Demander un `rebase` interactif depuis ce point :
|
||||
|
||||
```bash
|
||||
git rebase -i $(git merge-base HEAD officiel/master)
|
||||
```
|
||||
|
||||
*Explications*: Le rebase interactif permet d'enregistrer un suite de
|
||||
manipulation de commit dans un seul fichier texte. Le fichier texte qui reprend
|
||||
tels quels tous les commits concernés (et donc qui ne fait rien) est préparé par
|
||||
la commande `-i` de la commande_ `git rebase`.
|
||||
|
||||
Vous pouvez ensuite modifier ce fichier dans votre éditeur favori (ou pas) (à
|
||||
régler par `git config`) pour décrire_ _votre intention (réordonner, changer le
|
||||
message, fusionner, ...) sur l'ensemble des commits.
|
||||
|
||||
Quand votre édition est terminée, git reprend la main est exécute chacune de vos
|
||||
opérations. Il est possible (bien que très rare) que des conflits apparaissent
|
||||
à ce moment-là. Les commandes habituelles de correction accompagnées des
|
||||
commandes :
|
||||
|
||||
```bash
|
||||
git rebase --continue # pour poursuivre le processus
|
||||
git rebase --abort # pour tout abandonner
|
||||
```
|
||||
|
||||
*vous permettront de résoudre ces problèmes exceptionnels*.
|
||||
|
||||
Application:
|
||||
|
||||
```bash
|
||||
git rebase -i $(git merge-base HEAD officiel/master)
|
||||
```
|
||||
|
||||
Vous devez obtenir dans un éditeur de texte la liste des commits opéré depuis le
|
||||
début du développement sous cette forme (c'est un exemple : le nombre de lignes
|
||||
peut varier) :
|
||||
|
||||
```bash
|
||||
pick eb8cbec modif 1
|
||||
pick 83eb79e modif 2
|
||||
|
||||
# Rebase 5ffd074..83eb79e onto 5ffd074 (2 commands)
|
||||
#
|
||||
# Commands:
|
||||
# p, pick <commit> = use commit
|
||||
# r, reword <commit> = use commit, but edit the commit message
|
||||
# e, edit <commit> = use commit, but stop for amending
|
||||
# s, squash <commit> = use commit, but meld into previous commit
|
||||
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
|
||||
# commit's log message, unless -C is used, in which case
|
||||
# keep only this commit's message; -c is same as -C but
|
||||
# opens the editor
|
||||
# x, exec <command> = run command (the rest of the line) using shell
|
||||
# b, break = stop here (continue rebase later with 'git rebase --continue')
|
||||
# d, drop <commit> = remove commit
|
||||
# l, label <label> = label current HEAD with a name
|
||||
# t, reset <label> = reset HEAD to a label
|
||||
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
|
||||
# . create a merge commit using the original merge commit's
|
||||
# . message (or the oneline, if no original merge commit was
|
||||
# . specified); use -c <commit> to reword the commit message
|
||||
#
|
||||
# These lines can be re-ordered; they are executed from top to bottom.
|
||||
#
|
||||
# If you remove a line here THAT COMMIT WILL BE LOST.
|
||||
#
|
||||
# However, if you remove everything, the rebase will be aborted.
|
||||
#
|
||||
```
|
||||
|
||||
Vous pouvez réorganiser tous les commits (changer l'ordre, fusionner) en
|
||||
changeant la commande pick au début de chaque ligne. L'idée ici est de fusionner
|
||||
toutes les lignes avec la première en remplaçant le 'pick' à partir de la ligne
|
||||
2 par `fixup`. Au besoin, vous pouvez reformuler le message de commit
|
||||
(commande `reword` sur la première ligne).
|
||||
|
||||
Vous construirez par exemple :
|
||||
|
||||
```bash
|
||||
reword eb8cbec Correctif: Api - gestion des formation
|
||||
fixup 83eb79e modif 2
|
||||
...
|
||||
```
|
||||
|
||||
Quand vous sortez de l'éditeur, git effectue toutes les opérations demandées.
|
||||
|
||||
À ce niveau-là de la procédure :
|
||||
|
||||
- vous avez un seul commit pour l'ensemble du correctif proposé ;
|
||||
|
||||
- toutes les différences entre officiel/master et votre branche locale sont
|
||||
signifiantes.
|
||||
|
||||
#### Étape 4
|
||||
|
||||
Vous pouvez maintenant pousser votre branche locale sur votre dépôt personnel
|
||||
(vers une branche de même nom):
|
||||
|
||||
```bash
|
||||
git push --set-upstream perso ma_branche
|
||||
```
|
||||
|
||||
Si vous avez déjà fait cette opération auparavant il est possible que le push
|
||||
soit refusé (car le rebase a modifié des commits qui avaient déjà été poussés).
|
||||
Dans ce cas l'option `--force` du push vous permette de passer outre, mais
|
||||
assurez-vous avant d'être le seul à travailler sur cette branche.
|
||||
|
||||
#### Etape 5 : La dernière étape se passe sur le site [git.scodoc.org](https://git.scodoc.org/)
|
||||
|
||||
- Identifiez-vous
|
||||
|
||||
- Placez-vous sur la branche nouvellement créée
|
||||
|
||||
- À l'aide de l'interface du serveur, vous pouvez comparer l'état de votre
|
||||
branche par rapport au master officiel, et si cela vous convient, il vous
|
||||
reste à formuler une demande d'intégration (*pull request*). En remplissant
|
||||
les informations demandées.
|
@ -1,22 +1,22 @@
|
||||
# Quelques informations pour les développeurs
|
||||
# Développement ScoDoc: Introduction
|
||||
|
||||
## Composants logiciels
|
||||
|
||||
- le code est écrit en Python 3.9 (passage à 3.10 prévu avec Debian 12).
|
||||
- le code doit être formatté par [black](https://pypi.org/project/black/) qui
|
||||
est normalement intégré à votre éditeur (VSCode et PyCharm sont deux choix
|
||||
judicieux).
|
||||
- outre Python, les principaux composants logiciels sont:
|
||||
- [Flask](https://flask-sqlalchemy.palletsprojects.com/en/2.x/): le
|
||||
framework Web, dont on utilise notamment:
|
||||
- le code est écrit en Python 3.11.
|
||||
- le code doit être formatté par [black](https://pypi.org/project/black/) qui
|
||||
est normalement intégré à votre éditeur (VSCode et PyCharm sont deux choix
|
||||
judicieux).
|
||||
- outre Python, les principaux composants logiciels sont:
|
||||
- [Flask](https://flask-sqlalchemy.palletsprojects.com/en/2.x/): le
|
||||
framework Web, dont on utilise notamment:
|
||||
- l'ORM [SQLAlchemy](https://www.sqlalchemy.org/)
|
||||
- les templates [Jinja2](https://jinja.palletsprojects.com/en/3.0.x/)
|
||||
- [Postgresql](https://www.postgresql.org/)
|
||||
- [Redis](https://redis.io/) cache persistant
|
||||
- [NGINX](https://www.nginx.com/) serveur Web frontal
|
||||
- [gunicorn](https://gunicorn.org/) WSGI HTTP server
|
||||
- et bien sûr Linux (Debian 11 en 2021-2022) et systemd.
|
||||
|
||||
- [Postgresql](https://www.postgresql.org/)
|
||||
- [Redis](https://redis.io/) cache persistant
|
||||
- [NGINX](https://www.nginx.com/) serveur Web frontal
|
||||
- [gunicorn](https://gunicorn.org/) WSGI HTTP server
|
||||
- et bien sûr Linux (Debian 12 en 2023-2024) et systemd.
|
||||
|
||||
## Principaux objets
|
||||
|
||||
Les objets manipulés par ScoDoc sont pour la plupart stockés en base postgres et
|
||||
@ -27,35 +27,35 @@ Les modèles correspondant sont déclarés dans `/opt/scodoc/app/models/`.
|
||||
|
||||
Principales classes (les noms des classes Python sont en `CamelCase`).
|
||||
|
||||
- Étudiants (classe `Identite`): nom, codes INE/NIP, etc
|
||||
- Formations: programmes pédagogiques, contenant
|
||||
- Unités d'Enseignement (`UniteEns`);
|
||||
- Matières et Modules (`Module`, avec son type standard, bonus, ressources
|
||||
ou SAÉ).
|
||||
- FormSemestre: instanciation d'une session de formation, avec un programme
|
||||
pédagogique donné (Formation), les dates de début et fin, des étudiants
|
||||
inscrits, des responsables, divers codes, et les ModuleImpl mis en œuvre.
|
||||
- ModuleImpl: la mise en place d'un module pédagogique (le ModuleImpl est au
|
||||
Module ce que le FormSemestre est à la Formation): lié à un module, avec un
|
||||
enseignant responsable et des étudiants inscrits.
|
||||
- Inscriptions: tables d'association avec codes et/ou état (démission,
|
||||
défaillant): FormsemestreInscription ModuleImplInscription.
|
||||
- Étudiants (classe `Identite`): nom, codes INE/NIP, etc
|
||||
- Formations: programmes pédagogiques, contenant
|
||||
- Unités d'Enseignement (`UniteEns`);
|
||||
- Matières et Modules (`Module`, avec son type standard, bonus, ressources
|
||||
ou SAÉ).
|
||||
- FormSemestre: instanciation d'une session de formation, avec un programme
|
||||
pédagogique donné (Formation), les dates de début et fin, des étudiants
|
||||
inscrits, des responsables, divers codes, et les ModuleImpl mis en œuvre.
|
||||
- ModuleImpl: la mise en place d'un module pédagogique (le ModuleImpl est au
|
||||
Module ce que le FormSemestre est à la Formation): lié à un module, avec un
|
||||
enseignant responsable et des étudiants inscrits.
|
||||
- Inscriptions: tables d'association avec codes et/ou état (démission,
|
||||
défaillant): FormsemestreInscription ModuleImplInscription.
|
||||
|
||||
## Vues et décorateurs
|
||||
|
||||
Une vue ordinaire (Web) pourrait ressembler à cela. Noter la présence de
|
||||
décorateurs:
|
||||
|
||||
- `@scodoc` récupère le département (présent dans l'URL) et initialise quelques
|
||||
trucs, notamment `g.scodoc_dept` (l'acronyme du département courant) et
|
||||
`g.scodoc_dept_id` (l'id du dépt. courant).
|
||||
- `@permission_required`: permet de contrôler l'accès, en se basant sur les
|
||||
permissions définies dans la classe `Permission`.
|
||||
- `@scodoc` récupère le département (présent dans l'URL) et initialise quelques
|
||||
trucs, notamment `g.scodoc_dept` (l'acronyme du département courant) et
|
||||
`g.scodoc_dept_id` (l'id du dépt. courant).
|
||||
- `@permission_required`: permet de contrôler l'accès, en se basant sur les
|
||||
permissions définies dans la classe `Permission`.
|
||||
|
||||
```
|
||||
```py
|
||||
@bp.route("/un_exemple")
|
||||
@scodoc
|
||||
@permission_required(Permission.ScoChangeFormation)
|
||||
@permission_required(Permission.EditFormation)
|
||||
def un_exemple():
|
||||
# Récupérer le ou les arguments: exemple avec formation_id
|
||||
formation_id = int(request.args["formation_id"])
|
||||
@ -66,8 +66,8 @@ def un_exemple():
|
||||
# Effectuer au besoin un traitement
|
||||
resultat = ...
|
||||
# Afficher le résultat
|
||||
return render_template(
|
||||
"exemple_template.html",
|
||||
return render_template(
|
||||
"exemple_template.html",
|
||||
resultat=resultat, # par exemple
|
||||
formation=formation,
|
||||
... # etc
|
||||
@ -131,8 +131,8 @@ http GET http://localhost:5000/ScoDoc/api/formsemestres/query "Authorization:Bea
|
||||
|
||||
### Côté programmation serveur
|
||||
|
||||
Reprenons le même exemple (voir app/api/formsemestres.py ligne 91,
|
||||
<https://scodoc.org/git/ScoDoc/ScoDoc/src/branch/master/app/api/formsemestres.py#L91>):
|
||||
Reprenons le même exemple (voir `app/api/formsemestres.py`` ligne 91,
|
||||
<https://git.scodoc.org/ScoDoc/ScoDoc/src/branch/master/app/api/formsemestres.py#L91>):
|
||||
|
||||
```py
|
||||
@bp.route("/formsemestres/query")
|
||||
@ -177,7 +177,8 @@ lancer flask (plus rapide).
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Informations pour les développeurs](Internals.md)
|
||||
- [Conventions de codage](DevConventions.md)
|
||||
- [Guide développeurs](GuideDeveloppeurs.md)
|
||||
- [API ScoDoc 9](ScoDoc9API.md)
|
||||
- [Modélisation du BUT](ModelisationParcoursBUT.md)
|
||||
- [Contacts](Contact.md)
|
183
docs/DevJuryBUT.md
Normal file
183
docs/DevJuryBUT.md
Normal file
@ -0,0 +1,183 @@
|
||||
# Implémentation jurys BUT
|
||||
|
||||
*Quelques notes informelles sur la gestion des jurys BUT.*
|
||||
|
||||
Fichiers sources:
|
||||
|
||||
```txt
|
||||
app/but/jury_but.py
|
||||
app/but/cursus_but.py
|
||||
```
|
||||
|
||||
## Validations enregistrées
|
||||
|
||||
- UEs : comme pour les formations classiques
|
||||
|
||||
- RCUE: `ApcValidationRCUE(etudid, formsemestre, ue1, ue2)`
|
||||
- Le formsemestre est optionnel: c'est celui d'où a été émise la validation.
|
||||
- Pour retrouver le niveau, passer par l'UE: `ue1.niveau_competence`
|
||||
|
||||
- Années BUT: `ApcValidationAnnee`
|
||||
- liée au référentiel de compétence.
|
||||
|
||||
## La page saisie jury BUT (annuelle)
|
||||
|
||||
Partir de la liste des niveaux à valider pour cet étudiant dans sa scolarité,
|
||||
selon le parcours de l'étudiant. Le parcours est donné par son inscription dans
|
||||
le semestre courant (celui duquel on lance la saisie).
|
||||
Chaque compétence forme une ligne, comme sur la fiche étudiant.
|
||||
Le semestre courant donne l'année scolaire (2022, ...) et l'année BUT courante (1, 2, 3)
|
||||
On affiche les colonnes suivantes (exemple d'un jury de BUT2 S4):
|
||||
|
||||
| BUT1 | BUT2 S2 | BUT2 S3 | BUT2 RCUE | autorisation | BUT3 |
|
||||
|---------------|---------|---------|-----------|--------------|-------------|
|
||||
| Compétence 1 | rcue | UE1.3 | UE1.4 | code | feu vert S5 |
|
||||
| Compétence 2 | ... | ... | ... | ... | ... |
|
||||
|
||||
sur chaque code un popup explicatif (date de validation)
|
||||
|
||||
Actuellement (9.4), l'état du BUT1 (et BUT2 quand on sera en BUT3) n'est pas
|
||||
rappelé sur cet affichage.
|
||||
|
||||
### Rappel sur les validations de jury
|
||||
|
||||
En BUT, on va utiliser 3 types de décisions de jury: sur les UEs, les RCUEs et
|
||||
les années de BUT. Une décision sur une UE concerne l'UE d'un semestre, d'une
|
||||
année scolaire donnée: on peut enregistre une décision AJ sur l'UE12 en 2022,
|
||||
puis ADM sur l'UE12 d'an nouveau formsemestre en 2023. Ce n'est pas le cas pour
|
||||
les décisions concernant le cursus BUT: on valide (ou non) l'année BUT1, puis
|
||||
BUT2 puis BUT3. Un redoublant pour avoir son BUT1 en AJ, puis il passera en ADM
|
||||
l'année suivante. Pareil pour les RCUEs. Autrement dit, le code d'une année BUT
|
||||
ou d'un RCUE, pour un étudiant donné, est unique.
|
||||
|
||||
### Validations d'UE antérieures
|
||||
|
||||
Les validations d'UEs externes existaient avant ScoDoc 9.
|
||||
Elles sont utilisées quand un étudiant arrive en transfert avec une UE validée
|
||||
mais pas un semestre complet (ne pas confondre avec les "semestres extérieurs"
|
||||
qui sont gérés comme des formsemestres ordinaires).
|
||||
|
||||
Les UE antérieures sont présentes dans les bulletins BUT.
|
||||
|
||||
### Tenue du jury
|
||||
|
||||
Le jury part d'un formsemestre (dit origine).
|
||||
Dans ce formsemestre, `etud` est inscrit à un parcours (ou au tronc commun): on
|
||||
sait quels niveaux il doit valider durant année.
|
||||
|
||||
Le jury (pour un niveau) peut éditer:
|
||||
|
||||
- l'UE du formsemestre origine (qui peut être déjà validée en cas de
|
||||
modification)
|
||||
- l'UE du formsemestre précédent si l'origine est impaire et que ce formsemestre
|
||||
impair n'est pas verrouillé (sinon, affichée mais en lecture seule)
|
||||
- le RCUE
|
||||
|
||||
#### Édition décision d'UE
|
||||
|
||||
Le menu jury (activé par défaut) pour une UE affichera:
|
||||
|
||||
- Si en cours: la moyenne courante, la décision recommandée basée sur cette note
|
||||
- Si validée ailleurs que dans le semestre en cours: le code et la moyenne
|
||||
enregistrés.
|
||||
- Si pas en cours, menu désactivé, pas d'édition de la décision d'UE.
|
||||
|
||||
#### Édition décision de RCUE
|
||||
|
||||
Le menu RCUE est désactivé par défaut: calcul automatique en fonction des
|
||||
décisions d'UE.
|
||||
|
||||
Le code enregistré (rappel: chaque RCUE n'a qu'un code enregistré, contrairement
|
||||
aux UEs) est affiché (code couleur s'ile st différent d ecelui calculé).
|
||||
|
||||
La modification du code RCUE peut entrainer la modification des codes des UEs
|
||||
qui le constituent: code RCUE `ADJ` => UEs non validante passées en `ADJR`
|
||||
(géré par `DecisionRCUE.record` et en js dans `jury_but.js`). )
|
||||
|
||||
La modification de codes d'UE devrait ou pourrait modifier le code RCUE proposé,
|
||||
mais ce n'est pas implémenté en 9.4.92.
|
||||
|
||||
### Classes
|
||||
|
||||
Ordre de construction:
|
||||
- `DecisionsProposeesAnnee`
|
||||
- `RegroupementCoherentUE`
|
||||
- `DecisionsProposeesRCUE(rcue)`
|
||||
- `DecisionsProposeesUE`
|
||||
|
||||
#### `RegroupementCoherentUE(etud, ApcNiveau, ues_pair, ues_impair)`
|
||||
|
||||
Modélise un couple d'UEs associées au même niveau de compétence du référentiel.
|
||||
|
||||
L'ancienne classe `RegroupementCoherentUE` (définie dans
|
||||
`models/but_validation.py`) ne répondait pas au besoin car elle était construite sur
|
||||
la base de deux formsemestres.
|
||||
|
||||
- On part de toutes les UEs de nos formations associées à ce niveau. On peut
|
||||
avoir un nombre quelconque d'UEs paires et impaires associées à ce niveau.
|
||||
|
||||
- Les UEs associées à ce niveau peuvent être:
|
||||
- validées (externes, ou dans un formsemestre connu), avec une moyenne enregistrée
|
||||
- ou en cours: dans un formsemestre suivi par l'étudiant, avec une moyenne
|
||||
d'UE calculable.
|
||||
|
||||
Notons qu'il peut arriver qu'aucune des UEs n'appartiennent au semestre origine
|
||||
(capitalisations, validations antérieures). Dans ce cas, leurs décisions ne sont
|
||||
pas toujours éditables, mais le RCUE l'est.
|
||||
|
||||
Pour chaque côté (impair, pair), on va chercher:
|
||||
|
||||
- l'UE en cours pendant l'année scolaire du formsemestre origine s'il y en a
|
||||
une (ie cherche dans les formations des formsemestres de même année scolaire
|
||||
que l'origine)
|
||||
- la validation de jury enregistrée pour cette UE en cours
|
||||
- la validation d'UE validante enregistrée (capitalisation ou antérieure, peu
|
||||
importe)
|
||||
|
||||
NB: s'il y a plusieurs UEs en cours (double inscription, erreur): prend celle du
|
||||
formsemestre commencé le plus récemment.
|
||||
|
||||
État d'un `RegroupementCoherentUE`:
|
||||
|
||||
- **complete** : False si on n'a pas les deux UEs
|
||||
|
||||
#### Opérations sur `RegroupementCoherentUE`
|
||||
|
||||
- init:
|
||||
- Chercher l'UE en cours pour pair, impair: `ue_cur_pair`, `ue_cur_impair`, et
|
||||
leurs validations `validation_ue_cur_pair`, `validation_ue_cur_impair`.
|
||||
- Chercher pour pair, impair la meilleure validation d'UE enregistrée dans un
|
||||
autre formsemestre. `validation_ue_best_pair`
|
||||
- complete = les deux UEs validées ou en cours cette année
|
||||
- moy_rcue: moyenne des moyennes d'UE
|
||||
|
||||
#### DecisionsProposeesAnnee
|
||||
|
||||
- `decisions_ues` : considérer les UEs associées aux niveaux et non celles des
|
||||
semestres. Notez que même si l'étudiant n'est pas inscrit ("dispensé") à une UE
|
||||
dans le formsemestre origine, elle doit apparaitre sur la page jury.
|
||||
- `rcues_annee`: liste des `RegroupementCoherentUE`
|
||||
- `decisions_rcue_by_niveau`
|
||||
|
||||
#### DecisionsProposeesRCUE
|
||||
|
||||
- `record`: modifie les codes d'UE en fonction du RCUE: *si le RCUE est `ADJ`,
|
||||
les UEs non validées sont passées à `ADJR`.
|
||||
- Les validations d'UEs antérieures ou capitalisées ne sont pas concernées car
|
||||
déjà valides.
|
||||
- Si le formsemestre contenant l'UE à modifier est verrouillé, on
|
||||
modifie quand même et on émet un warning.
|
||||
- Les RCUE/UE du niveau inférieur peuvent aussi être modifiées (c'est déjà le
|
||||
cas, `ADSUP`).
|
||||
|
||||
#### DecisionsProposeesUE
|
||||
|
||||
L'objet peut représenter une validation capitalisée ou antérieure: il est alors
|
||||
en lecture seule.
|
||||
|
||||
Pour chaque RCUE, on a les deux UEs à considérer dans `ue_1`, `ue_2`.
|
||||
|
||||
- Modifier affichage UE "en lecture seule"
|
||||
- Ne pas restreindre la recherche aux UEs du formsemestre.
|
||||
- Le calcul de la moyenne en utilisant `ResultatsSemestreBUT` n'est évidemment
|
||||
utilisé que pour l'UE en cours.
|
@ -2,49 +2,63 @@
|
||||
|
||||
## Description d'un étudiant
|
||||
|
||||
La désignation d'un étudiant (classiquement civilité-nom-prenom) peut prendre différentes formes en fonctions des circonstances et des souhaits de l'étudiant.
|
||||
La désignation d'un étudiant (classiquement civilité-nom-prénom) peut prendre
|
||||
différentes formes en fonctions des circonstances et des souhaits de l'étudiant.
|
||||
On distingue les éléments suivants:
|
||||
|
||||
* `nom`: (obligatoire): le nom de l'étudiant (en usage dans l'établissement). Généralement (mais pas toujours) le nom d'état-civil de l'étudiant.
|
||||
* `nom`: (obligatoire): le nom de l'étudiant (en usage dans l'établissement).
|
||||
Généralement (mais pas toujours) le nom d'état-civil de l'étudiant.
|
||||
* `prenom`: (obligatoire): le prénom de l'étudiant
|
||||
* `civilité`: (obligatoire): la civilité utilisée parmi les valeurs:
|
||||
* `MR` (ou aussi `H` ou `M`)
|
||||
* `MME` (ou aussi `F`)
|
||||
* `X` décrit plus loin
|
||||
* `nom_usuel`: si présent s'affiche à la place du `nom`.
|
||||
* `prenom_etat_civil`: Si présent, indique le prénom qui doit être utilisé dans les documents officiels (PV et bulletin).
|
||||
* `civilite_etat_civil` est associé au prénom d'état-civil (donc jamais utilisé si `prenom_etat_civil` n'est pas renseigné.
|
||||
* `prenom_etat_civil`: Si présent, indique le prénom qui doit être utilisé dans
|
||||
les documents officiels (PV et bulletin).
|
||||
* `civilite_etat_civil` est associé au prénom d'état-civil (donc jamais utilisé
|
||||
si `prenom_etat_civil` n'est pas renseigné).
|
||||
|
||||
## Personalisations
|
||||
## Personnalisations
|
||||
|
||||
L'étudiant peut:
|
||||
|
||||
* déclarer un nom d'usage qui remplacera le nom initial dans tous les documents
|
||||
(par exemple par l'adoption d'un nom marital pour remplacer le patronyme)
|
||||
Il faut dans ce cas remplir la donnée `nom_usuel` avec le nouveau nom souhaité.
|
||||
* Demander la suppression de la civilité courante (`MR` ou `MME`). La valeur `X` peut être utlisée dans ce cas.
|
||||
* Demander à ce que sa civilité (`M.` ou `Mme`) ne soit pas affichée. La valeur
|
||||
`X` doit être utilisée dans ce cas.
|
||||
* demander l'utilisation d'un prénom d'usage ([1] et [2]).
|
||||
|
||||
Ce prénom, qui ne demande pas d'acte officiel (hormis une demande formelle à l'université d'appartenence) remplace le prénom initial dans tous les documents internes
|
||||
sauf dans les documents officiels (procès-verbal et bulletin de notes). Ce changement peut être accompagné d'un changement de civilité.
|
||||
Il faut dans ce cas:
|
||||
* Reporter le prénom et la civilité initiaux dans les champs `prenom_etat_civil` et `civilite_etat_civil`
|
||||
* Remplacer les champs `civilite` et `prenom` avec les valeurs souhaitées par l'étudiant.
|
||||
Ce prénom, qui ne demande pas d'acte officiel (hormis une demande formelle à
|
||||
l'université d'appartenance) remplace le prénom initial dans tous les
|
||||
documents internes sauf dans les documents officiels (procès-verbal et
|
||||
bulletin de notes). Ce changement peut être accompagné d'un changement de
|
||||
civilité. Il faut dans ce cas:
|
||||
* Reporter le prénom et la civilité initiaux dans les champs
|
||||
`prenom_etat_civil` et `civilite_etat_civil`
|
||||
* Remplacer les champs `civilite` et `prenom` avec les valeurs souhaitées par
|
||||
l'étudiant.
|
||||
|
||||
## Dans le logiciel
|
||||
|
||||
Les données personnelles sont modifiables:
|
||||
|
||||
* Dans l'écran `Changer les données identité/admission` du menu `Étudiant` dans la fiche étudiant.
|
||||
* Par la procédure d'importation par tableur (`Import/export des données d'admission` du menu `INSCRIPTIONS`)
|
||||
* Dans l'écran `Changer les données identité/admission` du menu `Étudiant` dans
|
||||
la fiche étudiant.
|
||||
* Par la procédure d'importation par tableur (`Import/export des données
|
||||
d'admission` du menu `INSCRIPTIONS`)
|
||||
|
||||
Les civilités et prénom d'état-civil sont prises en compte:
|
||||
|
||||
* Automatiquement lors de la production du procés-verbal
|
||||
* Dans l'édition du bulletin au format pdf (pas sur la passerelle étudiant) à condition que les descriptions spécifiées dans le paramètrage du département et/ou les réglages bulletin des semestres concernés mentionne
|
||||
la balise `etat_civil` plutôt que la balise `nomprenom` (cf. [Paramètrage des bulletins / Valeurs remùplacées](https://scodoc.org/ParametrageBulletins/#valeurs-remplacees)).
|
||||
* Automatiquement lors de la production du procès-verbal
|
||||
* Dans l'édition du bulletin au format pdf (pas sur la passerelle étudiant) à
|
||||
condition que les descriptions spécifiées dans le paramétrage du département
|
||||
et/ou les réglages bulletin des semestres concernés mentionne la balise
|
||||
`etat_civil` plutôt que la balise `nomprenom` (voir
|
||||
[Paramétrage des bulletins / Valeurs remplacées](https://scodoc.org/ParametrageBulletins/#valeurs-remplacees)).
|
||||
|
||||
Les données personalisées figurent toutes dans les données livrées par l'API.
|
||||
Les données personnalisées figurent toutes dans les données livrées par l'API.
|
||||
|
||||
## Références
|
||||
|
||||
|
170
docs/DonneesModuleAssiduite.md
Normal file
170
docs/DonneesModuleAssiduite.md
Normal file
@ -0,0 +1,170 @@
|
||||
<!-- markdownlint-disable MD024 -->
|
||||
# Document expérimental sur les données du module Assiduité de ScoDoc
|
||||
|
||||
Dans ce document je (Matthias Hartmann) détaillerais plusieurs méthodes pour enregistrer les données du module Assiduité et les utiliser. Je mettrai à jour ce document et je l'utiliserai lors de l'implémentation du cahier des charges.
|
||||
|
||||
> Pour la suite du document je nomme `plage` l'objet représentant une absence/présence sur une période donnée.
|
||||
|
||||
Dans les diagrammes:
|
||||
|
||||
> - les noms précédés par `?` sont des valeurs optionnelles.
|
||||
> - les noms précédés par `#` sont des clés externes.
|
||||
> - les noms précédés par `$` sont des clés primaires.
|
||||
|
||||
___
|
||||
|
||||
> dev note *(11/10/22)*: Les types des données ne sont pas forcément les bons, je n'ai pas encore regardé comment était organisée la BDD de ScoDoc
|
||||
|
||||
## Représentation d'une assiduité et d'un justificatif
|
||||
|
||||
> voir l'API ScoDoc -> [ScoDoc9 API](ScoDoc9API.md#api-assiduite)
|
||||
|
||||
## Représentation des données (Version 4)
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
|
||||
class assiduites{
|
||||
$assiduiteid : Integer
|
||||
#etuid : Integer
|
||||
date_debut : DateTime
|
||||
date_fin : DateTime,
|
||||
etat : String
|
||||
#module?: Integer
|
||||
|
||||
}
|
||||
class justificatifs{
|
||||
$justifid : Integer
|
||||
#etuid : Integer
|
||||
date_debut : DateTime
|
||||
date_fin : DateTime
|
||||
fichier? : Integer
|
||||
raison? : String
|
||||
#etat : Integer DEFAULT=0
|
||||
}
|
||||
class etat_justificatif{
|
||||
$etat_id : Integer
|
||||
desc : String
|
||||
}
|
||||
justificatifs --> etat_justificatif
|
||||
```
|
||||
|
||||
### Explications de la représentation
|
||||
|
||||
> - Dans cette version, les objets en base de données suivent la représentation fait en json (dans l'API)
|
||||
> - Le fichier justificatif est toujours stocker sur le serveur et en base il est stocker sous la forme d'un identifiant unique.
|
||||
> - le champs `etat` de la table `justificatif` est une clé étrangère vers la table `etat_justificatif` qui contient les différents états (attente, validé, modifié, en cours . . . ), Cette table permettra aux utilisateurs d'ajouter eux même des états en fonction de leurs besoins. (deux états seront obligatoires : 0[Non Validé] 1[Validé] mais leurs noms pourront être changés.)
|
||||
|
||||
## Représentation des données (Version 3)
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
|
||||
class plage{
|
||||
plage_id : Integer
|
||||
date_debut : DateTime
|
||||
date_fin : DateTime
|
||||
#etuid : Integer
|
||||
type : String
|
||||
? #module_id : Integer
|
||||
? #enseignant_id : Integer
|
||||
}
|
||||
class justificatif{
|
||||
$#etuid : Integer
|
||||
$date_debut : DateTime
|
||||
$date_fin : DateTime
|
||||
attachement : String
|
||||
#etat : Integer DEFAULT=0
|
||||
}
|
||||
class etat_justificatif{
|
||||
$etat_id : Integer
|
||||
desc : String
|
||||
}
|
||||
justificatif --> etat_justificatif
|
||||
```
|
||||
|
||||
### Explications de la représentation
|
||||
|
||||
> - Dans cette représentation, une plage est complètement dissociée d'une formation / département. Elle repose uniquement sur un étudiant en particulier. On peut néanmoins spécifier l'enseignant et le module concerné par l'absence dans le but de produire des statistiques.
|
||||
> - Du coté des justificatifs, on a désormais un attribut `etat` plutôt qu'un booléen. Cet attribut est une clé étrangère lié à la table `etat_justificatif`. Cela permet alors d'avoir plusieurs états (Validé, Refusé, En Attente, Incomplet...) l'état `0` étant `Pas encore étudié` par exemple.
|
||||
|
||||
### Problèmes de la représentation
|
||||
|
||||
> - On utilise une nouvelle table pour stocker les différents états. A moins que cette table ne puisse être modifiée par les administrateurs de ScoDoc (ajouter des états pour des cas précis par IUT), on créer une table pour enregistrer des données statiques.
|
||||
|
||||
### Améliorations potentielles
|
||||
|
||||
> - A la place d'une table dans la BDD, on pourrait directement hard coder les états de justificatifs. Les états seront plus simple à accéder mais on perd l'aspect modification au cas par cas.
|
||||
|
||||
## Représentation des données (Version 2)
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
class plage{
|
||||
id_plage : Integer
|
||||
date_debut : DateTime
|
||||
date_fin : DateTime
|
||||
#id_dept : Integer
|
||||
#formsemestre_id : Integer
|
||||
#etuid : Integer
|
||||
type : String
|
||||
? #id_module : Integer
|
||||
? #id_enseignant : Integer
|
||||
}
|
||||
class justificatif{
|
||||
$#etuid : Integer
|
||||
$date_debut : DateTime
|
||||
$date_fin : DateTime
|
||||
attachement : String
|
||||
valide : bool DEFAULT=False
|
||||
}
|
||||
```
|
||||
|
||||
### Problèmes liés à la représentation
|
||||
|
||||
> - L'export de la base de donnée avec les justificatif devient plus complexe (car on doit aller chercher les fichiers du dossier justificatifs)
|
||||
> - Même problème que la version 1 pour les requêtes
|
||||
|
||||
## Représentation des données ( Version 1)
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
class plage{
|
||||
id_plage : Integer
|
||||
date_debut : DateTime
|
||||
date_fin : DateTime
|
||||
#id_dept : Integer
|
||||
#formsemestre_id : Integer
|
||||
#etuid : Integer
|
||||
type : String
|
||||
? #id_module : Integer
|
||||
? #id_enseignant : Integer
|
||||
}
|
||||
class justificatif{
|
||||
#$id_plage : Integer
|
||||
attachement : Blob
|
||||
valide : bool DEFAULT=False
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Problèmes liés à la représentation
|
||||
|
||||
> - Quasiment l'ensemble des données sont stockées dans un même tuple\
|
||||
> __Conséquence__ : chaque requête utilisant les données sera longue et lourde pour le gestionnaire de BDD
|
||||
> - Le stockage sour la forme de blob est très lourd pour la bdd ( cf : [Benchmark des différentes méthode de stockage de fichier binaire sur progresql](https://www.cybertec-postgresql.com/en/binary-data-performance-in-postgresql/) )
|
||||
> - Un justificatif doit être donné pour chaque absence (par exemple un arrêt maladie de plusieurs jours est présent dans la base autant de fois que l'étudiant a été absence à un cours )
|
||||
|
||||
### Avantages liés à la représentation
|
||||
|
||||
> - Peu ou pas de jointure à faire
|
||||
> - Ensemble des données facilement accessibles
|
||||
> - Une absence (`plage: type=absence`) est justifiée si un justificatif (`justificatifs : idPlage={idAbsence}`) est présent dans la base. Une absence peut être justifiée(par un étudiant par exemple) mais pas forcément validé par le corps enseignant / administratif. (`justificatifs : valide=Faux`)
|
||||
> - l'objet justificatif permet de stocker un fichier / un texte servant de justification (`justificatifs : attachement={Blob}`). L'utilisation d'un __Blob__ permet de stocker virtuellement n'import quel type de fichier dans la bdd.
|
||||
|
||||
### Améliorations potentielles
|
||||
|
||||
> - Stocker les fichiers justificatifs dans un dossier sur le serveur plutôt que dans la base de donnée. On aurait alors une sauvegarde uniquement d'une chaîne de caractères (le chemin du fichier / la justification textuelle) au lieu de __Blob__ prenant beaucoup de place et étant lourds à traiter.\
|
||||
> __Le problème est qu'on perd la facilité d'accès et les vérifications opérées automatiquement par le gestionnaire de base de donnée.__
|
||||
> - Définir une durée de validité pour chaque justificatif au lieu de lier le justificatif à une plage. (et donc lier un justificatif à un étudiant)\
|
||||
> __Le problème est qu'on perd de la simplicité de selection (utilisation de l'id de la plage dans un cas et utilisation de 2 *datetime* dans un autre) Mais au moins on a pas besoin d'entrer plusieurs fois un même justificatif.__
|
198
docs/EmploisDuTemps.md
Normal file
198
docs/EmploisDuTemps.md
Normal file
@ -0,0 +1,198 @@
|
||||
# Utilisation des emplois du temps
|
||||
|
||||
ScoDoc peut être interfacé avec un logiciel de gestion des emplois du temps (EDT).
|
||||
Le paramétrage peut-être assez complexe, mais une fois mis en place cela permet
|
||||
à ScoDoc d'afficher l'emploi du temps des étudiants d'un semestre et facilite
|
||||
grandement la saisie des absences.
|
||||
|
||||
## Principes généraux
|
||||
|
||||
Les emplois du temps sont gérés par un autre logiciel, comme:
|
||||
|
||||
- Hyperplanning
|
||||
- Celcat
|
||||
- GPU
|
||||
- VT [Visual Timetabling](http://visual.timetabling.free.fr)
|
||||
- ...
|
||||
|
||||
Ces logiciels peuvent exporter les calendriers au format ICS (iCalendar,
|
||||
[RFC 5545](https://datatracker.ietf.org/doc/html/rfc5545)).
|
||||
|
||||
ScoDoc va lire ces calendriers (fichiers ics). Il doit y avoir un fichier
|
||||
calendrier par semestre ScoDoc, contenant tous les évènements (cours, TD, TP...)
|
||||
du semestre.
|
||||
|
||||
### Fichiers calendrier ics
|
||||
|
||||
Un calendrier est ici une liste d'évènements, chaque cours étant un évènement.
|
||||
L'évènement comporte:
|
||||
|
||||
- dates début et fin;
|
||||
- identifiant du groupe d'étudiants concerné (dans la formation, par ex. groupe
|
||||
de TD);
|
||||
- identifiant du module (enseignement): par exemple, l'élément Apogée.
|
||||
- identifiant de l'enseignant concerné.
|
||||
|
||||
On suppose qu'on a un calendrier par "semestre" (`FormSemestre` ScoDoc),
|
||||
identifié par un code (par défaut, le premier code étape Apogée) que l'on
|
||||
appellera `edt_id`. Lors de la configuration, on indiquera à ScoDoc où sont
|
||||
placés ces fichiers.
|
||||
|
||||
|
||||
!!! note "Note: fuseau horaire"
|
||||
|
||||
Les calendriers sont exportés avec des dates comportant l'indication du fuseau
|
||||
horaire. ScoDoc affiche en principe toutes les heures en *heure locale du
|
||||
serveur*, c'est à dire à la montre des étudiants (et non dans l'heure locale de
|
||||
l'utilisateur qui peut être en déplacement dans un autre pays).
|
||||
|
||||
## Paramétrage global (administrateur)
|
||||
|
||||
Le super-administrateur a accès à la page de configuration via le lien
|
||||
"**Configuration du suivi de l'assiduité et accès aux emplois du temps**".
|
||||
|
||||
La première chose à faire est d'indiquer où sont placés les fichiers calendrier.
|
||||
L'emploi du temps étant variable, ces fichiers vont en général être exportés à
|
||||
intervalles réguliers (par exemple chaque heure) et écrits dans un répertoire
|
||||
donné du serveur ScoDoc. ScoDoc ne se charge pas de cette tâche:
|
||||
l'administrateur système doit mettre en place un mécanisme d'export et de
|
||||
recopie ou partage des calendriers.
|
||||
|
||||
Le chemin se configure ici:
|
||||
|
||||
![Configuration chemin vers le calendrier](screens/edt-config-chemin.png)
|
||||
|
||||
### Exemple d'évènement ics
|
||||
|
||||
Exemple venant d'un établissement utilisant HyperPlanning. Les calendrier sont exportés
|
||||
régulièrement, on a un fichier ics par formation (code Apogée).
|
||||
|
||||
```ics
|
||||
BEGIN:VEVENT
|
||||
CATEGORIES:HYPERPLANNING
|
||||
DTSTAMP:20231101T140300Z
|
||||
LAST-MODIFIED:20230905T094241Z
|
||||
UID:Cours-423101-5-BUT2_RT_pa._CYBER-Index-Education
|
||||
DTSTART:20230920T060000Z
|
||||
DTEND:20230920T083000Z
|
||||
SUMMARY;LANGUAGE=fr:TP2 GPR1 - VCYR303 - Services reseaux ava (VCYR303) - 1234 - M. VIENNET EMMANUEL - V2ROM - BUT2 RT pa. ROM - Groupe 1
|
||||
LOCATION;LANGUAGE=fr:P202 CRIT - P202 CRIT.RESEAUX
|
||||
DESCRIPTION;LANGUAGE=fr:Matière : VCYR303 - Services reseaux ava (VCYR303)\nEnseignant : 1234 - M. VIENNET EMMANUEL\nPromotion : V2ROM - BUT2 RT pa. ROM\nTD : Groupe 1\nSalle : P202 CRIT - P202 CRIT.RESEAUX\nMémo : TP2 GPR1\n
|
||||
X-ALT-DESC;FMTTYPE=text/html:Matière : VCYR303 - Services reseaux ava (VCYR303)<br/>Enseignant : 1234 - M. VIENNET EMMANUEL<br/>Promotion : V2ROM - BUT2 RT pa. ROM<br/>TD : Groupe 1<br/>Salle : P202 CRIT - P202 CRIT.RESEAUX<br/>Mémo : TP2 GPR1<br/>
|
||||
END:VEVENT
|
||||
```
|
||||
|
||||
On a ici:
|
||||
|
||||
- identifiant de la formation: dans le nom du fichier calendrier (ici `V2CYB.ics`);
|
||||
- identifiant du groupe: dans `SUMMARY`, `* - <groupe>`
|
||||
- identifiant du module: on a le code `VCYR303` à trois endroits: `SUMMARY`,
|
||||
`DESCRIPTION`, `X-ALT-DESC`.
|
||||
- identifiant de l'enseignant: ici `1234`, présent dans `SUMMARY`, `DESCRIPTION` et `X-ALT-DESC`.
|
||||
|
||||
## Extraction des identifiants: semestres, groupes, modules, enseignants
|
||||
|
||||
La page de configuration globale, accessible uniquement au super-admin, permet
|
||||
d'indiquer comment ScoDoc doit extraire les identifiants du calendrier:
|
||||
|
||||
![Configuration des expressions régulières d'extraction](screens/edt-config-regexps.png)
|
||||
|
||||
|
||||
## Configuration des identifiants EDT dans ScoDoc
|
||||
|
||||
On a vu plus haut comment ScoDoc extrayait les identifiants de groupes, modules
|
||||
et enseignants des évènements calendrier. Mais ces identifiants ne sont pas
|
||||
toujours les mêmes que ceux utilisés dans ScoDoc, par exemple parce que les deux
|
||||
logiciels n'ont pas été configurés par le même service ou à des moments
|
||||
différents. Ainsi, il arrive qu'un groupe soit nommé "TD A" dans l'emploi du
|
||||
temps et "TDA" dans ScoDoc.
|
||||
|
||||
Chaque objet ScoDoc a donc un champs spécial "identifiant EDT" (pour *emploi du
|
||||
temps) que l'on peut renseigner.
|
||||
|
||||
### Semestres
|
||||
|
||||
L'identifiant `edt_id` (utilisé pour trouver le fichier calendrier) du semestre
|
||||
devra être renseigné pour chaque semestre sur la page `Semestre/Modifier le
|
||||
semestre`. À défaut, ScoDoc utilisera le premier code étape Apogée.
|
||||
|
||||
![Configuration de l'edt_id](screens/edt-config-edt_id.png)
|
||||
|
||||
### Groupes d'étudiants
|
||||
|
||||
Les identifiants de groupe sont édités sur la page **Groupes / Modifier groupes
|
||||
et partitions**.
|
||||
|
||||
Pour faciliter la mise en correspondance, la page d'aide à la configuration de
|
||||
l'emploi du temps (lien accessible sous le calendrier) permet de lister les
|
||||
identifiants de groupes utilisés de part et d'autre.
|
||||
|
||||
Dans l'exemple ci-dessous, on voit que de nombreux évènements du calendrier ne sont
|
||||
pas associés à un groupe reconnu ("STAGE", "START CAMPUS", etc.). ScoDoc les
|
||||
attribuera automatiquement à l'ensemble de la promotion (groupe "tous").
|
||||
|
||||
On voit aussi que les groupes ne sont pas reconnus car ils ne sont pas nommés de
|
||||
la même façon dans l'emploi du temps (ici généré par HyperPlanning) et dans
|
||||
ScoDoc: ainsi, le "TD A" de l'emploi du temps est nommé "TDA" dans ScoDoc.
|
||||
Nous indiquons ci-dessous comment corriger cela.
|
||||
|
||||
![Exemple configuration groupes EDT](screens/edt-config-groupes-1.png)
|
||||
|
||||
Pour modifier les identifiants EDT de groupe, on peut renommer les groupes
|
||||
ScoDoc ou, si on souhaite conserver les noms, indiquer le nom de l'emploi du
|
||||
temps. Passer par la page **Groupes / Modifier groupes et partitions**:
|
||||
|
||||
![Modification des noms de groupes](screens/edt-edit-partitions-1.png)
|
||||
|
||||
et cliquer sur le "crayon" d'édition du groupe, par exemple pour indiquer que le
|
||||
"TDA" de ScoDoc est appelé "TD A" dans l'emploi du temps:
|
||||
|
||||
![Modification des noms de groupes](screens/edt-edit-partitions-2.png)
|
||||
|
||||
|
||||
### Modules
|
||||
|
||||
ScoDoc peut utiliser plusieurs codes, dans cet ordre:
|
||||
|
||||
1. identifiant EDT du module du semestre;
|
||||
2. code Apogée du module du semestre (renseigné si ce code est différent de
|
||||
celui indiqué dans la formation, ce qui est rare);
|
||||
3. code Apogée du module dans la formation.
|
||||
|
||||
Dans la plupart des cas, l'emploi du temps utilise le code Apogée et il n'y a
|
||||
aucune configuration à faire (si vous avez déjà renseigné les codes Apogée dans
|
||||
ScoDoc).
|
||||
|
||||
Pour éditer les identifiants et codes Apogée du semestre, passer par la page
|
||||
**Modifier les codes Apogée et emploi du temps des modules**, lien placé sur la
|
||||
page **Semestre / Modifier le semestre**:
|
||||
|
||||
![Configuration des codes modules](screens/edt-config-codes-modules.png)
|
||||
|
||||
### Enseignants
|
||||
|
||||
Les évènements de calendrier peuvent indiquer des enseignants (le chargé de
|
||||
cours, ...), ce qui permettra à ScoDoc de proposer à l'utilisateur les plages le
|
||||
concernant. L'identifiant est là aussi variable selon les logiciels et les
|
||||
établissements (il peut s'agir de l'adresse mail, d'un numéro, etc.).
|
||||
|
||||
L'utilisateur ScoDoc a un identifiant EDT, que l'on peut spécifier sur la page
|
||||
d'édition du compte (avec les droits super-admin):
|
||||
![Config compte utilisateur](screens/edt-config-user.png)
|
||||
|
||||
Cet identifiant peut aussi être extrait automatiquement des informations
|
||||
renvoyées par le CAS quand il est utilisé. Pour cela, indiquer l'expression
|
||||
d'extraction sur la page de configuration du service CAS.
|
||||
|
||||
![Configuration extraction uid](screens/edt-config-cas-userid.png)
|
||||
|
||||
## Problèmes fréquents (FAQ)
|
||||
|
||||
- Les évènements sont tous attribués à a promotion et non à leur groupe de TD
|
||||
(ou TP, etc): vérifier le paramétrage de l'extraction du groupe et la
|
||||
correspondance entre groupes emplois du temps et groupes ScoDoc.
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- Emplois du temps: [doc développeurs](DevAbsencesCalendrier.md)
|
||||
- [Contacts](Contact.md)
|
106
docs/Evaluation.md
Normal file
106
docs/Evaluation.md
Normal file
@ -0,0 +1,106 @@
|
||||
# Les évaluations
|
||||
|
||||
On appelle dans ScoDoc "évaluation" toute action pédagogique produisant une
|
||||
note. Les notes sont des nombres positifs ou nuls (exceptés les "notes" de malus
|
||||
qui peuvent être négatives).
|
||||
|
||||
## Définition d'une évaluation
|
||||
|
||||
- **Description**: texte libre, qui sera affiché sur certains bulletins.
|
||||
- **Barème**: note maximale $M$. Les valeurs seront saisies dans l'intervalle $[0, M]$.
|
||||
Les notes affichées sont toujours ramenées sur 20.
|
||||
- **Date, heures de début et fin** de la réalisation de l'évaluation. Si les
|
||||
étudiants ne sont pas tous évalués en même temps (exemple: note de TP de
|
||||
différents groupes), on peut ne pas indiquer de date (la possibilité de
|
||||
définir plusieurs dates est à l'étude pour une version future).
|
||||
- **Visible sur bulletins**: indique si l'évaluation et la note de l'étudiant doit
|
||||
être affichée sur les bulletins au format dit "intermédiaire" (ni cours, ni
|
||||
long). C'est le format utilisé par la passerelle. La note reste prise en
|
||||
compte dans les moyennes même si l'évaluation n'est pas affichée.
|
||||
- **Prise en compte immédiate**: si coché, les notes saisies dans l'évaluation
|
||||
seront prises en compte dans le calcul des moyennes avant même que les notes
|
||||
de tous les étudiants ne soit saisies. Ne pas utiliser pour les évaluations de
|
||||
rattrapage ou de deuxième session (qui sont prises en compte quand elles
|
||||
existent).
|
||||
|
||||
### Pourquoi éviter d'utiliser "prise en compte immédiate" ?
|
||||
|
||||
Il est tentant de positionner toutes les évaluations en "*prise en compte
|
||||
immédiate*", parce que cela permet de communiquer leurs résultats aux étudiants
|
||||
sans attendre. Ce n'est pourtant pas une bonne idée, car:
|
||||
|
||||
- cela complique l'harmonisation: si on a plusieurs correcteurs, et que le second
|
||||
se rend compte d'une erreur de barème, il sera trop tard pour corriger sans
|
||||
informer les étudiants;
|
||||
- cela augmente le risque d'oubli ou de négligence (tout devrait être fait pour
|
||||
que les collègues corrigent et saisissent leurs notes rapidement);
|
||||
- en note manquante dans une évaluation "immédiate" est considérée comme "en
|
||||
attente": cela bloque la tenue du jury pour ces étudiants.
|
||||
|
||||
Ce réglage peut-être être contre-productif, voire nuisible si les notes sont
|
||||
montrées aux étudiants avant qu'elles soient définitives: il devrait rester
|
||||
réservé à des cas particuliers.
|
||||
|
||||
## Coefficient et poids
|
||||
|
||||
Le coefficient est utilisé pour pondérer les notes de l'évaluation afin de
|
||||
calculer la moyenne au module.En BUT, les poids modulent l'importance de
|
||||
l'évaluation dans chaque UE. Voir la page [calcul des notes](CalculNotes.md).
|
||||
|
||||
## État d'une évaluation
|
||||
|
||||
Une évaluation dans laquelle tous les étudiants inscrits au module ont une note
|
||||
est dite *complète*. Elle est alors prise en compte dans le calcul des moyennes
|
||||
et publiée sur les bulletins (selon les formats et réglages).
|
||||
|
||||
Si toutes les notes ne sont pas saisies, l'évaluation est dite *incomplète*, et
|
||||
n'est pas prise en compte *sauf* si l'option "Prise en compte immédiate" est
|
||||
activée.
|
||||
|
||||
Si toutes les notes sont saisies, mais certaines sont "en attente" (`ATT`),
|
||||
l'évaluation est dite *en attente*. Elle est prise en compte.
|
||||
|
||||
## Modalité d'une évaluation
|
||||
|
||||
- **Normale**: produit une note utilisée dans le calcul des moyennes du module.
|
||||
- **Deuxième session**: la note remplace, lorsqu'elle est saisie, la moyenne de
|
||||
l'étudiant à ce module, même si sa note de deuxième session est plus faible
|
||||
que sa moyenne normale.
|
||||
- **Rattrapage**: la note d'une évaluation de "rattrapage" remplacera la moyenne
|
||||
du module de l'étudiant *si et seulement si elle est meilleure que celles
|
||||
calculées*. S'il y a des évaluations de deuxième session, celles de
|
||||
rattrapage sont ignorées.
|
||||
- **Bonus**: la valeur est ajoutée à la moyenne du module, voir détail ci-dessous.
|
||||
|
||||
### Évaluations de "bonus"
|
||||
|
||||
Les évaluations bonus sont particulières:
|
||||
|
||||
- la valeur est ajoutée à la moyenne du module;
|
||||
- le bonus peut être négatif (malus);
|
||||
- le bonus s'applique après utilisation des notes de rattrapage ou de deuxième session;
|
||||
- le coefficient est ignoré, mais en BUT le bonus vers une UE est multiplié par le poids correspondant (par défaut égal à 1);
|
||||
- les notes de bonus sont prises en compte même si incomplètes.
|
||||
|
||||
Note 1: la conformité des évaluations au programme (coefficients vers les UEs) ne
|
||||
prend pas en compte les évaluations bonus.
|
||||
|
||||
## Bloquage et date de prise en compte
|
||||
|
||||
Ceci permet d'empêcher la prise en compte (et éventuellement la publication) de
|
||||
l'évaluation, même si ses notes sont complètes, ou bien de la différer jusqu'à
|
||||
la date indiquée. Cette fonctionnalité peut être utilisée
|
||||
|
||||
- temporairement pour ne pas communiquer trop tôt un résultat aux étudiants (on
|
||||
peut alors programmer la date de déblocage);
|
||||
- définitivement parce qu'on décide de ne pas tenir compte d'une évaluation,
|
||||
mais de garder ses résultats saisis.
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Les principaux objets de ScoDoc](IntroObjetsScoDoc.md)
|
||||
- [Calcul des notes](CalculNotes.md)
|
||||
- [Les évaluations et le BUT](BUT.md#creer-une-evaluation)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
155
docs/FAQ.md
155
docs/FAQ.md
@ -6,7 +6,7 @@
|
||||
|
||||
ScoDoc a été conçu et développé par Emmanuel Viennet, puis complété par
|
||||
plusieurs contributeurs, enseignants ou BIATSS dans les IUT et universités. Son
|
||||
développement est toujours actif, voir le dépôt git <https://scodoc.org/git>.
|
||||
développement est toujours actif, voir la plateforme gitea <https://git.scodoc.org>.
|
||||
|
||||
En 2020, une association a été créée pour soutenir et pérenniser le projet: par
|
||||
exemple pour acquérir services et équipements pour le développement
|
||||
@ -17,11 +17,6 @@ L'avenir du logiciel dépend donc de vous: adhérez, ou incitez votre institutio
|
||||
|
||||
## Utilisation de ScoDoc
|
||||
|
||||
### Comment prendre en compte les notes de sport ou autres bonus ?
|
||||
|
||||
Voir [CalculNotes](CalculNotes.md), ou bien
|
||||
[le tutoriel vidéo par Cédric C.](https://www.youtube.com/watch?v=SVbjuDpq-lI&list=PLw49h6RbvswhasBk9bXj7PzOD8GDW3kG1&index=13).
|
||||
|
||||
### Qui peut voir les notes, et quand ?
|
||||
|
||||
Tous les collègues (enseignants et administratifs) pouvant accéder au
|
||||
@ -33,31 +28,26 @@ notes des étudiants inscrits à cette évaluation sont saisies, soit parce qu'i
|
||||
s'agit d'une évaluation avec "prise en compte immédiate".
|
||||
|
||||
Les **étudiants n'ont pas accès à ScoDoc**, et ne peuvent donc pas voir leurs
|
||||
notes, sauf si une interface spécifique est configurée ("portail", avec
|
||||
notes, sauf si une interface spécifique est configurée ("passerelle", avec
|
||||
affichage sur leur ENT en général, cet affichage pouvant être désactivé depuis
|
||||
ScoDoc pour un semestre particulier). A défaut, il faut leur envoyer leurs
|
||||
bulletins par mail.
|
||||
|
||||
### Comment supprimer une évaluation ?
|
||||
### Comment les étudiants peuvent-ils accéder aux résultats ?
|
||||
|
||||
1. Supprimer toutes les notes saisies dans cette évaluation, s'il y en a: passer
|
||||
par la page "Saisie des notes" et suivre le lien "Effacer toutes les notes de
|
||||
cette évaluation".
|
||||
Les **étudiants n'ont pas accès à ScoDoc**, mais un composant "satellite",
|
||||
installé séparément peut fournir à chacun ses résultats (bulletins de notes,
|
||||
absences): il s'agit de [la passerelle développée par Sébastien Lehman](https://github.com/SebL68/Scodoc_Notes).
|
||||
|
||||
2. Lorsqu'il n'y a plus de notes, une croix rouge apparait sur le tableau de
|
||||
bord du module: cliquer dessus pour supprimer l'évaluation.
|
||||
### Comment signaler un problème ?
|
||||
|
||||
Nous vous remercions de nous signaler tous les problèmes que vous rencontrez:
|
||||
erreurs, comportement bizarre ou malcommode. Nous ne promettons pas de les
|
||||
régler rapidement, ni même plus tard: le logiciel est fourni sans aucune
|
||||
garantie. Mais nous faisons de notre mieux: joindre le canal Discord
|
||||
Assistance (voir [Contact](Contact.md))
|
||||
|
||||
### En IUT, comment gérer les licences professionnelles ?
|
||||
|
||||
* On peut créer un département regroupant les licences, ou bien rattacher
|
||||
chaque licence à un département existant. Cette dernière solution est
|
||||
préférable si des étudiants de DUT poursuivent en licence (ainsi, on a
|
||||
automatiquement accès à leur parcours complet).
|
||||
|
||||
* La plupart des licences pro durent un an, mais sont gérées comme un seul
|
||||
semestre (pas de jury à mi-parcours). Indiquer "*pas de semestre*" dans
|
||||
l'option "*Semestre dans la formation*" (page "*modification du semestre*").
|
||||
## La gestion des étudiants
|
||||
|
||||
### Comment gérer les étudiants les démissionnaires ?
|
||||
|
||||
@ -81,6 +71,108 @@ Ou bien au niveau de son inscription dans un semestre, via le menu *Scolarité*:
|
||||
abandonne en tout début d'année (il ne sera alors pas compté dans les
|
||||
inscrits).
|
||||
|
||||
## Les notes
|
||||
|
||||
### Comment prendre en compte les notes de sport ou autres bonus/malus ?
|
||||
|
||||
Voir [la page dédiée](BonusMalus.md), ou bien pour les bonus sport
|
||||
[le tutoriel vidéo par Cédric C.](https://www.youtube.com/watch?v=SVbjuDpq-lI&list=PLw49h6RbvswhasBk9bXj7PzOD8GDW3kG1&index=13).
|
||||
|
||||
|
||||
### Comment supprimer une évaluation ?
|
||||
|
||||
1. Supprimer toutes les notes saisies dans cette évaluation, s'il y en a: passer
|
||||
par la page "Saisie des notes" et suivre le lien "Effacer toutes les notes de
|
||||
cette évaluation".
|
||||
|
||||
2. Lorsqu'il n'y a plus de notes, une croix rouge apparait sur le tableau de
|
||||
bord du module: cliquer dessus pour supprimer l'évaluation.
|
||||
|
||||
### Passage de formation initiale à apprentissage
|
||||
|
||||
Après quelques semaines, il arrive de basculer un étudiant de formation initiale
|
||||
pour l'inscrire en apprentissage, ou l'inverse.
|
||||
|
||||
En général les évaluations ne sont pas exactement les mêmes dans les deux
|
||||
modalités, et parfois (souvent) l'adaptation locale diffère (coefficients, choix
|
||||
des ressources/SAE). Pour ces raisons, ScoDoc ne peut pas automatiquement
|
||||
recopier les notes d'un semestre à l'autre. Vous devez, au cas par cas, le faire
|
||||
manuellement.
|
||||
|
||||
Bon à savoir: quand on désincrit un étudiant d'un semestre, cela n'efface pas
|
||||
ses notes: si on réinscrit l'étudiant au même semestre, il retrouve magiquement
|
||||
ses notes: utile si on a oublié de le recopier avant de le désinscrire.
|
||||
|
||||
## Les formations
|
||||
|
||||
### Quelles formations peuvent être gérées par ScoDoc
|
||||
|
||||
Toutes les formations notées peuvent bénéficier de ScoDoc.
|
||||
|
||||
De nombreuses fonctions spécialisées sont consacrées au Bachelor Universitaire
|
||||
de technologie et son approche par compétences (APC) particulière.
|
||||
|
||||
ScoDoc est utilisé pour de nombreuses licences professionnelles, masters,
|
||||
formations d'ingénieurs.
|
||||
|
||||
### Le Bachelor Universitaire de Technologie
|
||||
|
||||
ScoDoc étant très utilisé en IUT, il offre de nombreuses fonctions dédiées au
|
||||
BUT. Voir notamment [le principe du calcul des notes en BUT](BUT.md) et [un exemple de
|
||||
modélisation de la spécialité BUT Informatique](BUTExempleInfo.md).
|
||||
|
||||
### En IUT, comment gérer les licences professionnelles ?
|
||||
|
||||
* On peut créer un département regroupant les licences, ou bien rattacher
|
||||
chaque licence à un département existant. Cette dernière solution est
|
||||
préférable si des étudiants de DUT poursuivent en licence (ainsi, on a
|
||||
automatiquement accès à leur parcours complet).
|
||||
|
||||
* La plupart des licences pro durent un an, mais sont gérées comme un seul
|
||||
semestre (pas de jury à mi-parcours). Indiquer "*pas de semestre*" dans
|
||||
l'option "*Semestre dans la formation*" (page "*modification du semestre*").
|
||||
|
||||
* les "nouvelles" licences pro en "blocs de compétences" ne sont pas encore
|
||||
entièrement prises en charge par ScoDoc. Utiliser par exemple "Licence pro en un
|
||||
semestre 2014" et calculer vous-même les moyennes de blocs non proposées par
|
||||
ScoDoc.
|
||||
|
||||
## Les jurys
|
||||
|
||||
### Les ECTS ne s'affichent pas
|
||||
|
||||
Les ECTS sont attribués (ou pas) au moment de la saisie de la décision de jury
|
||||
sur les UEs. Avant le jury, l'étudiant n'a jamais d'ECTS, quelles que soient ses
|
||||
notes.
|
||||
|
||||
### Comment identifier les ECTS ?
|
||||
|
||||
Les ECTS sont toujours liés aux Unités d'Enseignement (UE). Toute validation
|
||||
d'UE apporte à l'étudiant son quota d'ECTS. Cette quantité est définie dans le
|
||||
programme de la formation.
|
||||
|
||||
Les UEs peuvent être validées par le jury d'un semestre: le compte est affiché
|
||||
sur une colonne à droite du tableau **Jury / Voir les décisions de jury**.
|
||||
|
||||
### L'étudiant n'est pas diplômé
|
||||
|
||||
Vérifiez qu'il a bien obtenu tous ces ECTS.
|
||||
Si ce n'est pas le cas, vérifiez qu'il a bien validé toutes les UEs de son
|
||||
parcours de formation (BUT), ou un nombre suffisant de celles ci.
|
||||
|
||||
### Comment voir toutes les validations de jury d'un étudiant ?
|
||||
|
||||
Dans certains cas, on souhaite vérifier tout le détail des validations de jury
|
||||
enregistrées pour un étudiant. Pour cela, aller sur sa fiche et suivre le lien
|
||||
*Éditer toutes décisions de jury*. Vous aurez le détail de tous les éléments
|
||||
validés (UE, RCUEs du BUT, semestres des formations LMD, années du BUT, ...) et
|
||||
pourrez même les supprimer une à une (si vous disposez des droits d'accès nécessaires.)
|
||||
|
||||
Voir aussi [guide du responsable de formation](GuideAdminFormation.md#jurys)
|
||||
et [les jurys de BUT](BUTJurys.md).
|
||||
|
||||
## Administration système
|
||||
|
||||
### Mes données sont erronées, que faire ?
|
||||
|
||||
En cas de problème (bug, erreur de manipulation, suspicion de piratage),
|
||||
@ -99,21 +191,6 @@ Les utilisateurs autorisés peuvent facilement voir:
|
||||
Les administrateurs (informaticiens) peuvent aussi consulter les journaux (logs)
|
||||
du serveur, voir ["où sont les journaux"](#ou-sont-les-journaux-logs).
|
||||
|
||||
### Comment signaler un problème ?
|
||||
|
||||
Nous vous remercions de nous signaler tous les problèmes que vous rencontrez:
|
||||
erreurs, comportement bizarre ou malcommode. Nous ne promettons pas de les
|
||||
régler rapidement, ni même plus tard: le logiciel est fourni sans aucune
|
||||
garantie. Mais nous faisons de notre mieux:
|
||||
|
||||
* si vous êtes utilisateurs, écrire à
|
||||
[notes@listes.univ-paris13.fr](mailto:notes@listes.univ-paris13.fr).
|
||||
ou joindre le canal Discord Assistance.
|
||||
|
||||
* si vous êtes informaticien et voulez évoquer un problème technique
|
||||
(développement, installation), écrire à
|
||||
[scodoc-devel@listes.univ-paris13.fr](mailto:scodoc-devel@listes.univ-paris13.fr).
|
||||
|
||||
## Configuration
|
||||
|
||||
### Comment changer les logos sur les documents PDF (PV...)
|
||||
@ -129,7 +206,7 @@ Voir [la page sur la gestion des logos et images](GestionLogos.md).
|
||||
ScoDoc est accessible depuis n'importe quel navigateur Web (Firefox, Chrome, ...).
|
||||
|
||||
Le serveur ScoDoc fonctionne sous Linux. Il n'est testé qu'avec Debian (stable).
|
||||
Le script d'installation ([GuideInstallDebian11](GuideInstallDebian11.md))
|
||||
Le script d'installation ([GuideInstallDebian12](GuideInstallDebian12.md))
|
||||
assure l'installation de tout les éléments nécessaires au bon fonctionnement de
|
||||
ScoDoc.
|
||||
|
||||
|
119
docs/FichiersJustificatifs.md
Normal file
119
docs/FichiersJustificatifs.md
Normal file
@ -0,0 +1,119 @@
|
||||
<!-- markdownlint-disable MD024 -->
|
||||
# Gestions des fichiers justificatifs pour le module Assiduité
|
||||
|
||||
Le fonctionnement de l'importation / lecture des fichiers justificatifs est légèrement plus complexe que l'utilisation de l'API seule. Voici les différentes informations à savoir pour correctement utiliser les fichiers justificatifs.
|
||||
|
||||
Afin de bien comprendre les différentes informations, merci de lire d'abord la documentation de l'API Assiduité : [Documentation Assiduité](ScoDoc9API.md#api-assiduite)
|
||||
|
||||
## Importer un fichier
|
||||
|
||||
L'importation d'un fichier pour un justificatif se fait en deux temps :
|
||||
|
||||
* Créer un nouvel objet justificatif à l'aide de l'API
|
||||
* Envoyer le fichier sur le serveur ScoDoc
|
||||
|
||||
### Envoyer le fichier sur le serveur ScoDoc
|
||||
|
||||
Dans un premier temps il faut créer un objet justificatif à l'aide de l'API.
|
||||
|
||||
Dans un second temps il faut envoyer le fichier sur le serveur à l'aide d'une requête `POST`.
|
||||
|
||||
#### Exemple en Python
|
||||
|
||||
##### Script d'envoi du justificatif
|
||||
|
||||
> `token` est le même token que pour le reste de l'API
|
||||
|
||||
```py
|
||||
data = {
|
||||
"etat": "attente",
|
||||
"date_debut": "2022-10-27T08:00",
|
||||
"date_fin": "2022-10-27T12:00",
|
||||
}
|
||||
# la route de l'api est : /justificatif/<etudid:int>/create
|
||||
r = requests.post(API_URL + "/justificatif/123/create", json=data, headers=token)
|
||||
print(r.json)
|
||||
```
|
||||
|
||||
##### Réponse
|
||||
|
||||
```json
|
||||
{
|
||||
"justif_id" : 424242
|
||||
}
|
||||
```
|
||||
|
||||
##### Script d'envoi du fichier
|
||||
|
||||
> `token` est le même token que pour le reste de l'API
|
||||
|
||||
```py
|
||||
with open('exemple.txt', 'rb') as f:
|
||||
# la route pour importer est : api/justificatif/<justif_id:int>/import
|
||||
r = requests.post(API_URL + "/justificatif/424242/import", files={"exemple.txt": f}, headers=token)
|
||||
print(r.json)
|
||||
```
|
||||
|
||||
##### Réponse
|
||||
|
||||
```json
|
||||
{
|
||||
"filename" : "exemple.txt"
|
||||
}
|
||||
```
|
||||
|
||||
Veillez à bien noter le nom de fichier renvoyé car c'est le nom coté "server", il sera à utiliser lors que vous souhaitez récupérer le fichier
|
||||
ou lorsque vous voudrez le supprimer
|
||||
|
||||
## Télécharger un fichier
|
||||
|
||||
Pour télécharger un fichier de justificatif rien de plus simple
|
||||
|
||||
### Une simple requête POST
|
||||
|
||||
* **Méthode:** POST
|
||||
* **Permission: `ScoView`**
|
||||
* **Paramètres:**
|
||||
* `justif_id`
|
||||
* `filename`
|
||||
* **Routes:** `/justificatif/<justif_id:int>/export/<filename>`
|
||||
* **Exemple d'utilisation:** `/api/justificatif/424242/export/exemple.txt`
|
||||
* **Résultat:** télécharge directement le fichier
|
||||
|
||||
## Supprimer un fichier
|
||||
|
||||
Pour supprimer un fichier il suffit d'envoyer une requête post sur le justificatif, avec un json correct
|
||||
|
||||
### Script de suppression du fichier
|
||||
|
||||
> `token` est le même token que pour le reste de l'API
|
||||
|
||||
```py
|
||||
# la route pour supprimer est : api/justificatif/<justif_id:int>/remove
|
||||
|
||||
d = {
|
||||
|
||||
"remove": "list",
|
||||
"filenames": [
|
||||
"exemple.txt"
|
||||
]
|
||||
}
|
||||
|
||||
# ou
|
||||
|
||||
d = {
|
||||
|
||||
"remove": "al",
|
||||
}
|
||||
|
||||
r = requests.post(API_URL + "/justificatif/424242/remove", data=d, headers=token)
|
||||
print(r.json)
|
||||
```
|
||||
|
||||
#### Réponse
|
||||
|
||||
```json
|
||||
{
|
||||
"response" : "removed"
|
||||
}
|
||||
```
|
221
docs/Formations.md
Normal file
221
docs/Formations.md
Normal file
@ -0,0 +1,221 @@
|
||||
# Programmes pédagogiques et versions
|
||||
|
||||
Le programme pédagogique, appelé *formation* dans ScoDoc, défini les unités
|
||||
d'enseignement; il est destiné à être utilisé par plusieurs sessions de
|
||||
formation (semestres). On doit apporter un soin particulier à la définition du
|
||||
programme, et éviter de le modifier une fois que des semestres sont créés (il
|
||||
est toutefois possible d'en créer de nouvelles *versions* pour permettre des
|
||||
modifications ultérieures sans affecter les semestres achevés: voir plus bas.
|
||||
|
||||
Le programme pédagogique définit notamment les coefficients des modules qui le
|
||||
composent. Les semestres qui se réfèrent à ce programme utilisent ces
|
||||
coefficients pour calculer leurs notes. De même, les noms de UE et modules qui
|
||||
apparaissent sur les bulletins viennent du programme. Il faut être
|
||||
particulièrement vigilant lors des modifications du programme pédagogique.
|
||||
|
||||
Dans la configuration par défaut, seul le chef de département (rôle Admin) peut
|
||||
modifier les programmes pédagogiques.
|
||||
|
||||
(voir aussi des exemples de programmes en bas de la page
|
||||
[GuideAdminFormation](GuideAdminFormation.md)).
|
||||
|
||||
## Structure d'un programme pédagogique
|
||||
|
||||
On définira en général dans le programme l'ensemble des enseignements d'un
|
||||
diplôme (les 4 semestres d'un DUT par exemple). C'est dans une phase ultérieure
|
||||
que l'on mettra en place les différents semestres.
|
||||
|
||||
Les programmes pédagogiques ScoDoc sont structurés en Unités d'Enseignements
|
||||
(UE), Matières et Modules. Un module appartient forcément à une matière, qui
|
||||
appartient elle même à une UE. Les modules (déclinés en *ressources*, *SAÉs* en
|
||||
BUT) représentent les cours ("mathématique", "anglais", ...) et sont associés à
|
||||
un volume horaire (cours/TD/TP) et à un coefficient: chaque module produit une
|
||||
note moyenne (en général obtenue à travers plusieurs *évaluations* ou
|
||||
contrôles). La note moyenne d'une UE est obtenue en calculant une moyenne
|
||||
pondérée par les coefficients des notes moyennes de modules.
|
||||
|
||||
🚸 En BUT, c'est un peu différent, puisque les modules ont une note *pour chaque
|
||||
UE*: la moyenne d'un module n'est pas définie. Voir [BUT](BUT.md)
|
||||
|
||||
### Unités d'Enseignement (UE)
|
||||
|
||||
Les UE jouent un rôle particulier dans l'évaluation. En effet, selon les règles
|
||||
du LMD, les UE sont *capitalisables* (voir
|
||||
[CapitalisationUE](CapitalisationUE.md)). De plus, l'obtention de droit des
|
||||
semestres d'un DUT est soumise à une moyenne supérieure à 8/20 dans chacune des
|
||||
UE.
|
||||
|
||||
Notons qu'une UE ne possède pas de coefficient. Le coefficient d'une UE n'est
|
||||
autre que la somme des coefficient des modules qui composent cette UE. Par
|
||||
conséquent, le coefficient d'UE est potentiellement variable d'un étudiant à
|
||||
l'autre, si les étudiants ne sont pas inscrits aux mêmes modules (options ou
|
||||
parcours).
|
||||
|
||||
Note: une formation en plusieurs semestres devrait normalement avoir des UEs
|
||||
différentes dans chaque semestre.
|
||||
|
||||
* Il est parfois désirable de capitaliser au sein d'un parcours des UE
|
||||
appartenant à deux programmes ScoDoc différents (par exemple, on peut avoir
|
||||
changé de version du programme entre deux semestres, comme expliqué plus
|
||||
loin). Dans ce cas, il faut attribuer aux programmes le même code de formation
|
||||
(via le lien "modifier" sur la page d'accueil des programmes), et aussi
|
||||
attribuer les mêmes codes aux UE (via le lien "modifier l'UE" sur la page
|
||||
"programme détaillé et semestres").
|
||||
|
||||
* Les UE peuvent être de type "normal" ou "Sport&Culture". Ces dernières ne sont
|
||||
utilisées que pour les notes optionnelles (activités culturelles et sportives)
|
||||
utilisée dans certains établissements. Elles se voient attribuer une règle de
|
||||
calcul spécifique qui dépend généralement de l'établissement (il n'y à pas de
|
||||
règle nationale pour la prise en compte des notes de sport et culture).
|
||||
Typiquement, la note des UE de ce type spécial agit directement sur la moyenne
|
||||
générale de l'étudiant.
|
||||
|
||||
### Matières
|
||||
|
||||
Les matières n'ont pas d'autre utilité que d'aider à structurer le programme.
|
||||
Par exemple, on pourrait définir dans un programme une matière "Sciences"
|
||||
réunissant les modules de "mathématiques" et de "physique". Les matières n'ont
|
||||
pas de coefficient. Si l'on ne souhaite pas utiliser de matière, il suffit d'en
|
||||
créer une pour chaque module avec le même nom, ou au contraire (plus simplement)
|
||||
de créer une matière par UE et d'y placer tous les modules.
|
||||
|
||||
Note: les matières ne sont pas utilisées en BUT.
|
||||
|
||||
### Modules
|
||||
|
||||
* Le *code* du module va apparaitre sur les bulletins et certains tableaux
|
||||
récapitulatifs. Il comporte habituellement quelques caractères (comme "MATH",
|
||||
ou "SPO"). Si la version officielle de votre programme pédagogique n'utilise
|
||||
pas de codes de ce genre, inventez des codes à la fois courts (pas plus de 4
|
||||
ou 5 caractères) et évocateurs du nom du module.
|
||||
|
||||
* Le *titre* du module apparaitra sur le tableau de bord du semestre et sur les
|
||||
bulletins.
|
||||
|
||||
* L' *abréviation* est une version courte du titre. Si le titre n'est pas trop
|
||||
long (3 ou 4 mots), copier le. Sinon, inventer une abréviation en quelques
|
||||
mots qui soit lisible.
|
||||
|
||||
* Les volumes horaires ne sont présents que pour information et ne sont
|
||||
actuellement pas du tout utilisés par ScoDoc: il est donc facultatif de les
|
||||
indiquer.
|
||||
|
||||
* Le coefficient est utilisé pour le calcul de la moyenne d'UE et de la moyenne
|
||||
générale. Il s'agit d'un nombre réel positif ou nul.
|
||||
|
||||
* Choisir dans le menu la *matière* à laquelle appartient le module.
|
||||
|
||||
* Le semestre est un nombre indiquant dans quel semestre de la formation se
|
||||
place habituellement ce module. Il arrive que l'on décline la même formation
|
||||
selon différentes modalités (formation initiale, continue) avec des placements
|
||||
différents: dans ce cas, indiquer le semestre dans la modalité "habituelle";
|
||||
lors de la mise en place d'un semestre, on peut choisir manuellement des
|
||||
modules de tous les semestres.
|
||||
|
||||
### Ordre d'affichage des UE, matières et modules
|
||||
|
||||
Chaque élément (UE, matières et modules) possède un attribut *numéro* qui est un
|
||||
nombre entier utilisé pour le classement des éléments de même niveau dans la
|
||||
hiérarchie dans les tableaux et bulletins.
|
||||
|
||||
Il est conseillé d'attribuer les numéros de 10 en 10 afin de pouvoir plus
|
||||
facilement insérer un nouvel élément entre deux éléments existants. Par exemple,
|
||||
si l'on a dans une matière trois modules MA, MB, MC, on va leur attribuer les
|
||||
numéros 10, 20 et 30.
|
||||
|
||||
## Verrouillage d'une formation
|
||||
|
||||
Lorsque au moins l'un des semestres qui se réfèrent à ce programme est
|
||||
*verrouillé*, il devient impossible de modifier le programme (la page de
|
||||
présentation du programme ne comporte alors aucun lien). Deux cas peuvent se
|
||||
présenter:
|
||||
|
||||
* il s'agit d'une modification mineure (intitulé d'un module, ...) ne risquant
|
||||
pas affecter les notes existantes, et il y a peu de semestres verrouillés:
|
||||
dans ce cas, il est possible d'aller déverrouiller un à un les semestres
|
||||
concernés, puis d'effectuer la modification du programme avant de
|
||||
re-verrouiller les semestres.
|
||||
|
||||
* il s'agit d'une modification conséquente, on ne ne veut pas affecter les
|
||||
semestres existants: on crée alors une nouvelle *version* du programme. La
|
||||
version crée est une copie à l'identique du programme existant, que l'on peut
|
||||
modifier à sa guise.
|
||||
|
||||
## Versions de formation
|
||||
|
||||
Chaque semestre ("FormSemestre" dans le jargon ScoDoc) se réfère à un programme
|
||||
pédagogique, appelé sa *formation*. cette formation définit l'ensemble des UE et
|
||||
modules, leurs intitulés, et leurs coefficients et ECTS.
|
||||
|
||||
Les programmes sont le plus souvent adaptés localement, et peuvent varier d'une
|
||||
année sur l'autre. Lorsqu'une formation est modifié (par exemple, un changement
|
||||
de coefficient), ScoDoc doit recalculer l'ensemble des notes de tous les
|
||||
semestres utilisant cette formation. De même, si un intitulé change, il faut
|
||||
re-générer les bulletins et procès-verbaux. On conçoit donc que la modification
|
||||
d'une formation ne s'aborde pas à la légère. ScoDoc empêche d'ailleurs toute
|
||||
modification d'une formation (ou partie de, selon les cas) lorsqu'un semestre a
|
||||
été verrouillé (ce qui indique en général qu'il est achevé et que l'on souhaite
|
||||
conserver ses données et résultats inchangés pour utilisation future dans des
|
||||
jurys ou avis).
|
||||
|
||||
Si vous devez modifier une formation pour la nouvelle année scolaire, vous
|
||||
pouvez créer une nouvelle version d'une formation existante afin d'éviter
|
||||
d'avoir à saisir de nouveau l'ensemble des éléments. Il arrive même que, l'année
|
||||
scolaire déjà commencée, on se rende compte que l'on doit modifier la formation
|
||||
d'un semestre en cours (bien sûr, cela ne devrait pas arriver, les modalités
|
||||
d'évaluation étant souvent votées par des instances officielles avant le début
|
||||
de l'année, mais le monde n'est pas parfait et de petites corrections sont
|
||||
parfois nécessaires). Dans ce cas, ScoDoc vous permet d'associer un ou plusieurs
|
||||
semestres existants dans une formation à une nouvelle version de celle-ci, créée
|
||||
par copie.
|
||||
|
||||
<img src="/screens/menu-formsemestre-assoc.png" alt="menu formsemestre" width="33%">
|
||||
|
||||
La figure suivante montre la distinction entre formations et semestres, et les opérations possibles:
|
||||
|
||||
![menu formsemestre](fig/formations_versions_association.jpg)
|
||||
|
||||
![association nouvelle version](fig/sem-assoc-formation.png)
|
||||
|
||||
## Évolution du programme d'une année sur l'autre
|
||||
|
||||
Imaginons que nous ayons les semestres S1, S2, S3, S4 dans un programme V1, et
|
||||
que l'année suivante une nouvelle version du programme entre en vigueur
|
||||
(adaptation locale, corrections diverses...).
|
||||
|
||||
Voici comment mettre en place les semestres de l'année suivante tout en
|
||||
conservant le maximum d'éléments (évaluation, choix des ressources et SAE).
|
||||
|
||||
1. Cloner (menu **Semestre / Cloner**)les semestres concernés (S1 à S4 ici)
|
||||
2. Prendre l'un des semestres copiés (peu importe laquelle), et suivre
|
||||
**Semestre / Associer à une nouvelle version**. Il est alors possible d'associer
|
||||
à cette nouvelle version (V2) les semestres: cochez les semestres créés à
|
||||
l'étape précédente.
|
||||
|
||||
Cette façon de procéder permet de limiter le nombre de nouvelles versions de
|
||||
formations créée.
|
||||
|
||||
<img src="/screens/formsemestre_associate_new_version.png" width="100%">
|
||||
|
||||
## Changement de la formation d'un semestre
|
||||
|
||||
Il peut arriver que l'on ai créé deux versions de formations, qui sont encore
|
||||
identique, et que l'on souhaite rattacher un formsemestre de l'une à l'autre.
|
||||
C'est possible, à condition que les deux formations soient vraiment identiques
|
||||
(mêmes UEs, titres, coefficients, etc). Le lien est accessible en bas de la page
|
||||
"Associer à une nouvelle version du programme" mentionnée ci-dessus.
|
||||
|
||||
![change formation](fig/sem-change-formation.png)
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Guide du responsable de formation](GuideAdminFormation.md)
|
||||
- [Guide utilisateur](GuideUtilisateur.md)
|
||||
- Pour le BUT: [le référentiel de compétence](BUTReferentielCompetences.md)
|
||||
- [Tutoriels vidéo](https://www.youtube.com/channel/UCb0JYCBRi0CsE4XFp4ByhXg)
|
||||
- [Gestion des UE Bonus](https://www.youtube.com/watch?v=SVbjuDpq-lI)
|
||||
- [Mise en place des parcours BUT](https://www.youtube.com/watch?v=OnuOXJo-3ro)
|
||||
- [Saisie des codes Apogée](https://www.youtube.com/watch?v=MW0nNhbBjDM)
|
||||
- [Du DUT au BUT: comment transformer un programme](https://www.youtube.com/watch?v=9HizGTvYgck)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
@ -1,5 +1,7 @@
|
||||
# Suivi des absences (version <= 9.4)
|
||||
|
||||
## Suivi des absences
|
||||
**Cette page se réfère l'ancien système de gestion des absences, remplacé en
|
||||
juillet 2023 (ScoDoc 9.5) par le nouveau module Assiduité.**
|
||||
|
||||
ScoDoc permet d'enregistrer les absences des étudiants.
|
||||
|
||||
@ -7,60 +9,91 @@ Les absences sont notées par demi-journées (matin ou après midi).
|
||||
|
||||
Elles peuvent être "justifiées" ou non.
|
||||
|
||||
Dans les pages concernant un étudiant, un cadre en bas à gauche permet de visualiser le compte d'absences (comptées en demi-journées) et de les visualiser sur un calendrier de l'année scolaire. On peut simplement ajouter, justifier ou supprimer une absence pour un étudiant.
|
||||
Dans les pages concernant un étudiant, un cadre en bas à gauche permet de
|
||||
visualiser le compte d'absences (comptées en demi-journées) et de les visualiser
|
||||
sur un calendrier de l'année scolaire. On peut simplement ajouter, justifier ou
|
||||
supprimer une absence pour un étudiant.
|
||||
|
||||
Une absence:
|
||||
|
||||
* correspond à une demi-journée durant laquelle l'étudiant a été noté absent;
|
||||
* peut être signalée plusieurs fois (ScoDoc ne la comptera qu'une fois).
|
||||
* correspond à une demi-journée durant laquelle l'étudiant a été noté absent;
|
||||
* peut être signalée plusieurs fois (ScoDoc ne la comptera qu'une fois).
|
||||
|
||||
Un justificatif:
|
||||
|
||||
* permet de signaler que l'absence est "excusée" (certificat médical...);
|
||||
* peut être saisi à n'importe quel moment, avant ou après le signalement de l'absence.
|
||||
* permet de signaler que l'absence est "excusée" (certificat médical...);
|
||||
* peut être saisi à n'importe quel moment, avant ou après le signalement de l'absence.
|
||||
|
||||
Les absences peuvent aussi être saisies pour tout un groupe d'étudiants via un formulaire adapté (voir le menu "Saisir absences" sur le tableau de bord du semestre).
|
||||
Les absences peuvent aussi être saisies pour tout un groupe d'étudiants via un
|
||||
formulaire adapté (voir le menu "Saisir absences" sur le tableau de bord du
|
||||
semestre).
|
||||
|
||||
Le compte des absences peut ou non figurer sur les bulletins de notes, suivant les réglages choisis (voir le menu "Préférences du semestre").
|
||||
Le compte des absences peut ou non figurer sur les bulletins de notes, suivant
|
||||
les réglages choisis (voir le menu "Préférences du semestre").
|
||||
|
||||
|
||||
### Notification par mail des absences
|
||||
## Notification par mail des absences
|
||||
|
||||
ScoDoc peut prévenir par email lorsqu'un étudiant a "trop d'absences".
|
||||
Peuvent être prévenus:
|
||||
|
||||
* le chef du département;
|
||||
* le responsable du semestre concerné (direction des études en IUT);
|
||||
* une autre adresse indiquée dans les paramètres (cela peut être une liste de diffusion, par exemple);
|
||||
* le responsable du module concerné par une évaluation dans laquelle un étudiant est signalé absent (voir plus bas).
|
||||
* le chef du département;
|
||||
* le responsable du semestre concerné (direction des études en IUT);
|
||||
* une autre adresse indiquée dans les paramètres (cela peut être une liste de diffusion, par exemple);
|
||||
* le responsable du module concerné par une évaluation dans laquelle un étudiant est signalé absent (voir plus bas).
|
||||
|
||||
Pour éviter d'inonder les utilisateurs de messages, plusieurs paramètres sont réglables:
|
||||
|
||||
* notifier les absences au chef (oui/non);
|
||||
* notifier les absences au dir. des études (oui/non);
|
||||
* notifier les absences aux resp. de modules (oui/non);
|
||||
* notifier les absences aux étudiants (individuellement);
|
||||
* autre adresse vers laquelle notifier;
|
||||
* fréquence maximale de notification N (un utilisateur ne recevra pas plus de 1 message tous les N jours, *par étudiant*);
|
||||
* seuil de première notification: nombre d'absences tolérées avant premier envoi de notification (comptées en demi-journées);
|
||||
* seuil notifications suivantes: une notifications toutes les *N* absences, après le premier seuil;
|
||||
* message notification e-mail (template modifiable).
|
||||
* notifier les absences au chef (oui/non);
|
||||
* notifier les absences au dir. des études (oui/non);
|
||||
* notifier les absences aux resp. de modules (oui/non);
|
||||
* notifier les absences aux étudiants (individuellement);
|
||||
* autre adresse vers laquelle notifier;
|
||||
* fréquence maximale de notification N (un utilisateur ne recevra pas plus de 1
|
||||
message tous les N jours, *par étudiant*);
|
||||
* seuil de première notification: nombre d'absences tolérées avant premier envoi
|
||||
de notification (comptées en demi-journées);
|
||||
* seuil notifications suivantes: une notifications toutes les *N* absences,
|
||||
après le premier seuil;
|
||||
* message notification e-mail (template modifiable, voir ci-dessous).
|
||||
|
||||
Ces paramètres peuvent être spécifiés globalement ou par semestre (comme pour la plupart des paramètres ScoDoc, voir [PreferencesScoDoc](PreferencesScoDoc.md)).
|
||||
Ces paramètres peuvent être spécifiés globalement ou par semestre (comme pour la
|
||||
plupart des paramètres ScoDoc, voir [PreferencesScoDoc](PreferencesScoDoc.md)).
|
||||
|
||||
### Contenu du mail de notification
|
||||
|
||||
Le contenu du mail de notification envoyé est défini par la préférence *Message
|
||||
notification e-mail*, qui peut contenir des balises remplacées, suivant
|
||||
l'ancienne syntaxe python `%(nom-balise)s`.
|
||||
|
||||
- `nbabs`: nombre d'absences
|
||||
- `nbabsjust`: nombre d'absences justifiées
|
||||
- `nbabsnonjust`: nombre d'absences non justifiées
|
||||
- `url_ficheetud`: URL de la fiche de l'étudiant (accessible seulement avec authentification)
|
||||
- `titre_mois`: titre et dates du semestre concerné (ex: "BUT R&T semestre 1 FI (Sept 2022 - Jan 2023)")
|
||||
|
||||
|
||||
*Absences aux évaluations*: lorsqu'une absence concerne potentiellement une évaluation, le responsable du module concerné peut être prévenu. Limitations: la résolution temporelle de l'absence est la demi-journée, une évaluation peut être plus courte; il appartient à l'enseignant de vérifier si l'étudiant était réellement absent lors de son évaluation (ou si la justification d'absence produite couvre bien sa plage horaire). Notons que ScoDoc se fonde sur la date de l'évaluation déclarée, pas sur l'emploi du temps (qui n'est pas géré par ScoDoc).
|
||||
*Absences aux évaluations*: lorsqu'une absence concerne potentiellement une
|
||||
évaluation, le responsable du module concerné peut être prévenu. Limitations: la
|
||||
résolution temporelle de l'absence est la demi-journée, une évaluation peut être
|
||||
plus courte; il appartient à l'enseignant de vérifier si l'étudiant était
|
||||
réellement absent lors de son évaluation (ou si la justification d'absence
|
||||
produite couvre bien sa plage horaire). Notons que ScoDoc se fonde sur la date
|
||||
de l'évaluation déclarée, pas sur l'emploi du temps (qui n'est pas géré par
|
||||
ScoDoc).
|
||||
|
||||
### Billets d'absences
|
||||
|
||||
### Billets d'absences
|
||||
Les "billets d'absences" sont issus d'une demande du département Informatique de l'IUT de Villetaneuse en 2009, et sont implémentés à titre expérimental.
|
||||
Les "billets d'absences" sont issus d'une demande du département Informatique de
|
||||
l'IUT de Villetaneuse en 2009, et sont implémentés à titre expérimental.
|
||||
|
||||
Le scénario d'utilisation est le suivant :
|
||||
|
||||
* l'étudiant absent remplit un formulaire web (sur le portail étudiant, donc hors ScoDoc) indiquant les dates (début et fin) de son absence et sa raison;
|
||||
* ce billet rempli est alors envoyé à ScoDoc et doté d'un numéro unique ;
|
||||
* il l'imprime et va au secrétariat porter cette impression du formulaire (faisant apparaitre le numéro) et le justificatif correspondant;
|
||||
* le secrétariat, quand il en a le temps, rentre le numéro de la fiche d'absence et a juste une case à cocher : justifié/non justifié.
|
||||
* l'étudiant absent remplit un formulaire web (sur le portail étudiant, donc
|
||||
hors ScoDoc) indiquant les dates (début et fin) de son absence et sa raison;
|
||||
* ce billet rempli est alors envoyé à ScoDoc et doté d'un numéro unique;
|
||||
* il l'imprime et va au secrétariat porter cette impression du formulaire
|
||||
(faisant apparaitre le numéro) et le justificatif correspondant;
|
||||
* le secrétariat, quand il en a le temps, rentre le numéro de la fiche d'absence
|
||||
et a juste une case à cocher : justifié/non justifié.
|
||||
|
||||
Voir détails techniques sur [ServicesXml](ServicesXml.md).
|
||||
|
||||
|
@ -1,8 +1,8 @@
|
||||
|
||||
|
||||
|
||||
|
||||
# Gestion des jurys DUT
|
||||
|
||||
# Gestion des jurys DUT
|
||||
La gestion des jury DUT s'est inspirée des travaux de J.F. Mazoin, de l'ADIUT (et en particulier du document présenté le 30 mai 2006).
|
||||
Nous utiliserons les codes suivant pour représenter les décisions de jury:
|
||||
|
||||
@ -10,7 +10,7 @@ Nous utiliserons les codes suivant pour représenter les décisions de jury:
|
||||
|
||||
Code |
|
||||
-----|-----
|
||||
ADM | semestre validé automatiquement
|
||||
ADM | semestre validé automatiquement
|
||||
ADC | semestre validé par compensation avec un autre
|
||||
ADJ | semestre validé par le jury
|
||||
ATT | pas la moyenne, barres UE ok: décision en attente du semestre suivant
|
||||
@ -38,9 +38,9 @@ Nous utiliserons les codes suivant pour représenter les décisions de jury:
|
||||
|
||||
- assiduité satisfaisante.
|
||||
|
||||
(Chaque semestre ne pouvant n'en compenser qu'un seul autre, nous sommes conscients que cette règle
|
||||
conduit à désavantager certains étudiants qui compensent, alors que le jury décide de valider le
|
||||
semestre à des étudiants plus faibles qui ne peuvent pas compenser et conserve donc cette possibilité
|
||||
(Chaque semestre ne pouvant n'en compenser qu'un seul autre, nous sommes conscients que cette règle
|
||||
conduit à désavantager certains étudiants qui compensent, alors que le jury décide de valider le
|
||||
semestre à des étudiants plus faibles qui ne peuvent pas compenser et conserve donc cette possibilité
|
||||
pour la suite de leur parcours...).
|
||||
|
||||
* **Codes d'état d'UE:**
|
||||
@ -51,17 +51,17 @@ ADM | UE validée automatiquement (moyenne UE >= 10) |
|
||||
CMP | UE validée (moyenne UE < 10, mais semestre validé) |
|
||||
AJ | UE ajournée (échec) |
|
||||
|
||||
Notons que le jury n'intervient pas sur les décisions d'UE: elles sont toujours prises
|
||||
*automatiquement* en fonction des notes (et enregistrées par ScoDoc lorsqu'on entre une
|
||||
Notons que le jury n'intervient pas sur les décisions d'UE: elles sont toujours prises
|
||||
*automatiquement* en fonction des notes (et enregistrées par ScoDoc lorsqu'on entre une
|
||||
décision de semestre).
|
||||
|
||||
* **Codes devenir:** (*internes à ScoDoc, donnés ici pour information*)
|
||||
|
||||
Code |
|
||||
-----|-----
|
||||
NEXT | passe au semestre suivant dans le cursus
|
||||
REO | réorienté (dans une autre filière, “exclus”)
|
||||
REDOANNEE | redouble annee (eg passe de S2 à S1)
|
||||
NEXT | passe au semestre suivant dans le cursus
|
||||
REO | réorienté (dans une autre filière, “exclus”)
|
||||
REDOANNEE | redouble annee (eg passe de S2 à S1)
|
||||
REDOSEM | redouble semestre (eg passe de S1 à S1 "décalé")
|
||||
|
||||
|
||||
@ -81,23 +81,23 @@ Le jury conduit à prendre les décisions suivantes:
|
||||
- décider du devenir de l'étudiant (passage, redoublement, réorientation) (“Devenir”).
|
||||
|
||||
|
||||
## Compensation des semestres
|
||||
## Compensation des semestres
|
||||
|
||||
Voir la page [CompensationSemestre](CompensationSemestre.md)
|
||||
|
||||
## Capitalisation des UEs
|
||||
|
||||
## Capitalisation des UE
|
||||
Voir la [ note sur la capitalisation des UE](CapitalisationUE)
|
||||
Voir la [note sur la capitalisation des UE](CapitalisationUE.md)
|
||||
|
||||
## Gestion des cas particuliers
|
||||
|
||||
## Gestion des cas particuliers
|
||||
Parcours du type: S1 (ADM), S2 (AJ), S3 (AJ), S3D (ATT), S2D
|
||||
|
||||
Il faut tenir le jury de S2D, puis revenir sur le jury de S3D qui va, si S2D est validé, recevoir le code ADM et autoriser le passage en S4.
|
||||
Il faut tenir le jury de S2D, puis revenir sur le jury de S3D qui va, si S2D est
|
||||
validé, recevoir le code ADM et autoriser le passage en S4.
|
||||
|
||||
## Document de préparation du jury
|
||||
|
||||
|
||||
|
||||
## Document de préparation du jury
|
||||
Il s'agit d'une simple feuille Excel récapitulant les informations
|
||||
essentielles pour tenir un jury:
|
||||
identité, parcours, moyennes et décisions des 2 derniers semestres.
|
||||
@ -107,19 +107,19 @@ des cas rares (étudiants ayant effectué le début de leur scolarité ailleurs,
|
||||
etc).
|
||||
|
||||
|
||||
## Procès verbaux de jury
|
||||
### PV de jury: récapitulatif complet des décisions de jury
|
||||
## Procès verbaux de jury
|
||||
### PV de jury: récapitulatif complet des décisions de jury
|
||||
Document signé par le directeur de l'IUT récapitullant l'ensemble des décisions
|
||||
pour un semestre de formation.
|
||||
|
||||
Il s'agit d'un document PDF en format paysage, à imprimer sur
|
||||
papier ordinaire A4.
|
||||
|
||||
Les logos (IUT en haut, université en pied de page) sont
|
||||
Les logos (IUT en haut, université en pied de page) sont
|
||||
paramétrables par l'utilisateur: voir [configuration des logos](GestionLogos.md).
|
||||
|
||||
|
||||
### Lettres d'avis individuelles
|
||||
### Lettres d'avis individuelles
|
||||
Courriers (papier) adressés aux étudiants pour les informer
|
||||
des décisions du jury.
|
||||
|
||||
@ -134,4 +134,4 @@ préalable celle d'Apogée).
|
||||
|
||||
On peut spécifier une image de la signature du responsable de formation pour
|
||||
lui éviter de fastidieuses séances de paraphage.
|
||||
|
||||
|
||||
|
@ -1,30 +1,41 @@
|
||||
# Gestion des photos des étudiants
|
||||
|
||||
## Gestion des photos des étudiants
|
||||
Une photo de chaque étudiant peut être stockée par ScoDoc. On peut aussi utiliser des photos externes (portail).
|
||||
Une photo de chaque étudiant peut être stockée par ScoDoc.
|
||||
|
||||
## Associer une photo à l'étudiant
|
||||
|
||||
### Associer une photo à l'étudiant
|
||||
#### Individuellement
|
||||
Passer par la fiche individuelle de l'étudiant: menu "*Etudiant / Changer la photo*" et télécharger un fichier image (jpeg, gif, png...).
|
||||
### Individuellement
|
||||
|
||||
ScoDoc réduit automatiquement la taille de la photo (actuellement pour obtenir une taille verticale de 90 pixels).
|
||||
Passer par la fiche individuelle de l'étudiant: menu "*Etudiant / Changer la
|
||||
photo*" et télécharger un fichier image (jpeg, gif, png...).
|
||||
|
||||
ScoDoc réduit automatiquement la taille de la photo (actuellement pour obtenir
|
||||
une taille verticale de 90 pixels).
|
||||
|
||||
#### Import de plusieurs photos
|
||||
Si vous n'avez pas la possibilité d'interfacer ScoDoc à un service fournissant les photos (via le service de la Scolarité de votre Université, par exemple), vous pouvez importer les photos via un fichier Zip et un fichier Excel permettant d'associer à chaque étudiant le bon fichier image.
|
||||
### Import de plusieurs photos
|
||||
|
||||
Si vous n'avez pas la possibilité d'interfacer ScoDoc à un service fournissant
|
||||
les photos (via le service de la Scolarité de votre Université, par exemple),
|
||||
vous pouvez importer les photos via un fichier Zip et un fichier Excel
|
||||
permettant d'associer à chaque étudiant le bon fichier image.
|
||||
|
||||
Le menu "Photo" de la page "Trombinoscope" offre pour cela une fonction "Charger des photos...": suivre les indications données sur la page.
|
||||
Le menu "Photo" de la page "Trombinoscope" offre pour cela une fonction "Charger
|
||||
des photos...": suivre les indications données sur la page.
|
||||
|
||||
### Afficher un trombinoscope
|
||||
|
||||
### Afficher un trombinoscope
|
||||
Suivre le lien "*Photos*" du groupe qui vous intéresse.
|
||||
Suivre le lien "*Photos*" du groupe qui vous intéresse.
|
||||
|
||||
Le menu en haut à droite de la page permet d'obtenir une version PDF du trombinoscope (pour impression ou distribution) et une archive zip avec tous les fichiers images.
|
||||
Le menu en haut à droite de la page permet d'obtenir une version PDF du
|
||||
trombinoscope (pour impression ou distribution) et une archive zip avec tous les
|
||||
fichiers images.
|
||||
|
||||
La fonction "*Copier les photos du portail*" permet de copier dans ScoDoc les photos externes publiées sur le portail.
|
||||
La fonction "*Copier les photos du portail*" permet de copier dans ScoDoc les
|
||||
photos externes publiées sur le portail.
|
||||
|
||||
### Photos externes
|
||||
|
||||
### Photos externes
|
||||
Lorsque ScoDoc ne possède pas de copie de la photo d'un étudiant et qu'il est configuré avec un portail, il place dans les pages un lien vers ```portal_url + '/getPhoto.php?nip=CODE_NIP```. Voir [InterrogationPortail](InterrogationPortail.md).
|
||||
|
||||
Lorsque ScoDoc ne possède pas de copie de la photo d'un étudiant et qu'il est
|
||||
configuré avec un portail, il peut places dans les pages un lien vers
|
||||
```portal_url + '/getPhoto.php?nip=CODE_NIP```. Voir
|
||||
[InterrogationPortail](InterrogationPortail.md).
|
||||
|
@ -1,4 +1,3 @@
|
||||
|
||||
# Guide ScoDoc pour le ou la responsable de formation
|
||||
|
||||
Cette partie s'adresse plutôt aux responsables de formation (cheffes ou chefs de
|
||||
@ -12,96 +11,7 @@ département IUT, responsable de filières, ...). Nous allons apprendre à:
|
||||
|
||||
## Définir un programme pédagogique
|
||||
|
||||
Le programme pédagogique d'une formation défini les unités d'enseignement; il
|
||||
est destiné à être utilisé par plusieurs sessions de formation (semestres). On
|
||||
doit apporter un soin particulier à la définition du programme, et éviter de le
|
||||
modifier une fois que des semestres sont créés (il est toutefois possible d'en
|
||||
créer de nouvelles *versions* pour permettre des modifications ultérieures sans
|
||||
affecter les semestres achevés: voir [VersionProgrammes](VersionProgrammes.md)).
|
||||
|
||||
On définira en général dans le programme l'ensemble des enseignements d'un
|
||||
diplôme (les 4 semestres d'un DUT par exemple). C'est dans une phase ultérieure
|
||||
que l'on mettra en place les différents semestres.
|
||||
|
||||
Les programmes pédagogiques ScoDoc sont structurés en Unités d'Enseignements
|
||||
(UE), Matières et Modules. Un module appartient forcément à une matière, qui
|
||||
appartient elle même à une UE. Les modules (déclinés en *ressources*, *SAÉs* en
|
||||
BUT) représentent les cours ("mathématique", "anglais", ...) et sont associés à
|
||||
un volume horaire (cours/TD/TP) et à un coefficient: chaque module produit une
|
||||
note moyenne (en général obtenue à travers plusieurs *évaluations* ou
|
||||
contrôles). La note moyenne d'une UE est obtenue en calculant une moyenne
|
||||
pondérée par les coefficients des notes moyennes de modules.
|
||||
|
||||
🚸 En BUT, c'est un peu différent, puisque les modules ont une note *pour chaque
|
||||
UE*: la moyenne d'un module n'est pas définie. Voir [BUT](BUT.md)
|
||||
|
||||
Les matières n'ont pas d'autre utilité que d'aider à structurer le programme.
|
||||
Par exemple, on pourrait définir dans un programme une matière "Sciences"
|
||||
réunissant les modules de "mathématiques" et de "physique". Les matières n'ont
|
||||
pas de coefficient. Si l'on ne souhaite pas utiliser de matière, il suffit d'en
|
||||
créer une pour chaque module avec le même nom, ou au contraire (plus simplement)
|
||||
de créer une matière par UE et d'y placer tous les modules.
|
||||
|
||||
Les UE jouent un rôle particulier dans l'évaluation. En effet, selon les règles
|
||||
du LMD, les UE sont *capitalisables* (voir
|
||||
[CapitalisationUE](CapitalisationUE.md)). De plus, l'obtention de droit des
|
||||
semestres d'un DUT est soumise à une moyenne supérieure à 8/20 dans chacune des
|
||||
UE.
|
||||
|
||||
Notons qu'une UE ne possède pas de coefficient. Le coefficient d'une UE n'est
|
||||
autre que la somme des coefficient des modules qui composent cette UE. Par
|
||||
conséquent, le coefficient d'UE est potentiellement variable d'un étudiant à
|
||||
l'autre, si les étudiants ne sont pas inscrits aux mêmes modules (options ou
|
||||
parcours).
|
||||
|
||||
Vous trouverez plus d'informations sur la définition des programmes sur la page
|
||||
[VersionProgrammes](VersionProgrammes.md).
|
||||
|
||||
## Versions des programmes de formation
|
||||
|
||||
Chaque semestre ("FormSemestre" dans le jargon ScoDoc) se réfère à un programme
|
||||
pédagogique, appelé sa *formation*. cette formation définit l'ensemble des UE et
|
||||
modules, leurs intitulés, et leurs coefficients et ECTS.
|
||||
|
||||
Les programmes sont le plus souvent adaptés localement, et peuvent varier d'une
|
||||
année sur l'autre. Lorsqu'une formation est modifié (par exemple, un changement
|
||||
de coefficient), ScoDoc doit recalculer l'ensemble des notes de tous les
|
||||
semestres utilisant cette formation. De même, si un intitulé change, il faut
|
||||
re-générer les bulletins et procès-verbaux. On conçoit donc que la modification
|
||||
d'une formation ne s'aborde pas à la légère. ScoDoc empêche d'ailleurs toute
|
||||
modification d'une formation (ou partie de, selon les cas) lorsqu'un semestre a
|
||||
été verrouillé (ce qui indique en général qu'il est achevé et que l'on souhaite
|
||||
conserver ses données et résultats inchangés pour utilisation future dans des
|
||||
jurys ou avis).
|
||||
|
||||
Si vous devez modifier une formation pour la nouvelle année scolaire, vous
|
||||
pouvez créer une nouvelle version d'une formation existante afin d'éviter
|
||||
d'avoir à saisir de nouveau l'ensemble des éléments. Il arrive même que, l'année
|
||||
scolaire déjà commencée, on se rende compte que l'on doit modifier la formation
|
||||
d'un semestre en cours (bien sûr, cela ne devrait pas arriver, les modalités
|
||||
d'évaluation étant souvent votées par des instances officielles avant le début
|
||||
de l'année, mais le monde n'est pas parfait et de petites corrections sont
|
||||
parfois nécessaires). Dans ce cas, ScoDoc vous permet d'associer un ou plusieurs
|
||||
semestres existants dans une formation à une nouvelle version de celle-ci, créée
|
||||
par copie.
|
||||
|
||||
![menu formsemestre](fig/menu-formsemestre-assoc.png)
|
||||
|
||||
La figure suivante montre la distinction entre formations et semestres, et les opérations possibles:
|
||||
|
||||
![menu formsemestre](fig/formations_versions_association.jpg)
|
||||
|
||||
![association nouvelle version](fig/sem-assoc-formation.png)
|
||||
|
||||
### Changement de la formation d'un semestre
|
||||
|
||||
Il peut arriver que l'on ai créé deux versions de formations, qui sont encore
|
||||
identique, et que l'on souhaite rattacher un formsemestre de l'une à l'autre.
|
||||
C'est possible, à condition que les deux formations soient vraiment identiques
|
||||
(mêmes UEs, titres, coefficients, etc). Le lien est accessible en bas de la page
|
||||
"Associer à une nouvelle version du programme" mentionnée ci-dessus.
|
||||
|
||||
![change formation](fig/sem-change-formation.png)
|
||||
Voir [Programmes pédagogiques et versions](Formations.md).
|
||||
|
||||
## Créer un semestre de formation
|
||||
|
||||
@ -124,6 +34,11 @@ le langage IUT).
|
||||
|
||||
* [Données sur scolarité antérieure et admission](DonneesAdmissions.md)
|
||||
|
||||
## Jurys
|
||||
|
||||
* [Saisie des décisions](SaisieDecisionsJury.md)
|
||||
* [Gestion des commissions et jurys, édition des PV](GestionJury.md)
|
||||
|
||||
## Suivi de la Scolarité
|
||||
|
||||
* [Récapitulatif des opérations en fin de semestre et début du suivant](TransitionSemestre.md)
|
||||
@ -140,8 +55,9 @@ fichiers sur la page
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Édition des programmes de formation](VersionProgrammes.md)
|
||||
- [Programmes de formation](Formations.md)
|
||||
- [Guide utilisateur](GuideUtilisateur.md)
|
||||
- [Modélisation BUT: exemple complet](BUTExempleInfo.md)
|
||||
- [Tutoriels vidéo](https://www.youtube.com/channel/UCb0JYCBRi0CsE4XFp4ByhXg)
|
||||
- [Gestion des UE Bonus](https://www.youtube.com/watch?v=SVbjuDpq-lI)
|
||||
- [Mise en place des parcours BUT](https://www.youtube.com/watch?v=OnuOXJo-3ro)
|
||||
|
@ -1,12 +1,12 @@
|
||||
# Guide pour les administrateurs système de ScoDoc
|
||||
|
||||
ScoDoc 9 est prévu pour fonctionner sur un serveur **Linux Debian 11 (Bullseye)**.
|
||||
L'installation sur tout autre système n'est **pas supportée**.
|
||||
ScoDoc 9 est prévu pour fonctionner sur un serveur **Linux Debian 12 (Bookworm)**.
|
||||
L'installation sur tout autre système n'est **pas supportée**.
|
||||
Utilisez un **serveur virtuel** ou un container Docker si vous n'avez pas de machine Debian dédiée.
|
||||
|
||||
## Installation
|
||||
|
||||
* Installation de ScoDoc: [GuideInstallDebian11](GuideInstallDebian11.md)
|
||||
* Installation de ScoDoc: [GuideInstallDebian12](GuideInstallDebian12.md)
|
||||
|
||||
* Migration d'un serveur ScoDoc 7 vers la nouvelle version Scodoc 9: [MigrationScoDoc7a9](MigrationScoDoc7a9.md)
|
||||
|
||||
@ -31,13 +31,12 @@ Utilisez un **serveur virtuel** ou un container Docker si vous n'avez pas de mac
|
||||
## Utilisation avancée
|
||||
|
||||
* [Interfaçage avec Apogée](ScoDocApogee.md)
|
||||
* [API](ScoDoc9API.md) : API JSON ou XML pour interfaçage avec d'autres applications
|
||||
* [ServicesXml](ServicesXml.md) : web services XML pour interfaçage avec d'autres applications (obsolète).
|
||||
* [API](ScoDoc9API.md) : API pour interfaçage avec d'autres applications
|
||||
* [InterrogationPortail](InterrogationPortail.md) : liaison avec portail
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
|
||||
- [Guide pour les développeurs](GuideDeveloppeurs.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
@ -1,8 +1,7 @@
|
||||
# Prise en main et paramétrage de ScoDoc 9
|
||||
|
||||
# Prise en main et paramétrage de ScoDoc 9
|
||||
|
||||
Ce document suppose que le logiciel a été installé suivant la procédure décrite dans
|
||||
[GuideInstallDebian11](GuideInstallDebian11.md).
|
||||
Ce document suppose que le logiciel a été installé suivant la procédure décrite dans
|
||||
[GuideInstallDebian12](GuideInstallDebian12.md).
|
||||
|
||||
## Administration en ligne de commande
|
||||
|
||||
@ -11,15 +10,15 @@ création d'utilisateurs "super admin", c'est à dire admin pour tous les
|
||||
départements. Le reste des paramétrages (création de comptes, de formations,
|
||||
import d'étudiants, etc) se fait à partir du logiciel (web).
|
||||
|
||||
L'administration se fait dans un terminal connecté au serveur (en général via
|
||||
L'administration se fait dans un terminal connecté au serveur (en général via
|
||||
ssh), en tant qu'utilisateur `scodoc` (*et non* `root`).
|
||||
|
||||
Se connecter et initialiser la session ainsi:
|
||||
|
||||
ssh votre.serveur # si nécessaire
|
||||
su scodoc # idem,
|
||||
su scodoc # idem,
|
||||
# ou tout autre moyen d'ouvrir un shell comme scodoc
|
||||
|
||||
|
||||
cd /opt/scodoc
|
||||
source venv/bin/activate
|
||||
|
||||
@ -31,7 +30,7 @@ toute l'application scodoc est initialisée à chaque fois.*
|
||||
|
||||
flask create-dept DEPT
|
||||
|
||||
où `DEPT` est l'acronyme du département, par exemple "RT". Ce département
|
||||
où `DEPT` est l'acronyme du département, par exemple "RT". Ce département
|
||||
apparait immédiatement sur la page d'accueil.
|
||||
|
||||
### Suppression d'un département
|
||||
@ -65,12 +64,12 @@ où `admin2` est ici le pseudo du nouvel admin.
|
||||
### Changement du mot de passe d'un utilisateur
|
||||
|
||||
Cette opération peut s'effectuer via la page de gestion web des
|
||||
utilisateurs, mais il est parfois commode de le faire depuis la
|
||||
utilisateurs, mais il est parfois commode de le faire depuis la
|
||||
console:
|
||||
|
||||
flask user-password LOGIN
|
||||
|
||||
où `LOGIN` est le pseudo de l'utilisateur. Le mot de passe est demandé
|
||||
où `LOGIN` est le pseudo de l'utilisateur. Le mot de passe est demandé
|
||||
sur la ligne de commande.
|
||||
|
||||
### Création d'un nouveau rôle
|
||||
@ -97,7 +96,7 @@ Ajoute ou retire une permission.
|
||||
|
||||
Exemples:
|
||||
|
||||
flask user-role dupont
|
||||
flask user-role dupont
|
||||
|
||||
affiche les rôles de l'utilisateur `dupont`.
|
||||
|
||||
@ -123,7 +122,7 @@ Ces commandes sont utilisées par le script de migration de ScoDoc 7 à ScoDoc 9
|
||||
|
||||
#### Comptes utilisateurs
|
||||
|
||||
Toujours migrer les comptes utilisateurs avant d'importer les
|
||||
Toujours migrer les comptes utilisateurs avant d'importer les
|
||||
départements.
|
||||
|
||||
flask import-scodoc7-users
|
||||
@ -140,38 +139,44 @@ Exemple:
|
||||
|
||||
### Liste des commandes Flask/ScoDoc
|
||||
|
||||
Dans l'encart ci-dessous, `app` désigne `flask`, comme dans les exemple donnés plus haut.
|
||||
Dans l'encart ci-dessous, `app` désigne `flask`, comme dans les exemples donnés plus haut.
|
||||
|
||||
```
|
||||
Usage: app [OPTIONS] COMMAND [ARGS]...
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Commands:
|
||||
anonymize-db Anonymise la base de nom indiqué (et non...
|
||||
clear-cache Clear ScoDoc cache This cache (currently...
|
||||
create-dept Create new departement
|
||||
create-role Create a new role
|
||||
delete-dept Delete existing departement
|
||||
delete-role Delete a role
|
||||
dumphelp
|
||||
list-roles List roles
|
||||
downgrade-assiduites-module Supprime les assiduites et/ou les...
|
||||
dumphelp Génère la page d'aide complète pour la doc.
|
||||
edit-role Add [-a] and/or remove [-r] a permission...
|
||||
entreprises-reset-db Remet a zéro les tables du module...
|
||||
gen-api-map Génère la carte des routes de l'API.
|
||||
generate-ens-calendars Génère les calendrier enseignants à...
|
||||
import-scodoc7-dept Import département ScoDoc 7: dept:...
|
||||
import-scodoc7-users Import users defined in ScoDoc7...
|
||||
init-test-database Initialise les objets en base pour les...
|
||||
list-depts If dept exists, print it, else nothing.
|
||||
list-roles List all defined roles
|
||||
localize-logo Make local to a dept a global logo (both...
|
||||
migrate-abs-to-assiduites Permet de migrer les absences vers le...
|
||||
migrate-scodoc7-dept-archives Post-migration: renomme les archives en...
|
||||
migrate-scodoc7-dept-logos Post-migration: renomme les logos en...
|
||||
photos-import-files
|
||||
profile Start the application under the profiler...
|
||||
photos-import-files Import des photos d'étudiants à partir...
|
||||
profile Start the application under the code...
|
||||
sco-db-init Initialize the database.
|
||||
scodoc-database print the database connexion string
|
||||
user-change-login Change user's login (user_name)
|
||||
user-create Create a new user
|
||||
user-db-clear Erase all users and roles from the...
|
||||
user-delete Try to delete this user.
|
||||
user-password Set (or change) user’s password
|
||||
user-role Display roles, or add or remove a role to the given user...
|
||||
user-password Set (or change) user's password
|
||||
user-role Add or remove a role to the given user...
|
||||
|
||||
|
||||
Usage: app sco-db-init [OPTIONS]
|
||||
|
||||
@ -180,12 +185,21 @@ Usage: app sco-db-init [OPTIONS]
|
||||
|
||||
Options:
|
||||
--erase / --no-erase
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app anonymize-db [OPTIONS] DATABASE
|
||||
|
||||
Anonymise la base de nom indiqué (et non pas la base courante!)
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app user-db-clear [OPTIONS]
|
||||
|
||||
Erase all users and roles from the database !
|
||||
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app user-create [OPTIONS] USERNAME ROLE DEPT
|
||||
|
||||
@ -194,23 +208,36 @@ Usage: app user-create [OPTIONS] USERNAME ROLE DEPT
|
||||
Options:
|
||||
-n, --nom TEXT
|
||||
-p, --prenom TEXT
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app user-delete [OPTIONS] USERNAME
|
||||
|
||||
Try to delete this user. Fails if it’s associated to some scodoc objects.
|
||||
Try to delete this user. Fails if it's associated to some scodoc objects.
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app user-password [OPTIONS] USERNAME
|
||||
|
||||
Set (or change) user’s password
|
||||
Set (or change) user's password
|
||||
|
||||
Options:
|
||||
--password TEXT
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app create-role [OPTIONS] ROLENAME [PERMISSIONS]...
|
||||
|
||||
Create a new role
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app list-roles [OPTIONS]
|
||||
|
||||
List all defined roles
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app edit-role [OPTIONS] ROLENAME
|
||||
|
||||
@ -218,11 +245,12 @@ Usage: app edit-role [OPTIONS] ROLENAME
|
||||
permissions are not associated to users but to roles. Each user has a set of
|
||||
roles in each departement.
|
||||
|
||||
Example: `flask edit-role -a ScoEditApo Ens`
|
||||
Example: `flask edit-role -a EditApogee Ens`
|
||||
|
||||
Options:
|
||||
-a, --add TEXT
|
||||
-r, --remove TEXT
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app delete-role [OPTIONS] ROLENAME
|
||||
|
||||
@ -241,25 +269,36 @@ Options:
|
||||
-r, --remove TEXT
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app user-change-login [OPTIONS] USER_NAME NEW_USER_NAME
|
||||
|
||||
Change user's login (user_name)
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app delete-dept [OPTIONS] DEPT
|
||||
|
||||
Delete existing departement
|
||||
|
||||
Options:
|
||||
--yes
|
||||
--help Show this message and exit.
|
||||
-y, --yes
|
||||
-f, --force ignore non-existing departement
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app create-dept [OPTIONS] DEPT
|
||||
|
||||
Create new departement
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app list-depts [OPTIONS] [DEPTS]...
|
||||
|
||||
If dept exists, print it, else nothing. Called without arguments, list all
|
||||
depts along with their ids.
|
||||
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app scodoc-database [OPTIONS]
|
||||
|
||||
@ -268,7 +307,7 @@ Usage: app scodoc-database [OPTIONS]
|
||||
Options:
|
||||
-n, --name show database name instead of connexion string (required for
|
||||
dropdb/createdb commands)
|
||||
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app import-scodoc7-users [OPTIONS]
|
||||
|
||||
@ -277,30 +316,44 @@ Usage: app import-scodoc7-users [OPTIONS]
|
||||
script is typically run as unix user "scodoc". The original SCOUSERS
|
||||
database is left unmodified.
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app import-scodoc7-dept [OPTIONS] DEPT DEPT_DB_NAME
|
||||
|
||||
Import département ScoDoc 7: dept: InfoComm, dept_db_name: SCOINFOCOMM
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app migrate-scodoc7-dept-archives [OPTIONS] [DEPT]
|
||||
|
||||
Post-migration: renomme les archives en fonction des id de ScoDoc 9
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app migrate-scodoc7-dept-logos [OPTIONS] [DEPT]
|
||||
|
||||
Post-migration: renomme les logos en fonction des id / dept de ScoDoc 9
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app localize-logo [OPTIONS] LOGO DEPT
|
||||
|
||||
Make local to a dept a global logo (both logo and dept names are mandatory)
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app photos-import-files [OPTIONS] FORMSEMESTRE_ID XLSFILE ZIPFILE
|
||||
|
||||
Import des photos d’étudiants à partir d’une liste excel et d’un zip avec les images.
|
||||
Import des photos d'étudiants à partir d'une liste excel et d'un zip avec
|
||||
les images.
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app clear-cache [OPTIONS]
|
||||
|
||||
@ -310,10 +363,29 @@ Usage: app clear-cache [OPTIONS]
|
||||
|
||||
Options:
|
||||
--sanitize / --no-sanitize
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app init-test-database [OPTIONS]
|
||||
|
||||
Initialise les objets en base pour les tests API (à appliquer sur
|
||||
SCODOC_TEST ou SCODOC_DEV)
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app entreprises-reset-db [OPTIONS]
|
||||
|
||||
Remet a zéro les tables du module relations entreprises
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app dumphelp [OPTIONS]
|
||||
|
||||
Génère la page d’aide complète pour la doc.
|
||||
Génère la page d'aide complète pour la doc.
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app profile [OPTIONS]
|
||||
|
||||
@ -325,6 +397,45 @@ Options:
|
||||
--length INTEGER Number of functions to include in the profiler report.
|
||||
--profile-dir TEXT Directory where profiler data files are saved.
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app migrate-abs-to-assiduites [OPTIONS]
|
||||
|
||||
Permet de migrer les absences vers le nouveau module d'assiduités
|
||||
|
||||
Options:
|
||||
-d, --dept TEXT Restreint la migration au dept sélectionné (ACRONYME)
|
||||
-m, --morning TEXT Spécifie l'heure de début des cours format `hh:mm`
|
||||
-n, --noon TEXT Spécifie l'heure de fin du matin format `hh:mm`
|
||||
-a, --afternoon TEXT Spécifie l'heure de début de l'après-midi format
|
||||
`hh:mm` valeur identique à --noon si non spécifié
|
||||
-e, --evening TEXT Spécifie l'heure de fin des cours format `hh:mm`
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app downgrade-assiduites-module [OPTIONS]
|
||||
|
||||
Supprime les assiduites et/ou les justificatifs de tous les départements ou
|
||||
du département sélectionné
|
||||
|
||||
Options:
|
||||
-d, --dept TEXT Restreint la suppression au dept sélectionné (ACRONYME)
|
||||
-a, --assiduites Supprime les assiduités de scodoc
|
||||
-j, --justificatifs Supprime les justificatifs de scodoc
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app generate-ens-calendars [OPTIONS]
|
||||
|
||||
Génère les calendrier enseignants à partir des ics semestres
|
||||
|
||||
Options:
|
||||
--help Show this message and exit.
|
||||
|
||||
Usage: app gen-api-map [OPTIONS]
|
||||
|
||||
Génère la carte des routes de l'API.
|
||||
|
||||
Options:
|
||||
-e, --endpoint TEXT Endpoint à partir duquel générer la carte des routes
|
||||
--help Show this message and exit.
|
||||
```
|
||||
|
||||
(*la liste ci-dessus est générée à l'aide de la commande* `flask dumphelp`).
|
||||
@ -354,7 +465,7 @@ département, qui à son tour peut déléguer des droits.
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Guide installation](GuideInstallDebian11.md)
|
||||
- [Guide installation](GuideInstallDebian12.md)
|
||||
- [Gestion des utilisateurs](AdminUsers.md)
|
||||
- [Rôles et permissions](ConfigPermissionsDept.md)
|
||||
- [Configuration des envois d'emails](ConfigEmail.md)
|
||||
|
@ -2,16 +2,25 @@
|
||||
|
||||
Informations pour les développeurs souhaitant étendre ou modifier ScoDoc.
|
||||
|
||||
Pour le développement de logiciels externes, [utiliser l'API](ScoDoc9API.md).
|
||||
|
||||
Accès à la [plate-forme Gitea](https://git.scodoc.org).
|
||||
|
||||
## Informations générales
|
||||
|
||||
* Voir [contacts](Contact.md). Il y a aussi un serveur Discord ouvert sur
|
||||
invitation aux développeur actifs. Contacter Emmanuel Viennet.
|
||||
* [Générer de nouveaux formats de bulletins PDF](ApiGenerationBulletinsPdf.md)
|
||||
* [Créer de nouveaux types de "parcours"](ApiCreationParcours.md)
|
||||
* [API](ScoDoc9API.md) : API JSON ou XML pour interfaçage avec d'autres applications
|
||||
* Notes diverses
|
||||
* [Discussions pour la future gestion des absences](IdeesGestionAbsences.md)
|
||||
* [Anciennes discussions sur la gestion des plannings](IdeesGestionPlannings.md)
|
||||
Les échanges se font sur Discord, voir [contacts](Contact.md). Il y a un serveur
|
||||
Discord ouvert sur invitation aux développeur actifs. Contacter Emmanuel Viennet
|
||||
(`@emm`).
|
||||
|
||||
- [Développement ScoDoc: Introduction](DevInternals.md)
|
||||
- [Utilisation de git](DevGit.md)
|
||||
- [Définition des cursus](DevCursus.md)
|
||||
- [Générer de nouveaux formats de bulletins PDF](ApiGenerationBulletinsPdf.md)
|
||||
- [Gestion des jurys BUT](DevJuryBUT.md)
|
||||
- [API](ScoDoc9API.md) : API pour interfaçage avec d'autres applications
|
||||
- Notes diverses (caduques, pour mémoire)
|
||||
- [Très anciennes discussions pour la future gestion des absences](IdeesGestionAbsences.md)
|
||||
- [Anciennes discussions sur la gestion des plannings](IdeesGestionPlannings.md)
|
||||
|
||||
## Développer sur ScoDoc
|
||||
|
||||
@ -23,7 +32,7 @@ Quelques conseils, indications et mémos pour les développeurs sur ScoDoc versi
|
||||
|
||||
### Style et formatage du code
|
||||
|
||||
L'ancienneté de la base de code a rendu le style un peu incohérent, mais cela
|
||||
L'ancienneté de la base de code a rendu le style un peu incohérent, mais cela
|
||||
s'est nettement amélioré avec ScoDoc 9 (respect PEP 8).
|
||||
|
||||
Le code DOIT être formaté avec [`black`](https://black.readthedocs.io/) avant
|
||||
@ -60,348 +69,7 @@ Exemple:
|
||||
|
||||
### Git
|
||||
|
||||
Le dépôt est <https://scodoc.org/git/viennet/ScoDoc>
|
||||
|
||||
La branche `master` est celle de ScoDoc 9, d'où sont issues les paquets
|
||||
distribués (*releases*). Les développements ont lieu sur d'autres branches
|
||||
(`api`, `dev92`, `entreprises`, ...) avant d'être intégrés après tests.
|
||||
La branche `Scodoc7` était l'ancienne (jusqu'à septembre 2021) version de ScoDoc.
|
||||
|
||||
Ci-dessous quelques pense-bête qui peuvent servir.
|
||||
|
||||
#### Hot fixes (internes)
|
||||
|
||||
Pour les développeurs internes (écriture sur le dépôt master), un exemple
|
||||
basique illustrant le cycle de développement:
|
||||
|
||||
```bash
|
||||
# Créer une branche
|
||||
# si besoin (travail en cours), utiliser git stash avant
|
||||
git checkout master
|
||||
git branch hotfix
|
||||
git checkout hotfix
|
||||
... dev, test ...
|
||||
git add ...
|
||||
git commit -m "fixed ..."
|
||||
git checkout master
|
||||
git merge hotfix
|
||||
git branch -d hotfix
|
||||
# publication
|
||||
|
||||
# éventuellement: git stash pop
|
||||
```
|
||||
|
||||
Dans la plupart des cas, on travaillera sur son propre dépôt (clone du dépt
|
||||
origine), et on proposera une *pull request* (PR, *demande d'ajout* en français).
|
||||
|
||||
#### Mettre à jour votre branche
|
||||
|
||||
Quand vous travaillez dans votre branche `ma_branche`, pour lui appliquer les
|
||||
mises à jour de `master` (remote), faire:
|
||||
|
||||
```bash
|
||||
git pull origin master
|
||||
```
|
||||
|
||||
#### Commandes utiles, en vrac
|
||||
|
||||
* `git log -L:fonction_python:fichier.py`
|
||||
* Commits locaux: `git log @{u}..`
|
||||
|
||||
#### Refactoring
|
||||
|
||||
Lint tous les fichiers modifiés:
|
||||
|
||||
```bash
|
||||
git status | grep modified | grep .py | awk '{print $2}' | xargs pylint -E
|
||||
```
|
||||
|
||||
Affiche les variables non définies dans un fichier:
|
||||
|
||||
```bash
|
||||
pylint --disable=all -e E sco_parcours_dut.py | grep undefined-variable | awk '{print $4;}' | sort | uniq | tr -d \'
|
||||
```
|
||||
|
||||
Prépare un sed pour renommer les variables non définies:
|
||||
|
||||
```bash
|
||||
for f in *.py
|
||||
do
|
||||
pylint --disable=all -e E "$f" | grep undefined-variable | awk '{print "sed -i .bak s/"$4"/scu."$4"/ '$f'";}' | sort | uniq | tr -d \'
|
||||
done
|
||||
```
|
||||
|
||||
Restore les modes au besoin (SAMBA les changent parfois):
|
||||
|
||||
```bash
|
||||
git diff -p -R --no-color | grep -E "^(diff|(old|new) mode)" --color=never | git apply
|
||||
```
|
||||
|
||||
Note pour travailler sur VirtualBox:
|
||||
|
||||
```text
|
||||
addgroup scodoc vboxsf
|
||||
```
|
||||
|
||||
### Préparation d'une PR (Pull Request)
|
||||
|
||||
#### Principes généraux
|
||||
|
||||
Les remarques de cette section visent à obtenir une relecture facile de votre
|
||||
demande d'ajout (*pull request*, dite "PR"):
|
||||
|
||||
* Éviter les modifications de forme qui ne changent pas le sens du code. L'utilisation de
|
||||
[`black`](https://black.readthedocs.io/) est obligatoire : elle permet de normaliser la présentation
|
||||
du code. cela évite de générer des différences ne représentant que des
|
||||
changements de mise en forme (indentation, passages à la ligne). Cela évite
|
||||
aussi au développeur d'avoir à y réfléchir, autant de temps gagné !
|
||||
|
||||
* Avoir un nombre d'étapes de validation faible (idéalement un seul commit pour
|
||||
les PR courantes - peu volumineuses).
|
||||
|
||||
* La PR doit toujours être énoncée par rapport au dernier commit de la branche
|
||||
que vous visez (en général `master` du dépôt original).
|
||||
|
||||
#### Manipulations
|
||||
|
||||
Les manipulations sont décrites selon quatre phases du développement : l'installation,
|
||||
la mise en place, le suivi et la livraison.
|
||||
|
||||
##### L'installation
|
||||
|
||||
Il est pratique d'avoir en ligne les deux dépôts git distants que vous pouvez
|
||||
utiliser : votre dépôt personnel (`https://scodoc.org/git/<user>/<dépôt>.git`) et
|
||||
le dépôt officiel (`https://scodoc.org/git/ScoDoc/ScoDoc.git`).
|
||||
|
||||
pour ajouter une référence (et lui donner un nom) vers un dépôt distant, entrez
|
||||
la commande:
|
||||
|
||||
```bash
|
||||
git remote add nom_remote https://scodoc.org/git/ScoDoc/<dépôt>.git
|
||||
```
|
||||
|
||||
Par la suite vous aurez donc une référence vers votre dépôt personnel (`perso`)
|
||||
et une référence vers le dépôt officiel (`officiel`). Si vous avez initialement
|
||||
cloné l'un des deux dépôts, la référence vers le dépôt d'origine existe et a pour nom
|
||||
`origin`.
|
||||
|
||||
La commande vous exposant tous les dépôts connus est :
|
||||
|
||||
```bash
|
||||
git remote -v
|
||||
```
|
||||
|
||||
#### Mise en place
|
||||
|
||||
L'objectif de ce paragraphe est de créer une branche locale basée sur le master
|
||||
du dépôt officiel et bien sur de lui donner un nom.
|
||||
|
||||
pour cela (**attention cela va écraser les éventuels fichiers modifiés**. Si vous souhaitez conserver les
|
||||
modifications en cours, encadrez les lignes suivantes par `git stash` (avant) et `git stash apply` (après) :
|
||||
|
||||
```bash
|
||||
git reset --hard officiel/master
|
||||
git checkout -b ma_modif
|
||||
```
|
||||
|
||||
À partir de là, vous pouvez modifier, tester, développer et commit votre travail.
|
||||
|
||||
#### Suivi
|
||||
|
||||
Si votre développement prend plusieurs jours, il est probable que la branche
|
||||
principale évolue pendant ce temps.
|
||||
|
||||
Pour garder la cohérence, il est nécessaire de réintégrer en local les
|
||||
modifications de la branche principale. Ceci peut se faire de deux façons.
|
||||
|
||||
* Une fusion (`merge`) applique toutes les modifications en un seul commit).
|
||||
C'est la méthode couramment utilisée.
|
||||
|
||||
* Un `rebase` rejoue tous les commits de la nouvelle branche par dessus l'état
|
||||
le plus à jour de la branche principale (il en résulte un historique plus
|
||||
linéaire).
|
||||
|
||||
Les commandes git correspondantes :
|
||||
|
||||
```bash
|
||||
git fetch officiel
|
||||
git merge officiel/master
|
||||
```
|
||||
|
||||
ou
|
||||
|
||||
```bash
|
||||
git fetch officiel
|
||||
git rebase officiel/merge
|
||||
```
|
||||
|
||||
#### La livraison
|
||||
|
||||
Ça y est. Vous avez terminé le développement. IL n'y a plus qu'à demander
|
||||
l'intégration. Ceci se fait en plusieurs étapes (vous êtes bien sûr toujours sur
|
||||
la branche locale `ma_modif` et toutes vos modifications ont été commitées).
|
||||
|
||||
##### Étape 1 : faire l'inventaire des fichiers impliqués
|
||||
|
||||
```bash
|
||||
git fetch officiel/master
|
||||
git diff --name-only officiel/master
|
||||
```
|
||||
|
||||
##### Étape 2 : passer black sur les fichiers modifiés
|
||||
|
||||
Cette étape est automatique avec les bons réglages sous VSCode (pas trouvé
|
||||
l'équivalent sous *pyCharm*).
|
||||
|
||||
À défaut les lignes suivantes réalisent le même travail :
|
||||
|
||||
```bash
|
||||
for fn in $(git diff --name-only officiel/master)
|
||||
do
|
||||
python3 -m black $fn
|
||||
done
|
||||
```
|
||||
|
||||
Faire une première lecture rapide pour vérifier qu'il ne reste pas de fichiers
|
||||
modifiés accidentellement.
|
||||
|
||||
Pour obtenir la modification sur un fichier spécifique (`app/fichier.py` par
|
||||
exemple):
|
||||
|
||||
```bash
|
||||
git diff officiel/master app/fichier.py
|
||||
```
|
||||
|
||||
Utilisateurs Windows : Vérifiez bien que les réglages de fin de ligne suivent
|
||||
bien les règles Linux: pas de retour chariot (noté CR ou `\r`) en fin de ligne
|
||||
mais un seul caractère line feed (noté LF ou `\n`). Le cas échéant, réglez
|
||||
votre IDE pour cela.
|
||||
|
||||
À ce niveau là de la procédure, vous n'avez plus dans votre branche locale que
|
||||
les différences strictement nécessaires à votre correctif.
|
||||
|
||||
##### Étape 3 : résumez tous les commits depuis le point de divergence en un seul commit
|
||||
|
||||
Repérez le point de divergence de votre branche locale avec officiel/master
|
||||
(normalement `git merge-base HEAD officiel/master`)
|
||||
|
||||
Demander un `rebase` interactif depuis ce point :
|
||||
|
||||
```bash
|
||||
git rebase -i $(git merge-base HEAD officiel/master)
|
||||
```
|
||||
|
||||
*Explications*: Le rebase interactif permet d'enregistrer un suite de
|
||||
manipulation de commit dans un seul fichier texte. Le fichier texte qui reprend
|
||||
tels quels tous les commits concernés (et donc qui ne fait rien) est préparé par
|
||||
la commande `-i` de la commande_ `git rebase`.
|
||||
|
||||
Vous pouvez ensuite modifier ce fichier dans votre éditeur favori (ou pas) (à
|
||||
régler par `git config`) pour décrire_ _votre intention (réordonner, changer le
|
||||
message, fusionner, ...) sur l'ensemble des commits.
|
||||
|
||||
Quand votre édition est terminée, git reprend la main est exécute chacune de vos
|
||||
opérations. Il est possible (bien que très rare) que des conflits apparaissent
|
||||
à ce moment-là. Les commandes habituelles de correction accompagnées des
|
||||
commandes :
|
||||
|
||||
```bash
|
||||
git rebase --continue # pour poursuivre le processus
|
||||
git rebase --abort # pour tout abandonner
|
||||
```
|
||||
|
||||
*vous permettront de résoudre ces problèmes exceptionnels*.
|
||||
|
||||
Application:
|
||||
|
||||
```bash
|
||||
git rebase -i $(git merge-base HEAD officiel/master)
|
||||
```
|
||||
|
||||
Vous devez obtenir dans un éditeur de texte la liste des commits opéré depuis le
|
||||
début du développement sous cette forme (c'est un exemple : le nombre de lignes
|
||||
peut varier) :
|
||||
|
||||
```bash
|
||||
pick eb8cbec modif 1
|
||||
pick 83eb79e modif 2
|
||||
|
||||
# Rebase 5ffd074..83eb79e onto 5ffd074 (2 commands)
|
||||
#
|
||||
# Commands:
|
||||
# p, pick <commit> = use commit
|
||||
# r, reword <commit> = use commit, but edit the commit message
|
||||
# e, edit <commit> = use commit, but stop for amending
|
||||
# s, squash <commit> = use commit, but meld into previous commit
|
||||
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
|
||||
# commit's log message, unless -C is used, in which case
|
||||
# keep only this commit's message; -c is same as -C but
|
||||
# opens the editor
|
||||
# x, exec <command> = run command (the rest of the line) using shell
|
||||
# b, break = stop here (continue rebase later with 'git rebase --continue')
|
||||
# d, drop <commit> = remove commit
|
||||
# l, label <label> = label current HEAD with a name
|
||||
# t, reset <label> = reset HEAD to a label
|
||||
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
|
||||
# . create a merge commit using the original merge commit's
|
||||
# . message (or the oneline, if no original merge commit was
|
||||
# . specified); use -c <commit> to reword the commit message
|
||||
#
|
||||
# These lines can be re-ordered; they are executed from top to bottom.
|
||||
#
|
||||
# If you remove a line here THAT COMMIT WILL BE LOST.
|
||||
#
|
||||
# However, if you remove everything, the rebase will be aborted.
|
||||
#
|
||||
```
|
||||
|
||||
Vous pouvez réorganiser tous les commits (changer l'ordre, fusionner) en
|
||||
changeant la commande pick au début de chaque ligne. L'idée ici est de fusionner
|
||||
toutes les lignes avec la première en remplaçant le 'pick' à partir de la ligne
|
||||
2 par `fixup`. Optionnellement, vous pouvez reformuler le message de commit
|
||||
(commande `reword` sur la première ligne).
|
||||
|
||||
Vous construirez par exemple :
|
||||
|
||||
```bash
|
||||
reword eb8cbec Correctif: Api - gestion des formation
|
||||
fixup 83eb79e modif 2
|
||||
...
|
||||
```
|
||||
|
||||
Quand vous sortez de l'éditeur, git effectue toutes les opérations demandées.
|
||||
|
||||
À ce niveau-là de la procédure :
|
||||
|
||||
* vous avez un seul commit pour l'ensemble du correctif proposé ;
|
||||
|
||||
* toutes les différences entre officiel/master et votre branche locale sont
|
||||
signifiantes.
|
||||
|
||||
##### Étape 4
|
||||
|
||||
Vous pouvez maintenant pousser votre branche locale sur votre dépôt personnel
|
||||
(vers une branche de même nom):
|
||||
|
||||
```bash
|
||||
git push --set-upstream perso ma_branche
|
||||
```
|
||||
|
||||
Si vous avez déjà fait cette opération auparavant il est possible que le push
|
||||
soit refusé (car le rebase a modifié des commits qui avaient déjà été poussés).
|
||||
Dans ce cas l'option `--force` du push vous permette de passer outre, mais
|
||||
assurez-vous avant d'être le seul à travailler sur cette branche.
|
||||
|
||||
##### Etape 5 : La dernière étape se passe sur le site [scodoc.org/git](https://scodoc.org/git/)
|
||||
|
||||
* Identifiez-vous
|
||||
|
||||
* Placez-vous sur la branche nouvellement créée
|
||||
|
||||
* À l'aide de l'interface du serveur, vous pouvez comparer l'état de votre
|
||||
branche par rapport au master officiel, et si cela vous convient, il vous
|
||||
reste à formuler une demande d'intégration (*pull request*). En remplissant
|
||||
les informations demandées.
|
||||
Voir [la page sur git et ScoDoc](DevGit.md)
|
||||
|
||||
## Tests et tests unitaires
|
||||
|
||||
@ -418,7 +86,7 @@ Au besoin, mémo:
|
||||
|
||||
- afficher les clés: `redis-cli KEYS '*'`
|
||||
|
||||
- `redis-cli TTL key` affiche le TTL d'un clé, -1 si infini.
|
||||
- `redis-cli TTL key` affiche le TTL d'une clé, -1 si infini.
|
||||
|
||||
- `redis-cli -r -1 -i 3 KEYS '*_NT_*'` surveille certaines clés (ici _NT_),
|
||||
affiche toutes les 3 secondes.
|
||||
@ -444,14 +112,14 @@ bibliothèques, ou autres expériences de ce genre, vous pouvez le récréer ain
|
||||
Puis soit vous installez les versions "officielles" (testées)
|
||||
|
||||
```bash
|
||||
pip install -r requirements-3.9.txt
|
||||
pip install -r requirements-3.11.txt
|
||||
```
|
||||
|
||||
Soit vous prenez les versions les plus à jour disponibles. Une façon rapide de
|
||||
faire ceci est:
|
||||
|
||||
```bash
|
||||
cut -d= -f 1 requirements-3.9.txt | xargs pip install
|
||||
cut -d= -f 1 requirements-3.11.txt | xargs pip install
|
||||
```
|
||||
|
||||
à adapter selon vos objectifs.
|
||||
@ -459,17 +127,34 @@ faire ceci est:
|
||||
Pour régénérer le fichier indiquant la liste des paquets:
|
||||
|
||||
```bash
|
||||
pip freeze > requirements-3.9.txt
|
||||
pip freeze > requirements-3.11.txt
|
||||
```
|
||||
|
||||
Enfin, pour mettre à jour les paquets pip, il faut dégeler les versions (unpin)
|
||||
puis upgrader et re-générer le fichier, comme suit:
|
||||
|
||||
```bash
|
||||
cp requirements-3.11.txt requirements.txt
|
||||
sed -i 's/[~=]=/>=/' requirements.txt
|
||||
pip install -U -r requirements.txt
|
||||
pip freeze > requirements-new.txt
|
||||
# et si tout va bien
|
||||
mv requirements-new.txt requirements-3.11.txt
|
||||
```
|
||||
|
||||
Note: la mise à jour par `apt` recrée le virtualenv à chaque fois.
|
||||
|
||||
## Roadmap
|
||||
|
||||
* [voir les tickets](https://scodoc.org/git/viennet/ScoDoc/issues)
|
||||
* [voir les tickets](https://git.scodoc.org/viennet/ScoDoc/issues)
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
|
||||
- [Conventions de codage](DevConventions.md)
|
||||
- [API ScoDoc 9](ScoDoc9API.md)
|
||||
- [Guide installation](GuideInstallDebian12.md)
|
||||
- [Gestion des utilisateurs](AdminUsers.md)
|
||||
- [Guide administrateur ScoDoc](GuideAdminSys.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
@ -1,6 +1,11 @@
|
||||
|
||||
# Installation de ScoDoc 9 sur Debian 11 (Bullseye)
|
||||
|
||||
|
||||
!!! warning "Nouvelle version"
|
||||
La version actuelle de Linux est Debian 12:
|
||||
[voir le guide d'installation à jour](GuideInstallDebian12.md)
|
||||
|
||||
Ce document décrit la procédure d'installation et de configuration de ScoDoc 9.
|
||||
Cette procédure doit être effectué sur la machine serveur avec un accès
|
||||
administrateur (root).
|
||||
@ -11,7 +16,7 @@ donc installer et configurer ScoDoc avec des connaissances réduites sur le
|
||||
système Linux.
|
||||
|
||||
Cette documentation est prévue pour installer ScoDoc version 9 sur un système
|
||||
[Debian](http://www.debian.org) 11 (Bullseye, stable) s'exécutant sur une
|
||||
[Debian](http://www.debian.org) 11 (Bullseye, oldstable) s'exécutant sur une
|
||||
machine intel-like **64bits** (architecture **AMD64** sur Intel/AMD, ou
|
||||
**aarch64** sur Apple ARM). Debian s'installe facilement en cinq minutes, sur
|
||||
une machine normale ou un serveur virtualisé. Il est **vivement déconseillé** de
|
||||
@ -102,14 +107,14 @@ Checklist minimale de votre système Linux Debian:
|
||||
changer leurs mots de passe (bien d'autres fonctions dépendent des mails).
|
||||
Au besoin, revoir la configuration avec `dpkg-reconfigure postfix` (voir
|
||||
aussi [envoi des courriers électroniques](ProblemesMail.md)).
|
||||
|
||||
|
||||
1. Vérifiez que votre serveur est accessible depuis une autre machine de votre
|
||||
réseau (voire d'Internet): par exemple `ping serveur.exemple.fr`.
|
||||
1. Date et heure: vérifier que les dates et heure sont correctes, même après
|
||||
reboot. L'utilisation d'un serveur de temps (ntp) est recommandée (
|
||||
`apt-get install ntp`), et éventuellement `dpkg-reconfigure tzdata`).
|
||||
1. Si vous avez installé à partir d'un support (DVD, clé USB...), pensez à le
|
||||
retirer des sources Debian afin de ne pas bloquer les mise à jour (commenter
|
||||
retirer des sources Debian afin de ne pas bloquer les mises à jour (commenter
|
||||
la ligne `deb cdrom:` dans le fichier `/etc/apt/sources.list`)
|
||||
1. Cette liste est incomplète... et n'oubliez pas: avant de passer en
|
||||
production, mettez en place des sauvegardes sérieuses !
|
||||
@ -117,8 +122,8 @@ Checklist minimale de votre système Linux Debian:
|
||||
#### Configuration si utilisation d'un proxy
|
||||
|
||||
Si votre accès à Internet passe par un proxy, l'indiquer au moment de
|
||||
l'installation Debian.
|
||||
|
||||
l'installation Debian.
|
||||
|
||||
Ensuite, dans ScoDoc, indiquer votre proxy: pour cela, éditer le fichier
|
||||
```/opt/scodoc/.env```
|
||||
et ajouter les variables d'environnement nécessaires. Typiquement, il s'agit de :
|
||||
@ -130,20 +135,29 @@ et ajouter les variables d'environnement nécessaires. Typiquement, il s'agit de
|
||||
|
||||
Vérifiez aussi que ces variables sont bien définies dans `/etc/environment` (si
|
||||
l'installeur Linux Debian ne les a pas déjà indiquées là, les ajouter ou créer
|
||||
ce fichier).
|
||||
ce fichier):
|
||||
|
||||
```bash
|
||||
# /etc/environment
|
||||
export HTTP_PROXY=http://proxy.univ-xxx.fr:1234
|
||||
export HTTPS_PROXY=http://proxy.univ-xxx.fr:1234
|
||||
# Versions en minuscules utilisées par wget
|
||||
export http_proxy="${HTTP_PROXY}"
|
||||
export https_proxy="${HTTPS_PROXY}"
|
||||
```
|
||||
|
||||
Après modification de ce fichier (qui *doit* être lisible par l'utilisateur `scodoc`),
|
||||
redémarrer le service:
|
||||
|
||||
```bash
|
||||
sudo systemctl restart scodoc
|
||||
sudo systemctl restart scodoc9
|
||||
```
|
||||
|
||||
Dans les cas compliqués, il est possible qu'il vous faille configurer d'autres
|
||||
éléments, voir par exemple
|
||||
[ce post sur Stack Overflow](
|
||||
https://stackoverflow.com/questions/9445489/performing-http-requests-with-curl-using-proxy).
|
||||
|
||||
|
||||
#### Note sur l'install dans un container LXC
|
||||
|
||||
Il y a deux possibilités :
|
||||
@ -219,8 +233,8 @@ Remarque: *Si ce n'est pas déjà le cas, vous avez intérêt à ouvrir une sess
|
||||
`ssh` (ou `putty`) depuis une machine normale, afin de pouvoir copier/coller
|
||||
facilement les commandes et éditer les fichiers de configuration.*
|
||||
|
||||
- Ajouter le dépot scodoc: copier ce fichier <a href="/attachments/scodoc.list"
|
||||
download>scodoc.list</a> dans `/etc/apt/sources.list.d/`
|
||||
- Ajouter le dépôt scodoc: copier ce fichier <a href="/attachments/scodoc.list"
|
||||
download>scodoc-bullseye.list</a> dans `/etc/apt/sources.list.d/`
|
||||
ou le créer contenant juste cette ligne:
|
||||
|
||||
```text
|
||||
@ -241,7 +255,7 @@ ou le créer contenant juste cette ligne:
|
||||
apt-get install nginx
|
||||
```
|
||||
S'assurer que le logiciel `nginx` s'est bien installé. En cas de problème se
|
||||
référer à sa doc (par exemple, si
|
||||
référer à sa doc (par exemple, si
|
||||
[votre serveur ne supporte pas
|
||||
IPv6](https://techglimpse.com/nginx-error-address-family-solution/)).
|
||||
|
||||
@ -260,7 +274,7 @@ ou le créer contenant juste cette ligne:
|
||||
```
|
||||
|
||||
### 2.2) Configuration des logiciels et des données
|
||||
|
||||
|
||||
Lancer le script suivant en tant que `root` sur votre serveur nouvellement installé:
|
||||
|
||||
```bash
|
||||
@ -299,12 +313,17 @@ Ne pas hésiter à nous contacter (voir [contacts](Contact.md)).
|
||||
|
||||
Nota: sur certains réseaux, l'autoconfiguration IPv6 pose problème (par exemple:
|
||||
bloquage des envois de mails). Au besoin, il est possible de désactiver IPv6
|
||||
(voir par exemple [ici](https://wiki.debian-fr.xyz/D%C3%A9sactiver_l%27IPv6)).
|
||||
(voir par exemple [ici](https://wiki.debian-fr.xyz/D%C3%A9sactiver_l%27IPv6)).
|
||||
|
||||
## Ensuite...
|
||||
|
||||
- Mettez en place des [sauvegardes](SauvegardesBases.md)
|
||||
|
||||
- Si vous le souhaitez, vous pouvez mettre en place un anti-virus pour
|
||||
surveiller les fichiers uploadés par les utilisateurs. Les fichiers sont
|
||||
conservés dans `/opt/scodoc-data`: le plus simple est de faire surveiller tout
|
||||
ce répertoire sauf `/opt/scodoc-data/logs`.
|
||||
|
||||
- Abonnez-vous au moins à la liste d'annonces: voir [contacts](Contact.md)
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
@ -1,4 +1,4 @@
|
||||
# Configuration manuelle de ScoDoc sur Debian 11 (Bullseye)
|
||||
# Configuration manuelle de ScoDoc sur Debian 11 (Bullseye)
|
||||
|
||||
Instructions pour utilisateurs ne souhaitant pas utiliser le script
|
||||
|
||||
@ -8,7 +8,7 @@ Toutes les opérations décrites sur cette page sont effectuées par ce script.
|
||||
Cette page est donc destinée aux curieux et futurs développeurs. Se référer au
|
||||
script lui même pour les détails.
|
||||
|
||||
## Activation du firewall
|
||||
## Activation du firewall
|
||||
|
||||
(optionnel, recommandé)
|
||||
|
||||
|
342
docs/GuideInstallDebian12.md
Normal file
342
docs/GuideInstallDebian12.md
Normal file
@ -0,0 +1,342 @@
|
||||
|
||||
# Installation de ScoDoc 9.6+ sur Debian 12 (Bookworm)
|
||||
|
||||
Ce document décrit la procédure d'installation et de configuration de ScoDoc
|
||||
version 9.6 et suivantes.
|
||||
|
||||
Si vous mettez à jour une installation ScoDoc 9 existante (9.5 sous Debian 11
|
||||
Bullseye), suivez la
|
||||
[procédure de migration décrite sur cette page](UpgradeToDeb12Sco96.md).
|
||||
|
||||
La procédure décrite ici doit être effectué sur la machine serveur fraiche avec
|
||||
un accès administrateur (root). **Ne pas l'utiliser pour migrer une installation existante**.
|
||||
|
||||
ScoDoc est livré avec des scripts d'installation qui configurer presque
|
||||
automatiquement votre serveur (serveur web, base de données, etc): vous pouvez
|
||||
donc installer et configurer ScoDoc avec des connaissances réduites sur le
|
||||
système Linux.
|
||||
|
||||
Cette documentation est prévue pour installer ScoDoc version 9 sur un système
|
||||
[Debian](http://www.debian.org) 12 (Bookworm, stable) s'exécutant sur une
|
||||
machine intel-like **64bits** (architecture **AMD64** sur Intel/AMD, ou
|
||||
**aarch64** sur Apple ARM). Debian s'installe facilement en cinq minutes, sur
|
||||
une machine normale ou un serveur virtualisé. Il est **vivement déconseillé** de
|
||||
tenter l'installation sur une autre version de Linux.
|
||||
|
||||
Merci de signaler tout problème [sur le Discord](https://discord.gg/ybw6ugtFsZ).
|
||||
|
||||
- Note: l'image du CD d'installation de Debian (amd64) peut se trouver ici:
|
||||
[https://www.debian.org/CD/netinst/](https://www.debian.org/CD/netinst/),
|
||||
choisir la version "petits CD" pour **amd64**
|
||||
(*Il est indispensable d'utiliser une version 64 bits !*)
|
||||
|
||||
🚸 **Important:**
|
||||
|
||||
La procédure d'installation décrite ci-dessous suppose que ScoDoc va s'exécuter
|
||||
sur un serveur dédié. Pour faire des tests, utilisez un serveur virtuel (comme
|
||||
VirtualBox ou VMWare, ou UTM sur Mac). L'installation de ScoDoc va en effet
|
||||
modifier de nombreux paramètres de votre système Linux (serveur web, firewall,
|
||||
serveur SQL, messagerie, ...).
|
||||
|
||||
## 1) Préalable: configurer un serveur Linux
|
||||
|
||||
Le serveur devrait être accessible depuis Internet.
|
||||
|
||||
### Configuration matérielle
|
||||
|
||||
- taille disque: prévoir au moins 24Go sur la partition où sera scodoc (en
|
||||
général `/`).
|
||||
|
||||
- mémoire: prévoir au moins 8Go de RAM, et plutôt 12 ou 16.
|
||||
|
||||
### Informations sur les flux réseau
|
||||
|
||||
Le serveur est fréquemment installé sur un réseau protégé ou sur un VPN.
|
||||
|
||||
- le trafic entrant est sur le port 443 (le trafic http/80 est redirigé
|
||||
vers le https).
|
||||
|
||||
- le serveur doit pouvoir envoyer du mail (serveur Postfix en local, à
|
||||
configurer pour utiliser un relais smtp ou envoyer directement, selon votre
|
||||
politique. Au besoin, pour le reconfigurer, lancer `dpkg-reconfigure postfix`);
|
||||
|
||||
- Les serveurs de mise à jour de Debian doivent être accessibles (en http,
|
||||
voir `/etc/apt/sources.list`);
|
||||
|
||||
- Les serveurs `scodoc.org` et `scodoc.iutv.univ-paris13.fr` **doivent**
|
||||
être accessibles (80 et 443).
|
||||
|
||||
### Installation Linux Debian
|
||||
|
||||
Nous recommandons d'effectuer une installation standard de Debian par le réseau
|
||||
(netinst), et d'utiliser l'installation en mode texte, très simple et rapide.
|
||||
Durant l'installation de Debian, lorsqu'il demande "logiciels à installer", tout
|
||||
décocher sauf "Serveur SSH" et "Utilitaires standard du système". Le script
|
||||
d'installation de ScoDoc se chargera ensuite d'installer tous les éléments
|
||||
nécessaires (serveur web, messagerie, etc.).
|
||||
|
||||
🚸 *Veiller à sélectionner une locale `UTF-8` par défaut.*
|
||||
|
||||
![InstallDebian6-1.png](screens/InstallDebian6-1.png)
|
||||
|
||||
### Points à vérifier avant d'installer ScoDoc
|
||||
|
||||
Checklist minimale de votre système Linux Debian:
|
||||
|
||||
1. Connexion à Internet: le réseau doit être accessible. En effet, le script
|
||||
d'installation va installer des paquetages du système Debian puis
|
||||
télécharger la dernière mise à jour du logiciel ScoDoc (à partir du serveur
|
||||
scodoc.org).
|
||||
1. Vérifiez la connectivité, par exemple:
|
||||
|
||||
```bash
|
||||
ping www.univ-paris13.fr
|
||||
(quitter avec ctrl-c)
|
||||
cd /tmp
|
||||
wget --no-check-certificate https://scodoc.org
|
||||
# doit créer un fichier index.html contenant du code HTML...
|
||||
```
|
||||
3. Nom DNS: le serveur doit avoir un nom ("serveur.exemple.fr") connu dans le
|
||||
DNS (local ou public). Pour des tests, vous pouvez vous passer de DNS, mais
|
||||
dans ce cas le nom de votre serveur sera son adresse IP (eg `192.168.0.10`) et
|
||||
il ne sera peut être pas accessible de l'extérieur.
|
||||
4. Mail: vérifiez que le serveur peut envoyer des e-mail: `mail
|
||||
votre@adresse.fr`, puis entrer un message terminé par `ctrl-d`: si vous ne
|
||||
recevez pas le message après quelques minutes, vérifiez votre configuration
|
||||
(et le log `/var/log/mail.log`). Un serveur ScoDoc qui n'envoie pas de mail
|
||||
ne peut pas vérifier ceux des utilisateurs, qui à leur tour ne pourront pas
|
||||
changer leurs mots de passe (bien d'autres fonctions dépendent des mails).
|
||||
Au besoin, revoir la configuration avec `dpkg-reconfigure postfix` (voir
|
||||
aussi [envoi des courriers électroniques](ProblemesMail.md)).
|
||||
|
||||
1. Vérifiez que votre serveur est accessible depuis une autre machine de votre
|
||||
réseau (voire d'Internet): par exemple `ping serveur.exemple.fr`.
|
||||
1. Date et heure: vérifier que les dates et heure sont correctes, même après
|
||||
reboot. L'utilisation d'un serveur de temps (ntp) est recommandée (
|
||||
`apt-get install ntp`), et éventuellement `dpkg-reconfigure tzdata`).
|
||||
1. Si vous avez installé à partir d'un support (DVD, clé USB...), pensez à le
|
||||
retirer des sources Debian afin de ne pas bloquer les mises à jour (commenter
|
||||
la ligne `deb cdrom:` dans le fichier `/etc/apt/sources.list`)
|
||||
1. Cette liste est incomplète... et n'oubliez pas: avant de passer en
|
||||
production, mettez en place des sauvegardes sérieuses !
|
||||
|
||||
#### Configuration si utilisation d'un proxy
|
||||
|
||||
Si votre accès à Internet passe par un proxy, l'indiquer au moment de
|
||||
l'installation Debian.
|
||||
|
||||
Vérifiez aussi que ces variables sont bien définies dans `/etc/environment` (si
|
||||
l'installeur Linux Debian ne les a pas déjà indiquées là, les ajouter ou créer
|
||||
ce fichier):
|
||||
|
||||
```bash
|
||||
# /etc/environment
|
||||
export HTTP_PROXY=http://proxy.univ-xxx.fr:1234
|
||||
export HTTPS_PROXY=http://proxy.univ-xxx.fr:1234
|
||||
# Versions en minuscules utilisées par wget
|
||||
export http_proxy="${HTTP_PROXY}"
|
||||
export https_proxy="${HTTPS_PROXY}"
|
||||
```
|
||||
|
||||
Ensuite, après installation du paquet scodoc9 (voir plus bas), il faudra
|
||||
indiquer votre proxy: pour cela, éditer le fichier
|
||||
|
||||
```
|
||||
/opt/scodoc/.env
|
||||
```
|
||||
|
||||
et ajouter les variables d'environnement nécessaires. Typiquement, il s'agit de :
|
||||
|
||||
```bash
|
||||
HTTP_PROXY=http://proxy.univ-xxx.fr:1234
|
||||
HTTPS_PROXY=http://proxy.univ-xxx.fr:1234
|
||||
```
|
||||
|
||||
Après modification de ces fichiers (qui *doivent* être lisible par l'utilisateur `scodoc`),
|
||||
redémarrer le service:
|
||||
|
||||
```bash
|
||||
sudo systemctl restart scodoc9
|
||||
```
|
||||
|
||||
Dans les cas compliqués, il est possible qu'il vous faille configurer d'autres
|
||||
éléments, voir par exemple
|
||||
[ce post sur Stack Overflow](https://stackoverflow.com/questions/9445489/performing-http-requests-with-curl-using-proxy).
|
||||
|
||||
#### Note sur l'install dans un container LXC
|
||||
|
||||
Il y a deux possibilités :
|
||||
|
||||
**Option 1**, si vous installez dans un container LXC privilégié via le compte
|
||||
root et/ou sudo, attention: la config par défaut de Redis (un gestionnaire de
|
||||
cache utilisé par ScoDoc) n'est pas compatible, en raison d'un problème de
|
||||
système de fichier en lecture seule. Installer redis avant ScoDoc, comme suit:
|
||||
|
||||
```bash
|
||||
apt-get install redis
|
||||
```
|
||||
|
||||
Puis créer un dossier `/etc/systemd/system/redis.service.d` contenant le fichier
|
||||
`redis.conf` avec les lignes suivantes :
|
||||
|
||||
```text
|
||||
[Service]
|
||||
PrivateTmp=no
|
||||
ProtectSystem=false
|
||||
PrivateDevices=false
|
||||
ProtectHome=no
|
||||
ProtectControlGroups=no
|
||||
ProtectKernelTunables=no
|
||||
ProtectKernelModules=no
|
||||
ReadWritePaths=
|
||||
ReadOnlyDirectories=
|
||||
```
|
||||
|
||||
Ensuite
|
||||
|
||||
```bash
|
||||
systemctl daemon-reload
|
||||
systemctl start redis
|
||||
```
|
||||
|
||||
... et poursuivez l'installation comme ci-dessous.
|
||||
|
||||
**Option 2**, si vous installez dans un container LXC non-privilégié via un
|
||||
compte utilisateur normal, vous pouvez activer l'option « nesting »
|
||||
(imbriqué) de LXC pour permettre à Redis de fonctionner normalement.
|
||||
|
||||
🚸 Attention ! N'activez pas le *nesting* sur un conteneur privilégié. Cela
|
||||
provoquerait une faille de sécurité.
|
||||
|
||||
Si vous avez construit votre conteneur manuellement avec `lxc-create`, modifiez
|
||||
le fichier `/var/lib/lxc/${nomDuConteneur}/config` et ajoutez les lignes
|
||||
ci-dessous :
|
||||
|
||||
```text
|
||||
lxc.apparmor.allow_nesting = 1
|
||||
lxc.apparmor.profile = generated
|
||||
```
|
||||
|
||||
Si vous utilisez un conteneur LXC sur l'hyperviseur Proxmox, modifiez le
|
||||
fichier `/etc/pve/lxc/${CTID}.conf` et ajoutez la ligne suivante :
|
||||
|
||||
```text
|
||||
features: nesting=1
|
||||
```
|
||||
|
||||
... et poursuivez l'installation comme ci-dessous.
|
||||
|
||||
## 2) Installation de ScoDoc sur Debian
|
||||
|
||||
### 2.1) Charger le logiciel
|
||||
|
||||
🚸 Les commandes ci-dessous sont à exécuter dans un terminal ouvert en tant que
|
||||
**root** sur le serveur. Vous pouvez utiliser `su` (ou `sudo su`) pour devenir
|
||||
**root**).
|
||||
|
||||
Remarque: *Si ce n'est pas déjà le cas, vous avez intérêt à ouvrir une session
|
||||
`ssh` (ou `putty`) depuis une machine normale, afin de pouvoir copier/coller
|
||||
facilement les commandes et éditer les fichiers de configuration.*
|
||||
|
||||
|
||||
- Ajouter le dépot scodoc: copier ce fichier <a href="/attachments/scodoc.list"
|
||||
download>scodoc.list</a> dans `/etc/apt/sources.list.d/`
|
||||
ou bien le créer afin qu'il contienne juste cette ligne:
|
||||
|
||||
```text
|
||||
# contenu du fichier /etc/apt/sources.list.d/scodoc.list
|
||||
deb http://scodoc.org/deb/bookworm bookworm main
|
||||
```
|
||||
|
||||
- Installer la clé: en `root` sur le serveur, lancer
|
||||
|
||||
```bash
|
||||
apt-get -y install gnupg
|
||||
wget -O - https://scodoc.org/misc/scodoc-repo.gpg.key | apt-key add -
|
||||
```
|
||||
|
||||
- Installer le logiciel:
|
||||
|
||||
```bash
|
||||
apt-get update
|
||||
apt-get install nginx
|
||||
```
|
||||
S'assurer que le logiciel `nginx` s'est bien installé. En cas de problème se
|
||||
référer à sa doc (par exemple, si
|
||||
[votre serveur ne supporte pas
|
||||
IPv6](https://techglimpse.com/nginx-error-address-family-solution/)).
|
||||
|
||||
Ensuite:
|
||||
|
||||
```bash
|
||||
apt-get install scodoc9
|
||||
```
|
||||
|
||||
Notez que l'installation du paquet `scodoc9` va créer automatiquement un
|
||||
utilisateur `scodoc` qui sera utilisé par le serveur.
|
||||
|
||||
- Attribuer un mot de passe à l'utilisateur `scodoc`:
|
||||
|
||||
```bash
|
||||
passwd scodoc
|
||||
```
|
||||
|
||||
### 2.2) Configuration des logiciels et des données
|
||||
|
||||
Lancer le script suivant en tant que `root` sur votre serveur nouvellement installé:
|
||||
|
||||
```bash
|
||||
/opt/scodoc/tools/configure-scodoc9.sh
|
||||
```
|
||||
Vous devrez répondre à quelques questions et saisir le mot de passe que vous
|
||||
attribuerez à l'utilisateur `admin`.
|
||||
|
||||
(note: pour en savoir plus sur ce script, [voir l'explication](GuideInstallDebian11Advanced.md))
|
||||
|
||||
### 3) **Lancer ScoDoc**
|
||||
|
||||
```bash
|
||||
sudo su # se connecter en root
|
||||
systemctl restart nginx
|
||||
systemctl restart scodoc9
|
||||
```
|
||||
✨ et voila !
|
||||
|
||||
Visiter `https://monscodoc.mondomaine.fr/` pour achever la configuration et
|
||||
utiliser le logiciel: voir la page [GuideConfig](GuideConfig.md).
|
||||
|
||||
## Importation des données ScoDoc 7
|
||||
|
||||
Si vous aviez une installation très ancienne avec ScoDoc 7, vous pouvez migrer
|
||||
toutes vos données (comptes utilisateurs, étudiants, formations, notes, photos
|
||||
et fichiers divers) depuis une l'ancien serveur ScoDoc 7, ou même en place.
|
||||
|
||||
Voir [la procédure de migration](MigrationScoDoc7a9.md).
|
||||
|
||||
## En cas de problème
|
||||
|
||||
Ne pas hésiter à nous contacter (voir [contacts](Contact.md)).
|
||||
|
||||
- Problèmes d'envoi de courrier électronique (mail): voir [ProblemesMail](ProblemesMail.md)
|
||||
|
||||
Nota: sur certains réseaux, l'autoconfiguration IPv6 pose problème (par exemple:
|
||||
bloquage des envois de mails). Au besoin, il est possible de désactiver IPv6
|
||||
(voir par exemple [ici](https://wiki.debian-fr.xyz/D%C3%A9sactiver_l%27IPv6)).
|
||||
|
||||
## Ensuite...
|
||||
|
||||
- Mettez en place des [sauvegardes](SauvegardesBases.md)
|
||||
|
||||
- Si vous le souhaitez, vous pouvez mettre en place un anti-virus pour
|
||||
surveiller les fichiers uploadés par les utilisateurs. Les fichiers sont
|
||||
conservés dans `/opt/scodoc-data`: le plus simple est de faire surveiller tout
|
||||
ce répertoire sauf `/opt/scodoc-data/logs`.
|
||||
|
||||
- Abonnez-vous au moins à la liste d'annonces ou rejoignez le Discord: voir [contacts](Contact.md)
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Guide configuration](GuideConfig.md)
|
||||
- [Guide administrateur ScoDoc](GuideAdminSys.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
@ -1,5 +1,8 @@
|
||||
# Utilisation de ScoDoc
|
||||
|
||||
Les [principaux objets de ScoDoc](IntroObjetsScoDoc.md) sont présentés sur
|
||||
[cette page](IntroObjetsScoDoc.md).
|
||||
|
||||
ScoDoc contrôle les opérations via un mécanisme de permissions facile à mettre
|
||||
en œuvre et permettant de bien répartir les rôles entre les utilisateurs:
|
||||
responsables, enseignants, secrétariats.
|
||||
@ -11,11 +14,11 @@ paramétrages ne sont accessibles qu'au responsable de formation, ou chef de
|
||||
département.
|
||||
|
||||
* [Guide pour le responsable de formation](GuideAdminFormation.md)
|
||||
* [Modification d'un programme pédagogique et versions](VersionProgrammes.md)
|
||||
* [Modification d'un programme pédagogique et versions](Formations.md)
|
||||
* [Exemples et partages de programmes pédagogiques entre établissements](ExemplesProgrammesPedagogiques.md)
|
||||
|
||||
|
||||
* [Importation des étudiants](ImportationEtuds.md)
|
||||
|
||||
|
||||
* [Synchronisation des inscrits avec Apogée](SynchroApogee.md)
|
||||
* [Procédure d'inscription des étudiants via Apogée](InscriptionsEtudApogee.md)
|
||||
* [Données sur l'origine des étudiants](DonneesAdmissions.md)
|
||||
@ -30,7 +33,7 @@ département.
|
||||
|
||||
* [Édition des bulletins de notes](BulletinsNotes.md)
|
||||
* [paramétrage des bulletins pdf](ParametrageBulletins.md)
|
||||
|
||||
|
||||
* [Édition des PV de jury](ParametragePV.md)
|
||||
* Comment sont calculées les moyennes : [Calcul des notes](CalculNotes.md)
|
||||
|
||||
@ -40,11 +43,11 @@ département.
|
||||
|
||||
* [Saisie des décisions](SaisieDecisionsJury.md)
|
||||
* [Gestion des commissions et jurys, édition des PV](GestionJury.md)
|
||||
* [Capitalisation des UE](CapitalisationUE.md)
|
||||
* [Capitalisation des UEs](CapitalisationUE.md)
|
||||
|
||||
### Spécificités du BUT
|
||||
|
||||
(documentation à venir)
|
||||
* Voir [la page dédiée au BUT](BUT.md).
|
||||
|
||||
### Spécificités du DUT
|
||||
|
||||
|
@ -1,35 +1,52 @@
|
||||
# Importation d'étudiants (cas où l'on a pas de connexion directe à Apogée)
|
||||
|
||||
## Importation d'étudiants (cas où l'on a pas de connexion directe à Apogée)
|
||||
Les étudiants ne doivent être créés dans le système qu'une seule fois (lors de leur première inscription). Il sont ensuite suivi grâce à leur identifiant Apogée (ou à défaut leur code interne ScoDoc) qui ne varie pas. Insistons: les étudiants ne doivent être créés dans ScoDoc que lors de leur arrivée (premier semestre), ils sont ensuite suivis d'un semestre à l'autre.
|
||||
Les étudiants ne doivent être créés dans le système qu'une seule fois (lors de
|
||||
leur première inscription). Il sont ensuite suivi grâce à leur identifiant
|
||||
Apogée (ou à défaut leur code interne ScoDoc) qui ne varie pas. Insistons: les
|
||||
étudiants ne doivent être créés dans ScoDoc que lors de leur arrivée (premier
|
||||
semestre), ils sont ensuite suivis d'un semestre à l'autre.
|
||||
|
||||
Il est possible de créer les étudiants un par un (voir [CreationEtudIndividuel](CreationEtudIndividuel.md)) mais cela
|
||||
est rapidement fastidieux si l'on a plus d'une dizaine d'étudiants à inscrire. De plus, ce mode de fonctionnement tend à produire des erreurs de saisie et des doublons (le même étudiant créé deux fois dans des semestres différents, ce qui empêche le suivi de sa scolarité). Ces doublons posent de grandes difficultés et empêchent la gestion automatique des jurys: soyez vigilants lors des inscriptions.
|
||||
Il est possible de créer les étudiants un par un (voir
|
||||
[CreationEtudIndividuel](CreationEtudIndividuel.md)) mais cela est rapidement
|
||||
fastidieux si l'on a plus d'une dizaine d'étudiants à inscrire. De plus, ce mode
|
||||
de fonctionnement tend à produire des erreurs de saisie et des doublons (le même
|
||||
étudiant créé deux fois dans des semestres différents, ce qui empêche le suivi
|
||||
de sa scolarité). Ces doublons posent de grandes difficultés et empêchent la
|
||||
gestion automatique des jurys: soyez vigilants lors des inscriptions.
|
||||
|
||||
***On privilégiera donc l'import des étudiants depuis le portail (Apogée) à chaque fois que c'est possible. Voir [SynchroApogee](SynchroApogee.md).***
|
||||
***On privilégiera donc l'import des étudiants depuis le portail (Apogée) à
|
||||
chaque fois que c'est possible. Voir [SynchroApogee](SynchroApogee.md).***
|
||||
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> Le texte ci-dessous ne s'applique qu'aux établissement sans liaison ScoDoc-Apogée, et donc ***ne concerne pas l'IUT de Villetaneuse ! ***
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
|
||||
alt="/!\" /> Le texte ci-dessous ne s'applique qu'aux établissement sans liaison
|
||||
ScoDoc-Apogée, et donc ***ne concerne pas l'IUT de Villetaneuse !***
|
||||
|
||||
Si vous souhaitez importer une liste de nouveaux étudiants (inconnus de ScoDoc, même dans d'autres semestres) sans utiliser un portail Apogée, il suffit de créer un fichier tableur comportant
|
||||
toutes les informations requises. Le lien "importer de nouveaux étudiants"
|
||||
vous permet de télécharger une feuille Excel avec les colonnes. Une fois cette feuille remplie
|
||||
(une ligne par étudiant), cette feuille doit être renvoyée vers le
|
||||
logiciel (indiquer le nom du fichier et cliquer sur le bouton "Télécharger").
|
||||
Si vous souhaitez importer une liste de nouveaux étudiants (inconnus de ScoDoc,
|
||||
même dans d'autres semestres) sans utiliser un portail Apogée, il suffit de
|
||||
créer un fichier tableur comportant toutes les informations requises. Le lien
|
||||
"*importer de nouveaux étudiants*" vous permet de télécharger une feuille Excel
|
||||
avec les colonnes. Une fois cette feuille remplie (une ligne par étudiant),
|
||||
cette feuille doit être renvoyée vers le logiciel (indiquer le nom du fichier et
|
||||
cliquer sur le bouton "Télécharger").
|
||||
|
||||
![imprtetud1.png](screens/imprtetud1.png).
|
||||
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> Vous devez *impérativement* utiliser la feuille excel proposée par le site pour
|
||||
importer vos étudiants. Utiliser copier/coller pour remplir ses différentes colonnes.
|
||||
Seules les colonnes dont le titre est en rouge sont obligatoires, les autres peuvent
|
||||
être laissées vides, ou partiellement remplies.
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
|
||||
alt="/!\" /> Vous devez *impérativement* utiliser la feuille excel proposée par
|
||||
le site pour importer vos étudiants. Utiliser copier/coller pour remplir ses
|
||||
différentes colonnes. Seules les colonnes dont le titre est en rouge sont
|
||||
obligatoires, les autres peuvent être laissées vides, ou partiellement remplies.
|
||||
|
||||
Les étudiants importés vont être automatiquement inscrits dans le semestre
|
||||
choisi (et inscrits à tous les modules de ce semestre, sauf ceux de sport et
|
||||
culture). Il est donc nécessaire de créer le semestre *avant d'importer les
|
||||
étudiants*.
|
||||
|
||||
Les étudiants importés vont être automatiquement inscrits dans le semestre choisi (et inscrits à tous les modules de ce semestre, sauf ceux de sport et culture).
|
||||
Il est donc nécessaire de créer le semestre *avant d'importer les étudiants*.
|
||||
|
||||
Le plus simple est de passer par le lien "importer des étudiants" présent en bas du **tableau de bord semestre**.
|
||||
|
||||
Le plus simple est de passer par le lien "importer des étudiants" présent en bas
|
||||
du **tableau de bord semestre**.
|
||||
|
||||
Autres remarques:
|
||||
|
||||
* le champ 'SEXE' doit contenir ```MR``` (masculin) ou ```MLLE``` (féminin).
|
||||
* l'identité d'un étudiant (nom, prénom, civilité) peut quelquefois subir quelques variantes (voir [DonneesEtudiant](DonneesEtudiant.md))
|
||||
- le champ 'SEXE' doit contenir ```MR``` (masculin) ou ```MME``` (féminin).
|
||||
- l'identité d'un étudiant (nom, prénom, civilité) peut quelquefois subir
|
||||
quelques variantes (voir [DonneesEtudiant](DonneesEtudiant.md))
|
||||
|
@ -1,50 +1,56 @@
|
||||
# Inscription des étudiants via Apogée
|
||||
|
||||
# Inscription des étudiants via Apogée
|
||||
Les informations données ici ne concernent que les établissement qui ont mis en place une interface entre ScoDoc et le logiciel d'administration Apogée, comme à l'IUT de Villetaneuse.
|
||||
Cette interface repose sur l'utilisation d'un "portail" offrant les services décrits sur la page [InterrogationPortail](InterrogationPortail.md).
|
||||
Les informations données ici ne concernent que les établissement qui ont mis en
|
||||
place une interface entre ScoDoc et le logiciel d'administration Apogée, comme à
|
||||
l'IUT de Villetaneuse. Cette interface repose sur l'utilisation d'un "portail"
|
||||
offrant les services décrits sur la page
|
||||
[InterrogationPortail](InterrogationPortail.md).
|
||||
|
||||
## Généralités
|
||||
|
||||
On conserve la possibilité de créer les étudiants individuellement, ou de les
|
||||
importer d'un tableau Excel. Cependant, il est plus rationnel d'importer
|
||||
directement les étudiants depuis Apogée (le logiciel utilisé par la scolarité
|
||||
centrale).
|
||||
|
||||
## Généralités
|
||||
On conserve la possibilité de créer les étudiants individuellement, ou
|
||||
de les importer d'un tableau Excel. Cependant, il est plus rationnel d'importer directement les étudiants depuis Apogée (le logiciel utilisé par la scolarité centrale).
|
||||
Apogée identifie les sessions de formation (semestres) par un "code étape". Nous
|
||||
associons donc un code étape à chaque semestre ScoDoc. Lors de la création ou
|
||||
modification d'un semestre, ScoDoc présente la liste d'étapes disponible (cette
|
||||
liste peut être paramétrée dans ScoDoc via le fichier de configuration
|
||||
`config/default-etapes.txt` et/ou est fournie par le service `getEtapes` du
|
||||
portail, voir [détail techniques](InterrogationPortail.md)).
|
||||
|
||||
Apogée identifie les sessions de formation (semestres) par un "code étape". Nous associons donc un code étape à chaque semestre ScoDoc. Lors de la création ou modification
|
||||
d'un semestre, ScoDoc présente la liste d'étapes disponible (cette liste
|
||||
peut être paramétrée dans ScoDoc via le fichier de configuration `config/default-etapes.txt` et/ou est fournie par le service `getEtapes` du portail.
|
||||
Note: Apogée réutilise les mêmes codes étapes pour les sessions d'années
|
||||
différentes, ces codes changent donc rarement.
|
||||
|
||||
Note: Apogée réutilise les mêmes codes étapes pour les sessions d'années différentes, ces codes changent donc
|
||||
rarement.
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
|
||||
alt="/!\" /> certaines formations utilisent encore des codes Apogée *annuels*
|
||||
alors qu'elles sont semestrialisées.
|
||||
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> certaines formations utilisent encore des codes Apogée *annuels* alors qu'elles sont semestrialisées.
|
||||
Une fois le code étape défini, ScoDoc peut interroger Apogée pour obtenir la
|
||||
liste des étudiants inscrits dans cette étape. Les informations récupérées sont:
|
||||
|
||||
Une fois le code étape défini, ScoDoc peut interroger Apogée pour obtenir la liste des étudiants inscrits dans cette
|
||||
étape. Les informations récupérées sont:
|
||||
- identité (nom, prénom, civilité);
|
||||
- adresse (et téléphone).
|
||||
|
||||
* identité (nom, prénom, civilité);
|
||||
Apogée ne conserve pas (en général) les informations de type "admission" (lycée
|
||||
d'origine, notes et type du bac, ...), il faudra donc les importer séparément si
|
||||
on le souhaite (via le menu "Importer données admission").
|
||||
|
||||
* adresse (et téléphone).
|
||||
## Procédure à suivre pour le premier semestre (S1)
|
||||
|
||||
Apogée ne conserve pas (en général) les informations de type "admission" (lycée d'origine, notes et type du bac, ...),
|
||||
il faudra donc les importer séparément si on le souhaite (via le menu "Importer données admission").
|
||||
Listes Apogée presque complètes, faire l'import depuis le portail fin juillet,
|
||||
puis re-synchroniser fréquemment courant septembre. Voir
|
||||
[SynchroApogee](SynchroApogee.md)
|
||||
|
||||
- nouveaux étudiants, modification données personnelles
|
||||
|
||||
## Procédure à suivre pour le premier semestre (S1)
|
||||
Listes Apogée presques complètes, faire l'import depuis le portail fin juillet, puis synchros courant septembre. Voir [SynchroApogee](SynchroApogee.md)
|
||||
- import données admission (depuis fichier Excel)
|
||||
|
||||
* nouveaux etudiants, modifs données personnelles
|
||||
## Réinscriptions
|
||||
|
||||
* import données admission (depuis fichier Excel)
|
||||
Les étudiants ont jusqu'à fin octobre pour se réinscrire, il est probable que
|
||||
les listes Apogée ne soient pas à jour la semaine de la rentrée. On va donc
|
||||
utiliser le mécanisme de passage interne à ScoDoc, et faire une synchro fin
|
||||
octobre. Voir [TransitionSemestre](TransitionSemestre.md).
|
||||
|
||||
|
||||
## Réinscriptions
|
||||
Les étudiants ont jusqu'à fin octobre pour se réinscrire, il est probable que les listes
|
||||
Apogée ne soient pas à jour la semaine de la rentrée. On va donc utiliser le mécanisme de passage interne à ScoDoc,
|
||||
et faire une synchro fin octobre. Voir [TransitionSemestre](TransitionSemestre.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -1,48 +1,52 @@
|
||||
|
||||
# Interface avec un "portail" externe
|
||||
ScoDoc peut interagir avec un "portail" donnant des informations sur les étudiants.
|
||||
Ceci permet de synchroniser les données ScoDoc avec celles des applications
|
||||
externes comme Apogée. Pour simplifier l'administration, nous avons fait le choix
|
||||
d'intercaler entre ScoDoc et les applications type Apogée un "portail"
|
||||
(centralisation des autorisations, etc).
|
||||
# Interface avec un "portail" externe
|
||||
|
||||
Le portail interroge aussi ScoDoc (en particulier pour la publication des bulletins et pour
|
||||
effectuer l'export des décisions de jury vers Apogée). Voir les services offerts par ScoDoc
|
||||
sur la page [ServicesXml](ServicesXml.md).
|
||||
ScoDoc peut interagir avec un "portail" donnant des informations sur les
|
||||
étudiants. Ceci permet de synchroniser les données ScoDoc avec celles des
|
||||
applications externes comme Apogée. Pour simplifier l'administration, nous avons
|
||||
fait le choix d'intercaler entre ScoDoc et les applications type Apogée un
|
||||
"portail" (centralisation des autorisations, etc).
|
||||
|
||||
L'adresse du portail est indiquée dans la préférence ```portal_url``` (voir [PreferencesScoDoc](PreferencesScoDoc.md)).
|
||||
Le portail interroge aussi ScoDoc (en particulier pour la publication des
|
||||
bulletins et pour effectuer l'export des décisions de jury vers Apogée). Voir
|
||||
les services offerts par ScoDoc sur la page [ServicesXml](ServicesXml.md).
|
||||
|
||||
L'adresse du portail est indiquée dans la préférence ```portal_url``` (voir
|
||||
[PreferencesScoDoc](PreferencesScoDoc.md)).
|
||||
|
||||
Le code d'interface est dans le fichier source `sco_portal_apogee.py`.
|
||||
|
||||
Les trois appels suivants sont utilisés:
|
||||
|
||||
* `getEtud` : information sur un étudiant
|
||||
- `getEtud` : information sur un étudiant
|
||||
|
||||
* `getEtapes` : liste des étapes Apogée
|
||||
- `getEtapes` : liste des étapes Apogée
|
||||
|
||||
* `getPhoto` : image de l'étudiant
|
||||
- `getPhoto` : image de l'étudiant
|
||||
|
||||
Ces appels sont détaillés dans les sections suivantes.
|
||||
|
||||
## Information sur un étudiant
|
||||
|
||||
### Information sur un étudiant
|
||||
Le portail doit fournir une méthode web `getEtud.php` qui accepte les paramètres suivants:
|
||||
Le portail doit fournir une méthode web `getEtud.php` qui accepte les paramètres
|
||||
suivants:
|
||||
|
||||
- `nip` : code NIP
|
||||
- `nip` : code NIP
|
||||
|
||||
- `ine` : code INE
|
||||
|
||||
- `mail` : adresse e-mail
|
||||
- `ine` : code INE
|
||||
|
||||
- `nom` : nom de l'étudiant
|
||||
- `mail` : adresse e-mail
|
||||
|
||||
- `prenom` : prénom de l'étudiant
|
||||
- `nom` : nom de l'étudiant
|
||||
|
||||
- `etape` : code étape Apogée
|
||||
- `prenom` : prénom de l'étudiant
|
||||
|
||||
On peut spécifier un nombre quelconque de paramètres; `getEtud.php` recherche les étudiants
|
||||
correspondant aux critères indiqués, et renvoie du code XML:
|
||||
```
|
||||
- `etape` : code étape Apogée
|
||||
|
||||
On peut spécifier un nombre quelconque de paramètres; `getEtud.php` recherche
|
||||
les étudiants correspondant aux critères indiqués, et renvoie du code XML:
|
||||
|
||||
```xml
|
||||
<etudiants>
|
||||
<etudiant>
|
||||
<nip>20600577</nip>
|
||||
@ -54,8 +58,8 @@ correspondant aux critères indiqués, et renvoie du code XML:
|
||||
|
||||
<naissance>08/01/1990</naissance>
|
||||
<ville_naissance>Brest</ville_naissance>
|
||||
<code_dep_naissance>29</code_dep_naissance>
|
||||
<libelle_dep_naissance>Finisterre</libelle_dep_naissance>
|
||||
<code_dep_naissance>29</code_dep_naissance>
|
||||
<libelle_dep_naissance>Finisterre</libelle_dep_naissance>
|
||||
|
||||
<mail>melanie.bourton@xxx.univ-yyy.fr</mail>
|
||||
<address>11 Pierre Dupont</address>
|
||||
@ -70,11 +74,12 @@ correspondant aux critères indiqués, et renvoie du code XML:
|
||||
<anneebac>2007</anneebac>
|
||||
|
||||
<nom_lycee>nom du lycée</nom_lycee>
|
||||
<ville_lycee>ville lycée</ville_lycee>
|
||||
<codepostal_lycee>code postal lycée</codepostal_lycee>
|
||||
<ville_lycee>ville lycée</ville_lycee>
|
||||
<codepostal_lycee>code postal lycée</codepostal_lycee>
|
||||
|
||||
<datefinalisationinscription>10/07/24</datefinalisationinscription>
|
||||
<paiementinscription>true</paiementinscription>
|
||||
<bourse>N</bourse>
|
||||
<bourse>N</bourse>
|
||||
|
||||
</etudiant>
|
||||
<etudiant>
|
||||
@ -84,16 +89,47 @@ correspondant aux critères indiqués, et renvoie du code XML:
|
||||
</etudiants>
|
||||
```
|
||||
|
||||
Les champs `<lycee>` (code du lycée), `<bac>` (intitulé du bac), `<mention>`, `<anneebac>` et `<paiementinscription>` sont optionnels.
|
||||
Les champs `<lycee>` (code du lycée), `<bac>` (intitulé du bac), `<mention>`,
|
||||
`<anneebac>` et `<paiementinscription>` sont optionnels.
|
||||
|
||||
Le champ `<bac>` est un libellé, en général de la forme "ES-Economique et social". ScoDoc considère la première partie du libellé, jusqu'au caractère '-' comme la série du bac (uniquement si elle fait moins de 8 caractères). Le reste est alors considéré comme la "spécialité" du bac. Voir [DonneesAdmissions](DonneesAdmissions.md).
|
||||
Le champ `<bac>` est un libellé, en général de la forme "ES-Economique et
|
||||
social". ScoDoc considère la première partie du libellé, jusqu'au caractère '-'
|
||||
comme la série du bac (uniquement si elle fait moins de 8 caractères). Le reste
|
||||
est alors considéré comme la "spécialité" du bac. Voir
|
||||
[DonneesAdmissions](DonneesAdmissions.md).
|
||||
|
||||
Le champ `<paiementinscription>` (optionnel) vaut "true" ou "false" pour indiquer si l'étudiant a réglé ses frais d'inscription ou non.
|
||||
Le champ `<paiementinscription>` (optionnel) vaut "true" ou "false" pour
|
||||
indiquer si l'étudiant a réglé ses frais d'inscription ou non.
|
||||
|
||||
### Champs spécifiques à Apogée
|
||||
|
||||
Les champs suivant sont optionnels et donnent des informations spécifiques à
|
||||
Apogée:
|
||||
|
||||
```xml
|
||||
<cod_stu>01</cod_stu>
|
||||
<cod_rgi>1</cod_rgi>
|
||||
<tem_brs_iaa>O</tem_brs_iaa>
|
||||
<eta_edt_crt>E</eta_edt_crt>
|
||||
<dat_edt_crt>10/07/24</dat_edt_crt>
|
||||
<cod_pru>NO</cod_pru>
|
||||
<cod_dip>VBTCYB</cod_dip>
|
||||
<cod_etp>V2CYB</cod_etp>
|
||||
<tem_rgl_sit_mil>O</tem_rgl_sit_mil>
|
||||
```
|
||||
|
||||
Notes :
|
||||
|
||||
- `dat_edt_crt` est en principe la même chose que `datefinalisationinscription`:
|
||||
ce champ est vide si l'étudiant n'a pas finalisé son incription.
|
||||
|
||||
|
||||
### Liste des étapes Apogée
|
||||
`getEtapes.php` (pas de paramètres) renvoie un doc XML décrivant les étapes Apogée en cours. L'URL est paramétrable dans les préférences de ScoDoc.
|
||||
La structure est la suivante:
|
||||
## Liste des étapes Apogée
|
||||
|
||||
`getEtapes.php` (pas de paramètres) renvoie un doc XML décrivant les étapes
|
||||
Apogée en cours. L'URL est paramétrable dans les préférences de ScoDoc. La
|
||||
structure est la suivante:
|
||||
|
||||
```
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<etapes>
|
||||
@ -110,10 +146,16 @@ La structure est la suivante:
|
||||
...
|
||||
</etapes>
|
||||
```
|
||||
Le code département (cj ou rt dans l'exemple ci-dessous) est arbitraire et utilisé par ScoDoc pour ne présenter à l'utilisateur que les étapes de son département (voir la propriété *code du département sur le portail* dans les paramètres).
|
||||
|
||||
On peut aussi présenter une liste sans section par département, comme ceci: (cocher la préférence indiquant le format dans ScoDoc)
|
||||
```
|
||||
Le code département (cj ou rt dans l'exemple ci-dessous) est arbitraire et
|
||||
utilisé par ScoDoc pour ne présenter à l'utilisateur que les étapes de son
|
||||
département (voir la propriété *code du département sur le portail* dans les
|
||||
paramètres).
|
||||
|
||||
On peut aussi présenter une liste sans section par département, comme ceci:
|
||||
(cocher la préférence indiquant le format dans ScoDoc)
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<etapes>
|
||||
<etape code="V1XY">DUT CJ - Première Année</etape>
|
||||
@ -122,10 +164,11 @@ On peut aussi présenter une liste sans section par département, comme ceci: (c
|
||||
</etapes>
|
||||
```
|
||||
|
||||
### Image de l'étudiant
|
||||
## Image de l'étudiant
|
||||
|
||||
`getPhoto.php` accepte le paramètre suivant:
|
||||
|
||||
- `nip` : code NIP
|
||||
- `nip` : code NIP
|
||||
|
||||
et renvoie une image de l'étudiant (dans l'un des formats supportés par les navigateurs web).
|
||||
Si l'image ou l'étudiant n'existe pas, un code HTTP 404 peut être renvoyé.
|
||||
|
153
docs/IntroObjetsScoDoc.md
Normal file
153
docs/IntroObjetsScoDoc.md
Normal file
@ -0,0 +1,153 @@
|
||||
# Les principaux objets de ScoDoc
|
||||
|
||||
Nous introduisons ici les principaux objets manipulés par ScoDoc.
|
||||
|
||||
## Départements
|
||||
|
||||
Un serveur ScoDoc peut gérer un nombre quelconque de départements. Les
|
||||
départements sont entièrement séparés, à l'exception des comptes utilisateurs
|
||||
(un secrétaire ou une enseignante peuvent intervenir dans plusieurs
|
||||
départements). Les étudiants et les formations sont rattachés à un et un seul
|
||||
département.
|
||||
|
||||
Lorsqu'un utilisateur se connecte, il voit en bleu les liens vers les
|
||||
départements dans lesquels il a le droit d'aller.
|
||||
|
||||
![sco-accueil-0223.png](screens/sco-accueil-0223.png)
|
||||
|
||||
## Semestre
|
||||
|
||||
Un *semestre* représente une session d'un dispositif de formation. La plupart des
|
||||
formations LMD sont structurées en années scolaires de deux semestres. Dans
|
||||
ScoDoc, un "semestre" peut avoir une durée quelconque, il peut aussi bien s'agir
|
||||
une action de formation continue d'une semaine que d'une formation sur un an.
|
||||
|
||||
Saisie des dates de début et fin d'un semestre:
|
||||
![sco-dates-semestre.png](screens/sco-dates-semestre.png)
|
||||
|
||||
Chaque semestre a un ou plusieurs (co)responsables, utilisateurs ayant des droits
|
||||
particuliers, dont ceux de modifier la liste des modules d'enseignement à
|
||||
suivre, de nommer les enseignants, etc. Les responsables de semestres sont
|
||||
souvent appelés *directeurs ou directrices des études*.
|
||||
|
||||
Un semestre a un ensemble d'étudiants inscrits.
|
||||
|
||||
Le tableau de bord du semestre indique notamment la liste des modules qui y sont
|
||||
proposés:
|
||||
![sco-formsemestre-status.png](screens/sco-formsemestre-status.png)
|
||||
|
||||
|
||||
## Formations (programmes pédagogiques)
|
||||
|
||||
Un semestre utilise une *formation* (programme pédagogique) qui définit les
|
||||
unités d'enseignement (UE), modules, coefficients, crédits académiques, etc.
|
||||
Pour en savoir plus, voir [programmes pédagogiques et versions](Formations.md).
|
||||
|
||||
Exemple: une formation de *Bachelor Universitaire de Technologie* (BUT):
|
||||
![sco-formation-but.png](screens/sco-formation-but.png)
|
||||
|
||||
## Modules
|
||||
|
||||
Un *module* représente un dispositif pédagogique, typiquement un ensemble de
|
||||
cours, travaux dirigés, travaux pratiques, mais il peut aussi s'agir d'un
|
||||
projet, d'un stage, ou de tout ensemble d'activités.
|
||||
|
||||
Un module a un enseignant responsable (typiquement le chargé de cours) et des
|
||||
des enseignants associés (typiquement les chargés de TD).
|
||||
|
||||
Un sous-ensemble des étudiants inscrits au semestre peut être inscrit au module.
|
||||
|
||||
En BUT, les modules représentent les *ressources* et les SAÉs.
|
||||
|
||||
Le tableau de bord d'un module permet d'y inscrire les étudiants, modifier les
|
||||
enseignants, créer des évaluations et y saisir des notes.
|
||||
Exemple: une ressource de BUT
|
||||
![sco-modimpl-status.png](screens/sco-modimpl-status.png)
|
||||
|
||||
## Évaluations
|
||||
|
||||
Une *évaluation* est un dispositif pédagogique produisant une note par étudiant.
|
||||
Les notes sont numériques, mais dans les formations en approche par compétences
|
||||
(APC), les évaluations peuvent être associées à des *apprentissages critiques*.
|
||||
|
||||
Pour en savoir plus:
|
||||
|
||||
- [Les évaluations](Evaluation.md)
|
||||
- [Calcul des notes](CalculNotes.md)
|
||||
- [Bachelor Universitaire de Technologie (BUT)](BUT.md)
|
||||
|
||||
Exemple: modification d'une évaluation
|
||||
![sco-evaluation-edit.png](screens/sco-evaluation-edit.png)
|
||||
|
||||
## Étudiants
|
||||
|
||||
Un étudiant peut être créé individuellement par formulaire, ou bien importé via
|
||||
une feuille de calcul (par exemple Excel), ou, via un connecteur API, importé
|
||||
depuis un autre système (Apogée, Pégase, annuaire...).
|
||||
|
||||
Les étudiants sont rattachés à un et un seul département (en cas de transfert,
|
||||
le créer dans l'autre département). Chaque étudiant peut être inscrit à un
|
||||
nombre quelconque de semestres (en général, à un instant $t$, l'étudiant a un
|
||||
seul semestre en cours, mais il arrive que les semestres suivis se chevauchent).
|
||||
|
||||
La fiche de l'étudiant rassemble de nombreuses informations: données d'état
|
||||
civil, coordonnées, photographie, semestres suivis et leurs résultats résumés,
|
||||
annotations, etc. Ces informations peuvent être modifiées dans ScoDoc. Les accès
|
||||
et les droits de modification sont contrôlés par des autorisations spécifiques,
|
||||
tous les utilisateurs n'ont pas accès aux mêmes vues.
|
||||
|
||||
Exemple: extrait de la fiche d'un étudiant
|
||||
![sco-fiche-etud.png](screens/sco-fiche-etud.png)
|
||||
|
||||
## Groupes et partitions
|
||||
|
||||
Les étudiants d'un semestre peuvent être répartis dans des groupes.
|
||||
|
||||
Chaque *partition* d'un semestre défini un ensemble de groupes: par exemple,
|
||||
la partition des groupes de TD, ou la partition des projets tuteurés.
|
||||
|
||||
On peut à tout moment créer une partition, y créer des groupes, y placer ou
|
||||
déplacer des étudiants.
|
||||
|
||||
Exemple: l'éditeur de partitions
|
||||
![sco-partition-edit.png](screens/sco-partition-edit.png)
|
||||
|
||||
|
||||
|
||||
## Utilisateurs
|
||||
|
||||
ScoDoc gère des comptes utilisateur, et associe à chacun des rôles spécifiques,
|
||||
eux-mêmes associés à des permissions (droits d'accès). ce système permet de
|
||||
hiérarchiser l'accès aux informations et opérations sensibles (modification de
|
||||
résultats, inscriptions, éditions de procès-verbaux, etc.).
|
||||
|
||||
- [Rôles et permissions dans ScoDoc](ConfigPermissionsDept.md)
|
||||
- [Gestion des utilisateurs dans ScoDoc](AdminUsers.md)
|
||||
|
||||
### Administrateur de département
|
||||
|
||||
L'administrateur d'un département (typiquement le responsable de formation ou
|
||||
chef de département, ou bien une personne de confiance) possède des droits
|
||||
étendus sur son département (rassemblés dans le rôle `AdminDept`). Il peut
|
||||
notamment modifier les formations, mettre en place des semestres, créer des
|
||||
comptes utilisateurs.
|
||||
|
||||
### Super-administrateur
|
||||
|
||||
Le super-administrateur est un utilisateur ayant des droits d'accès complet au
|
||||
logiciel. Ce compte ne doit pas être utilisé pour autre chose que le paramétrage
|
||||
global. Il est le seul à avoir accès aux pages de configuration, accessibles via
|
||||
la page d'accueil:
|
||||
|
||||
![sco-config-generale.png](screens/sco-config-generale.png)
|
||||
|
||||
## Assiduité et justificatifs
|
||||
|
||||
Voir [Suivi de l'assiduité](Assiduites.md).
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Guide utilisateur](GuideUtilisateur.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
@ -1,5 +1,5 @@
|
||||
|
||||
# Migration d'une installation existante de ScoDoc
|
||||
# Migration d'une installation existante de ScoDoc
|
||||
Marche à suivre pour transférer les données d'un serveur ScoDoc déjà existant vers un autre. Cas d'usage typiques:
|
||||
|
||||
* changement de machine physique
|
||||
@ -10,8 +10,8 @@ Marche à suivre pour transférer les données d'un serveur ScoDoc déjà exista
|
||||
Toutes les données seront copiées: bases SQL, configurations, photos, archives, logs.
|
||||
|
||||
|
||||
## Principe
|
||||
Au lieu de mettre à jour le système Debian, il est préférable de **réinstaller complètement un nouveau serveur**. En effet, ScoDoc utilise certains composants qui ne sont pas fournis dans les versions adéquates par Debian.
|
||||
## Principe
|
||||
Au lieu de mettre à jour le système Debian, il est préférable de **réinstaller complètement un nouveau serveur**. En effet, ScoDoc utilise certains composants qui ne sont pas fournis dans les versions adéquates par Debian.
|
||||
|
||||
L'expérience montre qu'il est plus rapide de **tout réinstaller** sans se poser de questions. D'ailleurs, la plupart des installations étant sur des serveurs virtualisés, cette méthode est souvent plus simple et évite de toucher au serveur en production. J'insiste : **ne tentez pas de mettre à jour le système Debian de votre ancien serveur**, c'est une perte de temps.
|
||||
|
||||
@ -22,14 +22,14 @@ Le principe est donc:
|
||||
3. Copier les données d'un serveur à l'autre (scripts fournis);
|
||||
4. Tester, puis le cas échéant couper l'ancien serveur et le remplacer par le nouveau.
|
||||
|
||||
## Marche à suivre détaillée
|
||||
|
||||
## Marche à suivre détaillée
|
||||
### Installation de Debian et ScoDoc
|
||||
Voir les instructions ici: [GuideInstallDebian11](GuideInstallDebian11.md).
|
||||
### Installation de Debian et ScoDoc
|
||||
|
||||
Voir les instructions ici: [GuideInstallDebian12](GuideInstallDebian12.md).
|
||||
|
||||
### Copie des données d'un serveur à l'autre
|
||||
|
||||
### Copie des données d'un serveur à l'autre
|
||||
Il est important de suivre rigoureusement et pas à pas cette procédure:
|
||||
|
||||
1. S'assurer que le serveur de départ est à jour (pour avoir le bon script de sauvegarde!): voir [MisesAJour](MisesAJour.md)
|
||||
|
@ -1,7 +1,7 @@
|
||||
# Migration des données ScoDoc 7 vers ScoDoc 9
|
||||
|
||||
On peut installer à partir de zéro (cas 1), ou sur une machine ayant déjà un ScoDoc 7
|
||||
et migrer les données (cas 2).
|
||||
On peut installer à partir de zéro (cas 1), ou sur une machine ayant déjà un ScoDoc 7
|
||||
et migrer les données (cas 2).
|
||||
|
||||
## Cas 1: Migration d'une installation ScoDoc 7 sur un nouveau serveur
|
||||
|
||||
@ -11,8 +11,8 @@ basculer d'une version à l'autre.
|
||||
|
||||
Dans ce cas, la migration va se faire en suivant les étapes, détaillées plus loin:
|
||||
|
||||
1. installer le nouveau serveur Linux Debian 11 et ScoDoc 9;
|
||||
|
||||
1. installer le nouveau serveur Linux Debian et ScoDoc 9;
|
||||
|
||||
2. sauvegarder les données de ScoDoc7 depuis le serveur de production **et l'arrêter**;
|
||||
|
||||
3. charger les données ScoDoc 7 sur le nouveau serveur;
|
||||
@ -23,9 +23,9 @@ Si vous venez d'installer ScoDoc 9, passez directement à l'**étape 3**.
|
||||
|
||||
### Étape 1: Installer le nouveau serveur
|
||||
|
||||
Installer le nouveau serveur avec Debian 11 et ScoDoc 9.
|
||||
Installer le nouveau serveur avec Debian 12 et ScoDoc 9.
|
||||
|
||||
Voir [GuideInstallDebian11](GuideInstallDebian11.md).
|
||||
Voir [GuideInstallDebian12](GuideInstallDebian12.md).
|
||||
|
||||
Vérifier que tout fonctionne avant d'aller plus loin.
|
||||
|
||||
@ -41,7 +41,7 @@ Ouvrir un terminal en tant que `root`sur l'ancien serveur ScoDoc 7.
|
||||
# Export des données
|
||||
./save_scodoc7_data.sh /tmp/sauvegarde-scodoc7
|
||||
|
||||
Attention à l'espace disque: au besoin, faire le ménage ou montez un disque supplémentaire.
|
||||
Attention à l'espace disque: au besoin, faire le ménage ou montez un disque supplémentaire.
|
||||
|
||||
Notez que cette migration ne fonctionne qu'à partir de la dernière version de
|
||||
ScoDoc 7. Si vous avez une version plus ancienne, mettez-la d'abord à jour.
|
||||
@ -140,24 +140,25 @@ officielle](https://www.debian.org/releases/bullseye/mips64el/release-notes/ch-u
|
||||
est longue, mais en réalité c'est très simple et prends moins de 10 minutes,
|
||||
sauf si vous avez configuré votre système de façon exotique.
|
||||
Nombreux tutos disponibles, voir [par exemple
|
||||
celui-ci](https://www.cyberciti.biz/faq/update-upgrade-debian-10-to-debian-11-bullseye/).
|
||||
celui-ci](https://www.cyberciti.biz/faq/update-upgrade-debian-10-to-debian-11-bullseye/).
|
||||
|
||||
Attention, il faut désinstaller Apache (avant ou après upgrade Linux), car
|
||||
ScoDoc 9 utilise un autre serveur web (nginx) qui serait en conflit:
|
||||
|
||||
# peut être utile pour récuperer vos certificats SSL ?
|
||||
mv /etc/apache2 /etc/apache2.old
|
||||
mv /etc/apache2 /etc/apache2.old
|
||||
apt-get remove --purge apache2
|
||||
|
||||
|
||||
|
||||
### 3. Installer ScoDoc 9
|
||||
Voir [la section 2 du guide d'installation](GuideInstallDebian11.md#2-installation-de-scodoc-sur-debian).
|
||||
|
||||
Voir [la section 2 du guide d'installation](GuideInstallDebian12.md#2-installation-de-scodoc-sur-debian).
|
||||
|
||||
Vérifier que tout fonctionne avant d'aller plus loin.
|
||||
|
||||
### 4. Migrer vos données ScoDoc 7
|
||||
|
||||
Les données sont restées dans /opt/scodoc7.
|
||||
Les données sont restées dans `/opt/scodoc7`.
|
||||
|
||||
Lancer le script suivant en tant que `root`:
|
||||
|
||||
@ -186,5 +187,3 @@ Au besoin, réglez la fonction de calcul du **bonus sport&culture** via la page
|
||||
"configuration" accessible depuis la page d'accueil en tant qu'admin uniquement.
|
||||
|
||||
Célébrez !
|
||||
|
||||
|
||||
|
@ -70,7 +70,7 @@ Chaque module peut être associé à un ou plusieurs parcours, via la table
|
||||
d'association `ApcParcours` <-> `Module` (`parcours_modules`, many-to-many).
|
||||
|
||||
Via *Formation*/*Modification du module*:<br>
|
||||
<img src="/fig/module_choix_parcours.png" width="50%">
|
||||
<img src="/screens/module_choix_parcours.png" width="50%">
|
||||
|
||||
On peut ainsi vérifier que les parcours couvrent les AC, et faciliter les
|
||||
inscriptions des étudiants aux modules (par ex. page présentant les modules
|
||||
@ -539,7 +539,7 @@ erDiagram
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Informations pour les développeurs](Internals.md)
|
||||
- [Informations pour les développeurs](GuideDeveloppeurs.md)
|
||||
- [API ScoDoc 9](ScoDoc9API.md)
|
||||
- [Le Bachelor Universitaire de Technologie (BUT)](BUT.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
@ -1,11 +0,0 @@
|
||||
|
||||
# Notes de malus
|
||||
Il est fréquent d'introduire des pénalités ou *malus* sur les moyennes calculées à partir des notes. Par exemple, dans certains établissements, l'absence de l'étudiant à des activités obligatoires peut entrainer des points de pénalités. Inversement, certaines activités facultatives pourraient donner lieu à des bonifications.
|
||||
|
||||
Pour gérer cela ScoDoc propose de déclarer des modules de *malus*: les notes de malus sont directement *soustraites* à la moyenne générale. Contrairement aux notes ordinaires dans ScoDoc, les notes de malus sont toujours comprises entre -20 et +20. Une note de malus de 1 va diminuer la moyenne de l'UE de 1. Une note négative augmenterait cette moyenne. Les moyennes d'UE sont toujours comprises entre 0 et 20: si l'application du malus donne une note supérieure à 20 (ou inférieure à zéro), elle est ramenée à 20 (ou à zéro).
|
||||
|
||||
Lors de la création d'un module dans un programme pédagogique, on peut spécifier son type. Il est aussi possible de créer directement un module malus par UE du programme, via le lien "Ajouter des modules de malus dans chaque UE" en bas du programme.
|
||||
|
||||
Une fois le module créé (et ajouté à un semestre), on peut y déclarer une évaluation et saisir les notes de bonus/malus.
|
||||
Ces notes sont toujours *à prise en compte immédiate*, il n'est donc pas nécessaire de saisir des notes de malus pour tous les étudiants.
|
||||
|
@ -1,15 +1,18 @@
|
||||
# Préférences de ScoDoc
|
||||
|
||||
## Préférences de ScoDoc
|
||||
Ces variables sont modifiables globalement ou seulement pour un semestre spécifique (sauf pour certaines d'entre elles, qui n'ont de sens que globalement). Si un semestre défini une variable (via la page "Préférences du semestre" accessible dans le menu "Semestre"), sa valeur remplace, pour lui seulement, celle définie globalement (via la page "Paramétrage").
|
||||
Ces variables sont modifiables globalement ou seulement pour un semestre
|
||||
spécifique (sauf pour certaines d'entre elles, qui n'ont de sens que
|
||||
globalement). Si un semestre défini une variable (via la page "Préférences du
|
||||
semestre" accessible dans le menu "Semestre"), sa valeur remplace, pour lui
|
||||
seulement, celle définie globalement (via la page "Paramétrage").
|
||||
|
||||
*Page générée à l'aide de la méthode* `doc_preferences`
|
||||
|
||||
|
||||
## Générales
|
||||
|
||||
Nom | |
|
||||
---- | ---- | ----
|
||||
`DeptName` | Nom abrégé du département |
|
||||
`DeptName` | Nom abrégé du département |
|
||||
`DeptFullName` | Nom complet du département | inutilisé par défaut
|
||||
`UnivName` | Nom de l'Université | apparait sur les bulletins et PV de jury
|
||||
`InstituteName` | Nom de l'Institut | exemple "IUT de Villetaneuse". Peut être utilisé sur les bulletins.
|
||||
@ -29,7 +32,7 @@ Nom | |
|
||||
Nom | |
|
||||
---- | ---- | ----
|
||||
`email_chefdpt` | e-mail chef du département | utilisé pour envoi mail notification absences
|
||||
`work_saturday` | Considérer le samedi comme travaillé |
|
||||
`work_saturday` | Considérer le samedi comme travaillé |
|
||||
`handle_billets_abs` | Gestion de "billets" d'absence | fonctions pour traiter les "billets" déclarés par les étudiants sur un portail externe
|
||||
`abs_notify_chief` | Notifier les absences au chef | Envoyer un mail au chef si un étudiant a beaucoup d'absences
|
||||
`abs_notify_respsem` | Notifier les absences au dir. des études | Envoyer un mail au responsable du semestre si un étudiant a beaucoup d'absences
|
||||
@ -45,9 +48,9 @@ Nom | |
|
||||
|
||||
Nom | |
|
||||
---- | ---- | ----
|
||||
`portal_url` | URL du portail |
|
||||
`portal_url` | URL du portail |
|
||||
`portal_timeout` | timeout | secondes
|
||||
`portal_dept_name` | Code du département sur le portail |
|
||||
`portal_dept_name` | Code du département sur le portail |
|
||||
`etapes_url` | URL listant les étapes Apogée | par defaut, selon l'api, getEtapes ou scodocEtapes sur l'URL du portail
|
||||
`maquette_url` | URL maquettes Apogee | par defaut, scodocMaquette sur l'URL du portail
|
||||
`portal_api` | Version de l'API | 1 ou 2
|
||||
@ -71,8 +74,8 @@ Nom | |
|
||||
`SCOLAR_FONT` | Police de caractère principale | pour les pdf
|
||||
`SCOLAR_FONT_SIZE` | Taille des caractères | pour les pdf
|
||||
`SCOLAR_FONT_SIZE_FOOT` | Taille des caractères pied de page | pour les pdf
|
||||
`pdf_footer_x` | Position horizontale du pied de page pdf (en mm) |
|
||||
`pdf_footer_y` | Position verticale du pied de page pdf (en mm) |
|
||||
`pdf_footer_x` | Position horizontale du pied de page pdf (en mm) |
|
||||
`pdf_footer_y` | Position verticale du pied de page pdf (en mm) |
|
||||
|
||||
## Procès verbaux de jury (documents PDF)
|
||||
|
||||
@ -84,21 +87,21 @@ Nom | |
|
||||
`INSTITUTION_NAME` | Nom institution sur pied de pages PV | (pdf, balises <b> interprétées)
|
||||
`INSTITUTION_ADDRESS` | Adresse institution sur pied de pages PV | (pdf, balises <b> interprétées)
|
||||
`INSTITUTION_CITY` | Ville de l'institution | pour les lettres individuelles
|
||||
`PV_INTRO` | Paragraphe d'introduction sur le PV | Balises remplacées: %(Univname)s = nom de l'université, %(DecNum)s = numéro de l'arrêté, %(Date)s = date de la commission, %(Type)s = type de commission (passage ou délivrance)
|
||||
`PV_WITH_BACKGROUND` | Mettre l'image de fond sur les PV de jury (paysage) |
|
||||
`PV_WITH_HEADER` | Ajouter l'en-tête sur les PV (paysage) |
|
||||
`PV_WITH_FOOTER` | Ajouter le pied de page sur les PV (paysage) |
|
||||
`pv_left_margin` | Marge gauche PV en mm |
|
||||
`pv_top_margin` | Marge haute PV |
|
||||
`pv_right_margin` | Marge droite PV |
|
||||
`pv_bottom_margin` | Marge basse PV |
|
||||
`PV_INTRO` | Paragraphe d'introduction sur le PV | Balises remplacées: %(Univname)s = nom de l'université, %(DecNum)s = numéro de l'arrêté, %(Date)s = date de la commission, %(Type)s = type de commission (passage ou délivrance)
|
||||
`PV_WITH_BACKGROUND` | Mettre l'image de fond sur les PV de jury (paysage) |
|
||||
`PV_WITH_HEADER` | Ajouter l'en-tête sur les PV (paysage) |
|
||||
`PV_WITH_FOOTER` | Ajouter le pied de page sur les PV (paysage) |
|
||||
`pv_left_margin` | Marge gauche PV en mm |
|
||||
`pv_top_margin` | Marge haute PV |
|
||||
`pv_right_margin` | Marge droite PV |
|
||||
`pv_bottom_margin` | Marge basse PV |
|
||||
`PV_LETTER_DIPLOMA_SIGNATURE` | Signature des lettres individuelles de diplôme | %(DirectorName)s et %(DirectorTitle)s remplacés
|
||||
`PV_LETTER_PASSAGE_SIGNATURE` | Signature des lettres individuelles de passage d'un semestre à l'autre | %(DirectorName)s et %(DirectorTitle)s remplacés
|
||||
`pv_sig_image_height` | Hauteur de l'image de la signature | Lorsqu'on donne une image de signature, elle est redimensionnée à cette taille (en millimètres)
|
||||
`PV_LETTER_TEMPLATE` | Lettre individuelle | Balises remplacées et balisage XML, voir la documentation
|
||||
`PV_LETTER_WITH_BACKGROUND` | Mettre l'image de fond sur les lettres individuelles de décision |
|
||||
`PV_LETTER_WITH_HEADER` | Ajouter l'en-tête sur les lettres individuelles de décision |
|
||||
`PV_LETTER_WITH_FOOTER` | Ajouter le pied de page sur les lettres individuelles de décision |
|
||||
`PV_LETTER_WITH_BACKGROUND` | Mettre l'image de fond sur les lettres individuelles de décision |
|
||||
`PV_LETTER_WITH_HEADER` | Ajouter l'en-tête sur les lettres individuelles de décision |
|
||||
`PV_LETTER_WITH_FOOTER` | Ajouter le pied de page sur les lettres individuelles de décision |
|
||||
`pv_htab1` | marge colonne droite lettre | pour les courriers pdf
|
||||
`pv_htab2` | marge colonne gauche lettre | pour les courriers pdf
|
||||
`PV_FONTNAME` | Police de caractère pour les PV | pour les pdf
|
||||
@ -109,32 +112,31 @@ Nom | |
|
||||
---- | ---- | ----
|
||||
`bul_title` | Titre des bulletins | <tt>%(DeptName)s</tt> est remplacé par le nom du département
|
||||
`bul_class_name` | Format des bulletins | format de présentation des bulletins de note (web et pdf)
|
||||
`bul_show_abs` | Indiquer les absences sous les bulletins |
|
||||
`bul_show_abs_modules` | Indiquer les absences dans chaque module |
|
||||
`bul_show_decision` | Faire figurer les décisions sur les bulletins |
|
||||
`bul_show_abs` | Indiquer les absences sous les bulletins |
|
||||
`bul_show_abs_modules` | Indiquer les absences dans chaque module |
|
||||
`bul_show_decision` | Faire figurer les décisions sur les bulletins |
|
||||
`bul_show_ects` | Faire figurer les ECTS sur les bulletins | crédits associés aux UE ou aux modules, selon réglage
|
||||
`bul_show_codemodules` | Afficher codes des modules sur les bulletins |
|
||||
`bul_show_matieres` | Afficher les matières sur les bulletins |
|
||||
`bul_show_codemodules` | Afficher codes des modules sur les bulletins |
|
||||
`bul_show_matieres` | Afficher les matières sur les bulletins |
|
||||
`bul_show_all_evals` | Afficher toutes les évaluations sur les bulletins | y compris incomplètes ou futures
|
||||
`bul_show_rangs` | Afficher le classement sur les bulletins |
|
||||
`bul_show_ue_rangs` | Afficher le classement dans chaque UE sur les bulletins |
|
||||
`bul_show_mod_rangs` | Afficher le classement dans chaque module sur les bulletins |
|
||||
`bul_show_moypromo` | Afficher moyennes de la promotion sur les bulletins |
|
||||
`bul_show_minmax` | Afficher min/max moyennes sur les bulletins |
|
||||
`bul_show_minmax_mod` | Afficher min/max moyennes des modules sur les bulletins |
|
||||
`bul_show_minmax_eval` | Afficher min/max moyennes des évaluations sur les bulletins |
|
||||
`bul_show_coef` | Afficher coefficient des ue/modules sur les bulletins |
|
||||
`bul_show_ue_cap_details` | Afficher détail des notes des UE capitalisées sur les bulletins |
|
||||
`bul_show_ue_cap_current` | Afficher les UE en cours mais capitalisées sur les bulletins |
|
||||
`bul_show_temporary_forced` | Bannière "provisoire" sur les bulletins |
|
||||
`bul_show_temporary` | Bannière "provisoire" si pas de décision de jury |
|
||||
`bul_temporary_txt` | Texte de la bannière "provisoire |
|
||||
`bul_show_uevalid` | Faire figurer les UE validées sur les bulletins |
|
||||
`bul_show_mention` | Faire figurer les mentions sur les bulletins et les PV |
|
||||
`bul_show_date_inscr` | Faire figurer la date d'inscription sur les bulletins |
|
||||
`bul_show_sig_left` | Faire figurer le pied de page de gauche (ex.: nom du directeur) sur les bulletins |
|
||||
`bul_show_sig_right` | Faire figurer le pied de page de droite (ex.: nom du chef de département) sur les bulletins |
|
||||
`bul_display_publication` | Indique si les bulletins sont publiés | décocher si vous n'avez pas de portal étudiant publiant les bulletins
|
||||
`bul_show_rangs` | Afficher le classement sur les bulletins |
|
||||
`bul_show_ue_rangs` | Afficher le classement dans chaque UE sur les bulletins |
|
||||
`bul_show_mod_rangs` | Afficher le classement dans chaque module sur les bulletins |
|
||||
`bul_show_moypromo` | Afficher moyennes de la promotion sur les bulletins |
|
||||
`bul_show_minmax` | Afficher min/max moyennes sur les bulletins |
|
||||
`bul_show_minmax_mod` | Afficher min/max moyennes des modules sur les bulletins |
|
||||
`bul_show_minmax_eval` | Afficher min/max moyennes des évaluations sur les bulletins |
|
||||
`bul_show_coef` | Afficher coefficient des ue/modules sur les bulletins |
|
||||
`bul_show_ue_cap_details` | Afficher détail des notes des UE capitalisées sur les bulletins |
|
||||
`bul_show_ue_cap_current` | Afficher les UE en cours mais capitalisées sur les bulletins |
|
||||
`bul_show_temporary_forced` | Bannière "provisoire" sur les bulletins |
|
||||
`bul_show_temporary` | Bannière "provisoire" si pas de décision de jury |
|
||||
`bul_temporary_txt` | Texte de la bannière "provisoire |
|
||||
`bul_show_uevalid` | Faire figurer les UE validées sur les bulletins |
|
||||
`bul_show_mention` | Faire figurer les mentions sur les bulletins et les PV |
|
||||
`bul_show_date_inscr` | Faire figurer la date d'inscription sur les bulletins |
|
||||
`bul_show_sig_left` | Faire figurer le pied de page de gauche (ex.: nom du directeur) sur les bulletins |
|
||||
`bul_show_sig_right` | Faire figurer le pied de page de droite (ex.: nom du chef de département) sur les bulletins |
|
||||
`bul_pdf_title` | Bulletins PDF: paragraphe de titre | (balises interprétées, voir documentation)
|
||||
`bul_pdf_caption` | Bulletins PDF: paragraphe sous table note | (visible seulement si "Faire figurer les décision" est coché)
|
||||
`bul_pdf_sig_left` | Bulletins PDF: signature gauche | (balises interprétées, voir documentation)
|
||||
@ -146,10 +148,10 @@ Nom | |
|
||||
|
||||
Nom | |
|
||||
---- | ---- | ----
|
||||
`left_margin` | Marge gauche |
|
||||
`top_margin` | Marge haute |
|
||||
`right_margin` | Marge droite |
|
||||
`bottom_margin` | Marge basse |
|
||||
`left_margin` | Marge gauche |
|
||||
`top_margin` | Marge haute |
|
||||
`right_margin` | Marge droite |
|
||||
`bottom_margin` | Marge basse |
|
||||
|
||||
## Envoi des bulletins par e-mail
|
||||
|
||||
@ -160,7 +162,7 @@ Nom | |
|
||||
`bul_intro_mail` | Message d'accompagnement | <tt>%(DeptName)s</tt> est remplacé par le nom du département, <tt>%(nomprenom)s</tt> par les noms et prénoms de l'étudiant, <tt>%(dept)s</tt> par le nom du département, et <tt>%(webmaster)s</tt> par l'adresse mail du Webmaster.
|
||||
`bul_mail_list_abs` | Indiquer la liste des dates d'absences par mail | dans le mail envoyant le bulletin de notes
|
||||
`bul_mail_contact_addr` | Adresse mail contact "webmaster" | apparait dans le mail accompagnant le bulletin, voir balise "webmaster" ci-dessus.
|
||||
`bul_mail_allowed_for_all` | Autoriser tous les utilisateurs à expédier des bulletins par mail |
|
||||
`bul_mail_allowed_for_all` | Autoriser tous les utilisateurs à expédier des bulletins par mail |
|
||||
|
||||
## Mise en forme des feuilles (Absences, Trombinoscopes, ...)
|
||||
|
||||
@ -168,13 +170,13 @@ Nom | |
|
||||
---- | ---- | ----
|
||||
`feuille_releve_abs_taille` | Taille feuille relevé absences | Dimensions du papier pour les feuilles de relevés d'absences hebdomadaire
|
||||
`feuille_releve_abs_format` | Format feuille relevé absences | Format du papier pour les feuilles de relevés d'absences hebdomadaire
|
||||
`feuille_releve_abs_samedi` | Samedi travaillé |
|
||||
`feuille_releve_abs_samedi` | Samedi travaillé |
|
||||
`feuille_releve_abs_AM` | Créneaux cours matin | Nombre de créneaux de cours le matin
|
||||
`feuille_releve_abs_PM` | Créneaux cours après-midi | Nombre de créneaux de cours l'après-midi
|
||||
`feuille_placement_emargement` | Feuille d'émargement des contrôles - Signature étudiant | Hauteur de l'espace pour signer
|
||||
`feuille_placement_positions` | Feuille des places lors des contrôles | Nombre maximum de lignes par colonne
|
||||
`prepa_jury_nip` | Code NIP sur la feuille préparation jury |
|
||||
`prepa_jury_ine` | Code INE sur la feuille préparation jury |
|
||||
`prepa_jury_nip` | Code NIP sur la feuille préparation jury |
|
||||
`prepa_jury_ine` | Code INE sur la feuille préparation jury |
|
||||
`anonymous_lst_code` | Code pour listes anonymes | à défaut, un code interne sera utilisé
|
||||
|
||||
## Avis de poursuites d'études
|
||||
@ -183,7 +185,7 @@ Nom | |
|
||||
---- | ---- | ----
|
||||
`NomResponsablePE` | Nom du responsable des poursuites d'études | pour les avis pdf de poursuite
|
||||
`pe_avis_latex_tmpl` | Template LaTeX des avis | préparez-le dans un éditeur de texte puis copier le contenu ici (en utf8). Sinon, le fichier un_avis.tex du serveur sera utilisé.
|
||||
`pe_avis_latex_footer` | Code LaTeX en fin d'avis |
|
||||
`pe_avis_latex_footer` | Code LaTeX en fin d'avis |
|
||||
`pe_tag_annotation_avis_latex` | Tag désignant l'avis PE | ajoutez une annotation aux étudiants précédée du tag désigné ici pour qu'elle soit interprétée comme un avis de poursuites d'études et ajoutée aux avis LaTeX.
|
||||
|
||||
## Connexion avec le logiciel d'emplois du temps
|
||||
|
@ -4,7 +4,7 @@ Voir les <a href="https://www.youtube.com/playlist?list=PLw49h6RbvswhasBk9bXj7Pz
|
||||
|
||||
## Page d'accueil
|
||||
|
||||
![accueil](screens/accueil-scodoc7.png)
|
||||
![accueil](screens/sco-accueil-dept.png)
|
||||
|
||||
On y trouve les éléments suivants:
|
||||
|
||||
@ -13,7 +13,7 @@ droite) et contient des liens facilitant la navigation sur le site (certains
|
||||
sont paramétrables à l'installation). On note l'accès à trois composants
|
||||
importants: Entreprises (fichier d'entreprises), Notes (gestion des notes),
|
||||
Absences (relevé des absences), et un champ de texte permettant de rechercher un
|
||||
étudiant par son nom.
|
||||
étudiant par son nom.
|
||||
|
||||
L'identité de l'utilisateur défini ses droits d'accès (rôle) et les fonctions
|
||||
qu'il peut utiliser.
|
||||
@ -22,7 +22,7 @@ Le centre de la page donne les formations (sessions) en cours, groupées par
|
||||
type. A côté du titre de chaque formation, on a le nom de son responsable (ou
|
||||
directeur des études dans le jargon IUT), ainsi que les dates de début et de fin
|
||||
de la session.
|
||||
|
||||
|
||||
## Fiche étudiant
|
||||
|
||||
Pour accéder à la fiche d'un étudiant, on peut soit le rechercher par nom (voir
|
||||
@ -35,8 +35,8 @@ informations sur l'étudiant. ![fiche étudiant](screens/ficheEtud-scodoc7.png)
|
||||
ScoDoc permet d'enregistrer les absences des étudiants puis de les visualiser
|
||||
sur un calendrier. On peut aussi obtenir des comptes d'absences, générer des
|
||||
alarmes par e-mail pour prévenir un responsable, vérifier les absences qui
|
||||
coincident avec un examen, enregistre les justificatifs, etc. ![calendrier des
|
||||
absences](screens/calabs-scodoc7.png)
|
||||
coïncident avec un examen, enregistre les justificatifs, etc. ![calendrier des
|
||||
absences](screens/sco-assi-cal.png)
|
||||
|
||||
## Gestion des notes
|
||||
|
||||
@ -47,10 +47,11 @@ web, vérifications, etc.).
|
||||
|
||||
### Tableau de bord du semestre, avec les modules
|
||||
|
||||
![tableau de bord du semestre](screens/tableaubord2011.png)
|
||||
![tableau de bord du semestre](screens/sco-formsemestre-status.png)
|
||||
|
||||
### Tableau récapitulatif des moyennes
|
||||
![tableau de bord du semestre](screens/NotesRecap2012-crop.png)
|
||||
|
||||
![tableau de bord du semestre](screens/sco-table-recap-but.png)
|
||||
|
||||
### Bulletins de notes
|
||||
|
||||
@ -74,8 +75,9 @@ respectent les règles.
|
||||
## Gestion des groupes
|
||||
|
||||
ScoDoc permet de définir des partitions et groupes en nombre quelconque, et d'y
|
||||
répartir facilement les étudiants (glisser/déposer, fonctions de répartition
|
||||
automatiques). ![affectation aux groupes](screens/GroupesDnD.png)
|
||||
répartir facilement les étudiants:
|
||||
|
||||
![sco-partition-edit.png](screens/sco-partition-edit.png)
|
||||
|
||||
## Trombinoscopes
|
||||
|
||||
@ -89,5 +91,12 @@ automatiques). ![affectation aux groupes](screens/GroupesDnD.png)
|
||||
Les données conservées dans le logiciel peuvent être exportées dans une grande
|
||||
variété de formats (pages web, PDF, Excel, XML...) ce qui facilite tant son
|
||||
usage par des non informaticiens que son intégration dans d'autres logiciels
|
||||
(portails d'établissements, systèmes d'informations comme Apogée).
|
||||
(portails d'établissements, systèmes d'informations comme Apogée).
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Les principaux objets de ScoDoc](IntroObjetsScoDoc.md)
|
||||
- [Guide utilisateur](GuideUtilisateur.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
@ -1,16 +1,23 @@
|
||||
# Saisie des décisions de jury
|
||||
|
||||
# Saisie des décisions de jury
|
||||
ScoDoc guide les travaux de la commission (et/ou du jury) en présentant le parcours et
|
||||
les résultats de chaque étudiant, et les différentes décisions possibles
|
||||
(voir explications dans [GestionJury](GestionJury.md)).
|
||||
ScoDoc guide les travaux de la commission (et/ou du jury) en présentant le
|
||||
parcours et les résultats de chaque étudiant, et les différentes décisions
|
||||
possibles (voir explications dans [GestionJury](GestionJury.md)).
|
||||
|
||||
Note: pour le BUT, une page spéciale est présentée.
|
||||
|
||||
## Saisie des décisions pour un étudiant
|
||||
On accède à cette page soit via la fiche étudiant (menu **Scolarité** du semestre à considérer),
|
||||
soit via la page **Saisie des décisions du jury** accessible depuis le tableau de bord du semestre.
|
||||
## Saisie des décisions pour un étudiant
|
||||
|
||||
On accède à cette page soit via la fiche étudiant (menu **Scolarité** du
|
||||
semestre à considérer), soit via la page **Saisie des décisions du jury**
|
||||
accessible depuis le tableau de bord du semestre.
|
||||
|
||||
![ValidationSemestre.png](screens/ValidationSemestre.png)
|
||||
|
||||
|
||||
(source de ce dessin: <a class="attachment" href="/attachments/ValidationSemestre.dia" download>ValidationSemestre.dia</a>)
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Guide responsable de formation](GuideAdminFormation.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
@ -86,7 +86,8 @@ comptes utilisateurs.
|
||||
# en tant que root...
|
||||
systemctl stop scodoc9 # arret du serveur
|
||||
su - scodoc
|
||||
dropdb SCODOC # <<< votre base production
|
||||
cd /opt/scodoc
|
||||
dropdb SCODOC # <<< votre base production
|
||||
createdb -E UTF-8 SCODOC
|
||||
pg_restore -d SCODOC /tmp/SCODOC_pgdump # (nom du fichier dump)
|
||||
source venv/bin/activate
|
||||
@ -111,7 +112,7 @@ script
|
||||
Ce script va générer une archive (`tar`, format `.tgz`) contenant non seulement
|
||||
la base de données SQL mais aussi tous les fichiers générés par votre ScoDoc:
|
||||
photos, configurations locales, archives, PV de jurys, logos, etc (tout ceci
|
||||
étant stocké sous `/opt/scodoc-data`).
|
||||
étant stocké sous `/opt/scodoc-data`).
|
||||
|
||||
Attention à l'espace disque: le répertoire destination (`/tmp`dans l'exemple
|
||||
ci-dessus) doit avoir de l'espace (sinon utilisez un autre répertoire dans
|
||||
|
3193
docs/ScoDoc9API.md
3193
docs/ScoDoc9API.md
File diff suppressed because it is too large
Load Diff
@ -59,10 +59,10 @@ Par ailleurs, chaque semestre est associé à une étape Apogée (VET), et, en
|
||||
option, à un code d'élément annuel et un code d'élément semestre. Pour le
|
||||
deuxième semestre 5S2) du DUT R&T Villetaneuse, cela donne:
|
||||
|
||||
* Code étape (VET): `V1RT` (l'étape est annuelle)
|
||||
* Code année (ELP): `VRT1A` (cet élément contiendra exactement les mêmes
|
||||
- Code étape (VET): `V1RT` (l'étape est annuelle)
|
||||
- Code année (ELP): `VRT1A` (cet élément contiendra exactement les mêmes
|
||||
informations que le VET)
|
||||
* Code semestre (ELP): `VRTW2` (la note de ces élément sera la moyenne générale
|
||||
- Code semestre (ELP): `VRTW2` (la note de ces élément sera la moyenne générale
|
||||
du semestre)
|
||||
|
||||
Notez que la nomenclature est variable et souvent peu prévisible, même au sein
|
||||
@ -97,20 +97,44 @@ Apogée.
|
||||
|
||||
### Précautions à prendre et remarques diverses
|
||||
|
||||
* Codage des fichiers: Apogée (du moins à l'Université Paris 13) exporte et
|
||||
- **Codage des fichiers**: Apogée (du moins à l'Université Paris 13) exporte et
|
||||
importe des fichiers maquettes codés en latin-1 (ISO-8859-1). Les web
|
||||
services (portail Apogée), tout comme ScoDoc, travaillent en utf8. Pour
|
||||
faciliter les échanges, les fichiers maquettes importés et exportés de ScoDoc
|
||||
sont en latin-1 (sauf celui reçu du portail Apogée).
|
||||
|
||||
* Etudiants démissionnaires: on note les démissions dans ScoDoc (sur la fiche
|
||||
- **Format des nombres** (notes): les notes sont calculées par ScoDoc en haute
|
||||
précision, mais affichées avec deux chiffres après la virgule dans
|
||||
l'application (ce qui donne 4 chiffres significatifs, par exemple *12,34*,
|
||||
soit une précision de un pour dix mille, ce qui semble plus que suffisant
|
||||
compte tenu de l'incertitude inhérente au processus de correction des
|
||||
évaluations par des enseignants humains).
|
||||
Les exports excel et API conservent la précision maximale.
|
||||
Les exports Apogée passant par des fichiers texte, une perte de précision est
|
||||
inévitable. Le format par défaut est là aussi deux chiffres après la virgule,
|
||||
mais peut-être modifié via la configuration globale de ScoDoc, accessible à
|
||||
l'administrateur uniquement. Voir *Configuration / Export Apogée /
|
||||
Configuration des codes de décision*, tout en bas de la page.
|
||||
|
||||
![Config. précision exports Apogée](screens/apo-precision.png)
|
||||
|
||||
- **Étudiants démissionnaires**: on note les démissions dans ScoDoc (sur la fiche
|
||||
de l'étudiant), mais en général pas dans Apogée. Le résultat Apogée sera DEF.
|
||||
Ne jamais désinscrire du semestre ScoDoc les démissionnaires !
|
||||
|
||||
* Exports à mi-année (après jurys de janvier): Si periode==1 (jury de janvier),
|
||||
- Exports à **mi-année** (après jurys de janvier): Si `periode==1` (jury de janvier),
|
||||
alors l'étape Apogée (annuelle) n'est pas terminée.
|
||||
Donc on ne remplit pas le code annuel (`elt_annee_apo`, comme `VRT1A`) ni le
|
||||
`VET` sauf si l'année est en fait validée grâce à un semestre de l'an
|
||||
précédent: (voir r1525)
|
||||
* jury de fin de S1: si le S2 est validé;
|
||||
* jury de fin de S3: si le S4 est validé.
|
||||
|
||||
- jury de fin de S1: si le S2 est validé;
|
||||
- jury de fin de S3: si le S4 est validé.
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Inscription des étudiants via Apogée](InscriptionsEtudApogee.md)
|
||||
- [Exports des résultats BUT vers Apogée](BUTApogee.md)
|
||||
- [Guide du responsable de formation](GuideAdminFormation.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
@ -1,28 +1,35 @@
|
||||
# Services XML pour l'export des données (obsolète)
|
||||
|
||||
# Services XML pour l'export des données
|
||||
ScoDoc offre un certain nombre de services XML pour faciliter son intégration dans
|
||||
!!! warning "Obsolète"
|
||||
|
||||
- Cette page est obsolète. Utiliser [l'API ScoDoc 9](ScoDoc9API.md)
|
||||
|
||||
ScoDoc offrait un certain nombre de services XML pour faciliter son intégration dans
|
||||
d'autres composants (typiquement un portail de services pour étudiant,
|
||||
comme le portail eSup CEVIF à l'IUT de Villetaneuse).
|
||||
|
||||
## Identification des étudiants
|
||||
|
||||
## Identification des étudiants
|
||||
les étudiants peuvent être identifiés au choix par l'un des trois codes:
|
||||
Les étudiants peuvent être identifiés au choix par l'un des trois codes:
|
||||
|
||||
- **`etudid`** : code interne ScoDoc, toujours disponible.
|
||||
* **`etudid`** : code interne ScoDoc, toujours disponible.
|
||||
|
||||
- **`code_ine`** : code INE Apogée, s'il a été renseigné
|
||||
* **`code_ine`** : code INE Apogée, s'il a été renseigné
|
||||
|
||||
- **`code_nip`** : code NIP Apogée, s'il a été renseigné
|
||||
* **`code_nip`** : code NIP Apogée, s'il a été renseigné
|
||||
|
||||
## Listes des principaux points d'entrée
|
||||
|
||||
## Listes des principaux points d'entrée
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> pour des raisons historiques, les noms des fonctions ne sont pas homogènes :-(
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
|
||||
alt="/!\" /> pour des raisons historiques, les noms des fonctions ne sont pas
|
||||
homogènes :-(
|
||||
|
||||
* **`XMLgetEtudInfos`**
|
||||
* Paramètre: etudid ou code_ine ou code_nip
|
||||
* Donne des informations sur l'étudiant et les semestres où il est (ou a été) inscrit.
|
||||
* Exemple:
|
||||
```
|
||||
* **`XMLgetEtudInfos`**
|
||||
* Paramètre: etudid ou code_ine ou code_nip
|
||||
* Donne des informations sur l'étudiant et les semestres où il est (ou a été) inscrit.
|
||||
* Exemple:
|
||||
|
||||
```xml
|
||||
<etudiant nom="DUPOND" prenom="FREDERIC" sexe="M." code_ine="250308450" nomprenom="M. Frederic MARSAUD" code_nip="105022504" etudid="ADCDEF" email="toto@xxx.com" photo_url="https://scodoc.example.com/Dept/Fotos/dcp_2777.h90.jpg">
|
||||
<insemestre etat="I" formsemestre_id="SEM4740" date_fin="2007-06-30" date_debut="2007-01-22" />
|
||||
<insemestre etat="I" formsemestre_id="SEM3608" date_fin="2007-01-31" date_debut="2006-09-01" />
|
||||
@ -30,11 +37,11 @@ les étudiants peuvent être identifiés au choix par l'un des trois codes:
|
||||
</etudiant>
|
||||
```
|
||||
|
||||
* **`XMLgetGroupsInPartition`**
|
||||
* Paramètres: `partition_id=X`
|
||||
* Donne la liste des étudiants dans un semestre, par groupes.
|
||||
* Exemple:
|
||||
```
|
||||
* **`XMLgetGroupsInPartition`**
|
||||
* Paramètres: `partition_id=X`
|
||||
* Donne la liste des étudiants dans un semestre, par groupes.
|
||||
* Exemple:
|
||||
```xml
|
||||
<ajax-response>
|
||||
<response type="object" id="MyUpdater">
|
||||
|
||||
@ -51,13 +58,13 @@ les étudiants peuvent être identifiés au choix par l'un des trois codes:
|
||||
</ajax-response>
|
||||
```
|
||||
|
||||
* **`XMLgetFormsemestres`**
|
||||
* Paramètres optionnels:
|
||||
* `formsemestre_id` code semestre ScoDoc
|
||||
* `etape_apo` code étape Apogée
|
||||
* Donne informations sur le ou les semestres sélectionnés (par défaut, sur tous les semestres).
|
||||
* Exemple:
|
||||
```
|
||||
* **`XMLgetFormsemestres`**
|
||||
* Paramètres optionnels:
|
||||
* `formsemestre_id` code semestre ScoDoc
|
||||
* `etape_apo` code étape Apogée
|
||||
* Donne informations sur le ou les semestres sélectionnés (par défaut, sur tous les semestres).
|
||||
* Exemple:
|
||||
```xml
|
||||
<formsemestrelist>
|
||||
<formsemestre
|
||||
formsemestre_id="SEM4741"
|
||||
@ -71,12 +78,12 @@ les étudiants peuvent être identifiés au choix par l'un des trois codes:
|
||||
</formsemestrelist>
|
||||
```
|
||||
|
||||
|
||||
* **`formation_export_xml`**
|
||||
* Paramètre: `formation_id`
|
||||
* Export XML du programme pédagogique complet (UE, matières, modules). Ce format XML est réimportable pour créer une nouvelle formation.
|
||||
* Exemple:
|
||||
```
|
||||
* **`formation_export_xml`**
|
||||
* Paramètre: `formation_id`
|
||||
* Export XML du programme pédagogique complet (UE, matières, modules). Ce
|
||||
format XML est réimportable pour créer une nouvelle formation.
|
||||
* Exemple:
|
||||
```xml
|
||||
<formation acronyme="DUT R&T" titre_officiel="DUT Réseaux et Télécommunications" formation_code="FCOD2" version="0" titre="DUT Réseaux et Télécommunications" formation_id="FORM1130">
|
||||
<ue acronyme="UE 1" ue_code="UCOD5" numero="1" ue_id="UE1131" titre="Formation Générale" formation_id="FORM1130" type="0">
|
||||
<matiere titre="Mathématiques" matiere_id="MAT1132" numero="10" ue_id="UE1131">
|
||||
@ -84,14 +91,14 @@ les étudiants peuvent être identifiés au choix par l'un des trois codes:
|
||||
titre="Fondamentaux d'algèbre et de trigonométrie" module_id="MOD1138" formation_id="FORM1130" heures_td="30.0"/>
|
||||
...
|
||||
...
|
||||
```
|
||||
```xml
|
||||
|
||||
* **`formsemestre_bulletinetud`**
|
||||
* Paramètres: `format=xml&formsemestre_id=XXX&etudid=YYYX`
|
||||
* Paramètre optionnel: xml_with_decisions (force l'envoi des décisions même si elles ne doivent pas être montrées aux étudiants)
|
||||
* Bulletin de notes de l'étudiant. Toutes les notes obtenues dans ce semestres et prises en compte pour le calcul des moyennes (intégralement saisies), et décisions du jury si elles sont affichées (voir réglage des options du semestre).
|
||||
* Exemple:
|
||||
```
|
||||
* **`formsemestre_bulletinetud`**
|
||||
* Paramètres: `format=xml&formsemestre_id=XXX&etudid=YYYX`
|
||||
* Paramètre optionnel: `xml_with_decisions` (force l'envoi des décisions même si elles ne doivent pas être montrées aux étudiants)
|
||||
* Bulletin de notes de l'étudiant. Toutes les notes obtenues dans ce semestres et prises en compte pour le calcul des moyennes (intégralement saisies), et décisions du jury si elles sont affichées (voir réglage des options du semestre).
|
||||
* Exemple:
|
||||
```xml
|
||||
<bulletinetud date="2007-07-11T18:50:48.164292" formsemestre_id="SEM4729" publie="1" etudid="10408738" etape_apo="V1TR">
|
||||
<etudiant nom="DUPONT" prenom="YACINE" sexe="M." code_ine="2222222" etudid="11111111" code_nip="1033333333" email="toto@hotmail.com" photo_url="https://www-gtr.iutv.univ-paris13.fr/Dept/Fotos/dcp_n_01919.h90.jpg"/>
|
||||
<note value="12.92"/>
|
||||
@ -112,25 +119,29 @@ les étudiants peuvent être identifiés au choix par l'un des trois codes:
|
||||
```
|
||||
|
||||
Si les décisions du jury sont publiées, on a un élément:
|
||||
```
|
||||
```xml
|
||||
<decision etat="I" code="ADM"/>
|
||||
```
|
||||
et le cas échéant dans la décision une autorisation d'inscription (passage à un autre semestre) sous la forme:
|
||||
```
|
||||
et le cas échéant dans la décision une autorisation d'inscription (passage à un
|
||||
autre semestre) sous la forme:
|
||||
```xml
|
||||
<autorisation_inscription semestre_id="3"/>
|
||||
```
|
||||
|
||||
Le bulletin comporte aussi le décompte des absences enregistrées au cours de ce semestre (comptées en nombre de demi-journées):
|
||||
```
|
||||
Le bulletin comporte aussi le décompte des absences enregistrées au cours de ce
|
||||
semestre (comptées en nombre de demi-journées):
|
||||
```xml
|
||||
<absences nbabsjust="0" nbabs="2"/>
|
||||
```
|
||||
|
||||
* **`formsemestre_recapcomplet`**
|
||||
* Paramètres: `formsemestre_id=XXXX&tabformat=xml`
|
||||
* Paramètre optionnel: xml_with_decisions (force l'envoi des décisions même si elles ne doivent pas être montrées aux étudiants)
|
||||
* L'ensemble des bulletins de toutes la promotion d'étudiants (au même format que `formsemestre_bulletinetud`).
|
||||
* Exemple:
|
||||
```
|
||||
* **`formsemestre_recapcomplet`**
|
||||
* Paramètres: `formsemestre_id=XXXX&tabformat=xml`
|
||||
* Paramètre optionnel: xml_with_decisions (force l'envoi des décisions même
|
||||
si elles ne doivent pas être montrées aux étudiants)
|
||||
* L'ensemble des bulletins de toutes la promotion d'étudiants (au même
|
||||
format que `formsemestre_bulletinetud`).
|
||||
* Exemple:
|
||||
```xml
|
||||
<recapsemestre date="2007-07-11T19:00:12.370531" formsemestre_id="SEM4729">
|
||||
<evals_info date_derniere_note="2007-07-02 14:04:11.00" nb_evals_vides="0" nb_evals_en_cours="0" nb_evals_completes="28"/>
|
||||
<bulletinetud ...>
|
||||
@ -141,26 +152,33 @@ Le bulletin comporte aussi le décompte des absences enregistrées au cours de c
|
||||
```
|
||||
|
||||
|
||||
## Absences
|
||||
* **`XMLgetAbsEtud`**
|
||||
* Paramètres: etudid ou code_ine ou code_nip, beg_date, end_date (au format ISO 2009-11-04)
|
||||
* La liste des absences entre les dates indiquées (inclues):
|
||||
```
|
||||
## Absences
|
||||
|
||||
* **`XMLgetAbsEtud`**
|
||||
* Paramètres: etudid ou code_ine ou code_nip, beg_date, end_date (au format
|
||||
ISO 2009-11-04)
|
||||
* La liste des absences entre les dates indiquées (inclues):
|
||||
|
||||
```xml
|
||||
<absences beg_date="2009-11-03" end_date="2009-11-29" etudid="EID1911">
|
||||
<abs begin="2009-11-04 08:00:00" end="2009-11-04 11:59:59" justified="1" description="malade"/>
|
||||
<abs begin="2009-11-04 12:00:00" end="2009-11-04 17:59:59" justified="0" description=""/>
|
||||
</absences>
|
||||
```
|
||||
|
||||
* Les billets d'absences sont entrés via l'appel **`AddBilletAbsence`**:
|
||||
* Paramètres: etudid ou code_ine ou code_nip, begin, end, description
|
||||
* Résultat: XML contenant l'ID du billet créé.
|
||||
* Les billets d'absences sont entrés via l'appel **`AddBilletAbsence`**:
|
||||
* Paramètres: etudid ou code_ine ou code_nip, begin, end, description
|
||||
* Résultat: XML contenant l'ID du billet créé.
|
||||
|
||||
* **`XMLgetBilletsEtud`**
|
||||
* Paramètre: etudid ou code_ine ou code_nip
|
||||
* Les "billets" d'absence reçus pour cet étudiant (`etat` vaut 0 si le billet n'a pas été traité, 1 sinon, et `description` est la raison déclarée de l'absence).
|
||||
* Exemple (1 row par billet):
|
||||
```
|
||||
* **`XMLgetBilletsEtud`**
|
||||
|
||||
* Paramètre: etudid ou code_ine ou code_nip
|
||||
* Les "billets" d'absence reçus pour cet étudiant (`etat` vaut 0 si le billet
|
||||
n'a pas été traité, 1 sinon, et `description` est la raison déclarée de
|
||||
l'absence).
|
||||
* Exemple (1 row par billet):
|
||||
|
||||
```xml
|
||||
<table origin="" caption="" id="gt_920276">
|
||||
<row>
|
||||
<billet_id value="ABS-3"/>
|
||||
@ -171,4 +189,3 @@ Le bulletin comporte aussi le décompte des absences enregistrées au cours de c
|
||||
</row>
|
||||
</table>
|
||||
```
|
||||
|
||||
|
@ -1,27 +1,48 @@
|
||||
La page **Synchroniser avec étape Apogée** est accessible depuis le tableau de bord du semestre (via le menu **Inscriptions**). Elle permet de vérifier et modifier les inscriptions au semestre en utilisant l'étape Apogée (les inscriptions dans Apogée sont normalement gérées par le service de la Scolarité, cette opération ne concerne donc que les étudiants régulièrement inscrits).
|
||||
# Synchronisation avec Apogée
|
||||
|
||||
La page **Synchroniser avec étape Apogée** est accessible depuis le tableau de
|
||||
bord du semestre (via le menu **Inscriptions**). Elle permet de vérifier et
|
||||
modifier les inscriptions au semestre en utilisant l'étape Apogée (les
|
||||
inscriptions dans Apogée sont normalement gérées par le service de la Scolarité,
|
||||
cette opération ne concerne donc que les étudiants régulièrement inscrits).
|
||||
|
||||
![MenuSynchroEtape.png](screens/MenuSynchroEtape.png).
|
||||
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> Cette opération ne fonctionnera que si vous avez correctement renseigné le code étape du semestre (menu **Modifier le semestre**).
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
|
||||
alt="/!\" /> Cette opération ne fonctionnera que si vous avez correctement
|
||||
renseigné le code étape du semestre (menu **Modifier le semestre**).
|
||||
|
||||
ScoDoc peut rencontrer quatre cas de figure pour chaque étudiant:
|
||||
|
||||
1- étudiant présent dans Apogée et inscrit dans le semestre ScoDoc (*tout va bien*)
|
||||
1- étudiant présent dans Apogée et inscrit dans le semestre ScoDoc (*tout va
|
||||
bien*)
|
||||
|
||||
2- étudiant dans Apogée, dans ScoDoc, mais pas inscrit dans le semestre (*non incrit, on devrait l'inscrire*)
|
||||
2- étudiant dans Apogée, dans ScoDoc, mais pas inscrit dans le semestre (*non
|
||||
inscrit, on devrait l'inscrire*)
|
||||
|
||||
3- étudiant dans Apogée et pas dans ScoDoc (*on devrait l'importer et l'inscrire*)
|
||||
3- étudiant dans Apogée et pas dans ScoDoc (*on devrait l'importer et
|
||||
l'inscrire*)
|
||||
|
||||
4- étudiant inscrit dans le semestre ScoDoc, mais pas trouvé dans Apogée (sur la base du code NIP) (*peut être pas encore inscrit, ou bien une erreur de saisie ?*)
|
||||
4- étudiant inscrit dans le semestre ScoDoc, mais pas trouvé dans Apogée (sur la
|
||||
base du code NIP) (*peut être pas encore inscrit, ou bien une erreur de saisie
|
||||
?*)
|
||||
|
||||
Ces quatre cas sont présentés dans des cadres différents.
|
||||
Ces quatre cas sont présentés dans des cadres différents.
|
||||
|
||||
Le bouton **Importer et Inscrire** permet de traiter les étudiants du cas 3 (cas rencontré normalement en début de semestre).
|
||||
Le bouton **Importer et Inscrire** permet de traiter les étudiants du cas 3 (cas
|
||||
rencontré normalement en début de semestre).
|
||||
|
||||
Le lien **inscrire ces étudiants**, en bas du cadre **Etudiants non inscrits dans ce semestre**, permet d'inscrire les étudiants dans le cas 2.
|
||||
Le lien **inscrire ces étudiants**, en bas du cadre **Etudiants non inscrits
|
||||
dans ce semestre**, permet d'inscrire les étudiants dans le cas 2.
|
||||
|
||||
S'il reste, quelques semaines après la rentrée, des étudiants dans le cas 4 et que le code étape du semestre est correct, contactez votre service Scolarité pour élucider la situation.
|
||||
S'il reste, quelques semaines après la rentrée, des étudiants dans le cas 4 et
|
||||
que le code étape du semestre est correct, contactez votre service Scolarité
|
||||
pour élucider la situation.
|
||||
|
||||
|
||||
Voir aussi [Vérifier les codes NIP](VerifCodeNIP), [ Guide pour le chef de département](GuideAdminFormation).
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Vérifier les codes NIP](VerifCodeNIP.md)
|
||||
- [Guide pour le ou la responsable de formation](GuideAdminFormation.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
@ -5,27 +5,54 @@ ScoDoc est basé sur Flask, se référer à la doc de Flask pour aller plus loin
|
||||
|
||||
On travaille toujours en tant qu'utilisateur `scodoc`, dans le *virtualenv*:
|
||||
|
||||
su scodoc # si nécessaire
|
||||
cd /opt/scodoc
|
||||
source venv/bin/activate
|
||||
```bash
|
||||
su scodoc # si nécessaire
|
||||
cd /opt/scodoc
|
||||
source venv/bin/activate
|
||||
```
|
||||
|
||||
## Lancement interactif
|
||||
|
||||
flask shell
|
||||
```bash
|
||||
flask shell
|
||||
```
|
||||
|
||||
Pour mémoire, un certains nombre de commandes en ligne facilitant la gestion de
|
||||
Pour mémoire, un certains nombre de commandes en ligne facilitant la gestion de
|
||||
ScoDoc sont disponibles, afficher la liste avec
|
||||
|
||||
flask --help
|
||||
```bash
|
||||
flask --help
|
||||
```
|
||||
|
||||
## Tests unitaires
|
||||
|
||||
On utilise `pytest`. Ainsi, la commande
|
||||
|
||||
pytest tests/unit
|
||||
```bash
|
||||
pytest tests/unit
|
||||
```
|
||||
|
||||
lance l'ensemble des tests unitaires.
|
||||
|
||||
Ces tests sont lancés automatiquement avant la création du paquet Debian
|
||||
(release).
|
||||
|
||||
Rappelons quelques options utiles de `pytest`: `-x` permet de s'arrêter sur la
|
||||
première erreur, et `--pdb` lance directement le debugger sur l'erreur.
|
||||
Ainsi,
|
||||
|
||||
```bash
|
||||
pytest --pdb -x tests/api/test_api_departements.py
|
||||
```
|
||||
|
||||
lancera un test en mode "interactif", utile pour les mises au point.
|
||||
|
||||
Et pour lancer un seul test:
|
||||
|
||||
```bash
|
||||
pytest -x --pdb tests/unit/test_but_cursus.py::test_refcomp_niveaux_info
|
||||
```
|
||||
|
||||
### Création de la base de données pour les tests unitaires
|
||||
|
||||
```bash
|
||||
@ -44,11 +71,15 @@ Un faux portail "apogée" pour inscrire de faux étudiants avec photos. Utile po
|
||||
|
||||
Le code se trouve dans `tools/fakeportal/`.
|
||||
|
||||
Le serveur écoute par défaut sur `tcp/8678`. Il faudra paramétrer l'URL du "portail" dans les préférences du ScoDoc à tester, qui est en général sur le même hôte, donc `http://localhost:8678`.
|
||||
Le serveur écoute par défaut sur `tcp/8678`. Il faudra paramétrer l'URL du
|
||||
"portail" dans les préférences du ScoDoc à tester, qui est en général sur le
|
||||
même hôte, donc `http://localhost:8678`.
|
||||
|
||||
Lancement:
|
||||
|
||||
/opt/scodoc/tools/fakeportal/fakeportal.py
|
||||
```bash
|
||||
/opt/scodoc/tools/fakeportal/fakeportal.py
|
||||
```
|
||||
|
||||
## Tests de l'API ScoDoc9
|
||||
|
||||
@ -60,7 +91,7 @@ serveur doit avoir été configuré avec des données de test.
|
||||
|
||||
### TL;DR
|
||||
|
||||
Si votre install de développement est bien configurée, il suffit de lancer
|
||||
Si votre installation de développement est bien configurée, il suffit de lancer
|
||||
|
||||
```bash
|
||||
tools/test_api.sh
|
||||
@ -68,12 +99,13 @@ tools/test_api.sh
|
||||
|
||||
### Configuration du serveur pour tester l'API
|
||||
|
||||
1. modifier `/opt/scodoc/.env` pour indiquer
|
||||
1. modifier `/opt/scodoc/.env` pour indiquer
|
||||
```bash
|
||||
FLASK_ENV=test_api
|
||||
FLASK_DEBUG=1
|
||||
```
|
||||
1. En tant qu'utilisateur scodoc, lancer:
|
||||
|
||||
1. En tant qu'utilisateur scodoc, lancer:
|
||||
```bash
|
||||
tools/create_database.sh --drop SCODOC_TEST_API
|
||||
flask db upgrade
|
||||
@ -83,11 +115,14 @@ tools/test_api.sh
|
||||
Ces commandes vont effacer la base `SCODOC_TEST_API` si elle existe, la
|
||||
recréer, mettre à jour le schéma pour la dernière version de ScoDoc installée,
|
||||
l'initialiser et la peupler de données fictives pour les tests.
|
||||
3. Relancer ScoDoc:
|
||||
|
||||
1. Relancer ScoDoc:
|
||||
```bash
|
||||
flask run --host 0.0.0.0
|
||||
flask run --host 0.0.0.0 --debug
|
||||
```
|
||||
|
||||
Le script `tests/api/start_api_server.sh -p 5555` fait tout cela pour vous !
|
||||
|
||||
### Configuration du client de test API
|
||||
|
||||
1. Copier le fichier `scodoc/tests/api/dotenv_exemple` dans
|
||||
@ -96,9 +131,10 @@ l'initialiser et la peupler de données fictives pour les tests.
|
||||
votre serveur).
|
||||
Normalement, il est suffisant d'indiquer l'URL de votre serveur. Si le
|
||||
client de test est sur la même machine que le serveur ScoDoc, c'est simplement:
|
||||
```bash
|
||||
SCODOC_URL="http://localhost:5000/"
|
||||
```
|
||||
|
||||
```bash
|
||||
SCODOC_URL="http://localhost:5000/"
|
||||
```
|
||||
|
||||
### Lancement des tests de l'API
|
||||
|
||||
@ -109,11 +145,3 @@ le client (qui peut être un autre shell de la même machine, bien sûr).
|
||||
cd /opt/scodoc/
|
||||
pytest tests/api/test_api_xxx.py # remplacer xxx par votre test
|
||||
```
|
||||
|
||||
Rappelons quelques options utiles de `pytest`: `-x` permet de s'arrêter sur la
|
||||
première erreur, et `--pdb` lance directement le débuggueur sur l'erreur.
|
||||
Ainsi,
|
||||
```bash
|
||||
pytest --pdb -x tests/api/test_api_departements.py
|
||||
```
|
||||
lancera un test en mode "interactif", utile pour les mises au point.
|
||||
|
@ -1,71 +1,148 @@
|
||||
# Récapitulatif des opérations en fin de semestre (et début du suivant)
|
||||
|
||||
Cette page récapitule les opérations typiquement effectuées par un chef de département en IUT à la fin d'un semestre. Selon les cas, certaines opérations peuvent être effectuées par les directeurs des études. La plupart des étapes mentionnées ici sont aussi applicables pour d'autres types de formation.
|
||||
Cette page récapitule les opérations typiquement effectuées par le ou la
|
||||
responsable de formation (par ex. une cheffe de département en IUT) à la fin
|
||||
d'un semestre. Selon les cas, certaines opérations peuvent être effectuées par
|
||||
les directeurs des études.
|
||||
|
||||
Voir aussi le [Guide pour la cheffe ou le chef de département](GuideAdminFormation.md).
|
||||
|
||||
## À la fin d'un semestre
|
||||
|
||||
1. Vérifier que les réglages de votre semestre correspondent bien à ce que vous voulez. En particulier, les options comme *proposer compensation* et *jurys avec semestres décalés* (accessibles via *Modifier le semestre*, voir figure).
|
||||
![reglages-semestres-check.png](screens/reglages-semestres-check.png)
|
||||
1. Vérifier que les réglages de votre semestre correspondent bien à ce que vous
|
||||
voulez. En particulier, surtout pour les DUT, les options comme *proposer
|
||||
compensation* et *jurys avec semestres décalés* (accessibles via *Modifier
|
||||
le semestre*, voir figure).
|
||||
![reglages-semestres-check.png](screens/reglages-semestres-check.png)
|
||||
|
||||
2. Vérifier que le parcours choisi est correct (menu *Semestre* / *Voir la formation*): ainsi, le parcours affiché doit être "DUT selon l'arrêté d'août 2005" pour le DUT.
|
||||
2. Vérifier que la formation (menu **Semestre / Voir la formation**) est
|
||||
correcte et, s'il y a des messages d'avertissement dans la formation ou sur
|
||||
le tableau de bord du semestre, que vous les avez pris en compte ou
|
||||
comprenez la situation.
|
||||
|
||||
3. Vérifier que toutes les notes ont été saisies: regarder le tableau de bord, qui affiche dans chaque module les évaluations et indique si des notes manquent ou sont en attente.
|
||||
3. Vérifier que toutes les notes ont été saisies: regarder le tableau de bord,
|
||||
qui affiche dans chaque module les évaluations et indique si des notes
|
||||
manquent ou sont en attente. Le tenue d'un jury exige que toutes les notes
|
||||
sont à jour.
|
||||
|
||||
4. (optionnel) Vérifier les absences si cela n'a pas déjà été fait. Dans le menu *Semestre* du tableau de bord, suivre *Vérifier les absences aux évaluations*.
|
||||
Attention, actuellement ScoDoc enregistre les absences par demi-journées, ce qui fait qu'un étudiant peut être noté absent alors qu'il a assisté à un examen sur une partie de la demi-journée et sèché le cours suivant.
|
||||
4. (optionnel) En BUT, sur un semestre impair (S1, S3, S5), si les étudiants ont
|
||||
déjà commencé le semestre suivant (par exemple si le S2 a commencé avant que
|
||||
le jury de S1 ait été enregistré), prendre soin de bloquer la prise en compte
|
||||
des moyennes du semestre pair: sur celui là, via **Semestre / Modifier le
|
||||
semestre**, cocher *empêcher le calcul des moyennes d'UE*. Sinon, les
|
||||
décisions annuelles BUT seraient calculées !
|
||||
|
||||
5. Réunir la commission (ou le jury):
|
||||
5. (optionnel) Vérifier les absences si cela n'a pas déjà été fait. Dans le
|
||||
menu *Semestre* du tableau de bord, suivre *Vérifier les absences aux
|
||||
évaluations*.
|
||||
|
||||
a. Il peut être utile de préparer des documents pour les membres de la commission: suivre *Générer feuille préparation Jury* dans le menu *Jury*.
|
||||
6. Réunir la commission (ou le jury):
|
||||
|
||||
b. Durant la commission, nous recommandons de saisir en temps réel les décisions (menu *Jury / Saisie des décisions*). **Pour éviter que les étudiants n'aient accès aux décisions pendant le jury, décocher l'option *publier le bulletin sur le portail* ** (menu *Semestre / Options du semestre*).
|
||||
a. Il peut être utile de préparer des documents pour les membres de la
|
||||
commission: suivre *Générer feuille préparation Jury* dans le menu *Jury*.
|
||||
|
||||
6. Édition du procès-verbal: menu *Jury / Voir les décisions du jury*.
|
||||
b. Durant la commission, nous recommandons de saisir en temps réel les
|
||||
décisions (menu *Jury / Saisie des décisions*). **Pour éviter que les
|
||||
étudiants n'aient accès aux décisions pendant le jury, décocher l'option
|
||||
*publier le bulletin sur la passerelle* ** (menu *Semestre / Options du
|
||||
semestre*).
|
||||
|
||||
1. En bas de la page, un lien *Courriers individuels (classeur pdf)* permet de générer les courriers à adresser aux étudiants (penser à vérifier leurs adresses postales au préalable sur leurs fiches).
|
||||
7. Édition du procès-verbal: menu *Jury / Voir les décisions du jury*.
|
||||
|
||||
2. Le lien *PV officiel (pdf)* permet de générer le procès verbal avec la liste des décisions pour chaque étudiant.
|
||||
a. En bas de la page, un lien *Courriers individuels (classeur pdf)* permet
|
||||
de générer les courriers à adresser aux étudiants (penser à vérifier
|
||||
leurs adresses postales au préalable sur leurs fiches).
|
||||
|
||||
A ce stade, le semestre est terminé. Il est recommandé de le **verrouiller** après les prises de décisions définitives.
|
||||
b. Le lien *PV officiel (pdf)* permet de générer le procès verbal avec la
|
||||
liste des décisions pour chaque étudiant.
|
||||
|
||||
A ce stade, le semestre est terminé. Il est recommandé de le **verrouiller**
|
||||
après les prises de décisions définitives.
|
||||
|
||||
## Mise en place du semestre suivant
|
||||
|
||||
1. **Créer une instance du semestre suivant** (par exemple un S2 après un S1). Pour cela, aller sur la page *Programmes*, choisir la formation (rappelons que ScoDoc appelle "formation" la définition d'un programme pédagogique) et suivre le lien *UE, modules, semestres*.
|
||||
1. **Créer une instance du semestre suivant** (par exemple un S2 après un S1).
|
||||
Pour cela, aller sur la page *Programmes*, choisir la formation (rappelons
|
||||
que ScoDoc appelle "formation" la définition d'un programme pédagogique) et
|
||||
suivre le lien *UE, modules, semestres*.
|
||||
|
||||
2. En bas de la page qui détaille le programme, suivre le lien *Mettre en place un nouveau semestre de formation* et remplissez le formulaire.
|
||||
|
||||
Une autre approche, souvent plus rapide, consiste à créer un semestre en utilisant un semestre existant comme modèle: on reprend la même liste de modules; pour cela, se placer sur le semestre modèle, et utiliser le menu ** *Cloner ce semestre* **.
|
||||
2. En bas de la page qui détaille le programme, suivre le lien *Mettre en place
|
||||
un nouveau semestre de formation* et remplissez le formulaire.
|
||||
|
||||
1. Indiquez les dates correctes de début et de fin du semestre (attention: il est important que les dates ne se chevauchent pas: le nouveau semestre doit commencer quelques jours (ou semaines) après le précédent !)
|
||||
Une autre approche, souvent plus rapide, consiste à créer un semestre en
|
||||
utilisant un semestre existant comme modèle: on reprend la même liste de
|
||||
modules; pour cela, se placer sur le semestre modèle, et utiliser le menu **
|
||||
*Cloner ce semestre* **.
|
||||
|
||||
1. Indiquez les dates correctes de début et de fin du semestre (attention:
|
||||
il est important que les dates ne se chevauchent pas: le nouveau semestre
|
||||
doit commencer quelques jours (ou semaines) après le précédent !)
|
||||
|
||||
2. Désignez le responsable (directeur des études en DUT).
|
||||
|
||||
3. Si vous êtes interfacé à Apogée (via un portail), indiquez le code étape Apogée correspondant à votre nouveau semestre.
|
||||
|
||||
4. Cocher les modules de votre semestre, et associez leur un enseignant responsable (ce dernier pourra créer des évaluations dans ce module et déclarer des collègues pouvant saisir les notes).
|
||||
|
||||
|
||||
3. Si vous êtes interfacé à Apogée (via un portail), indiquez le code étape
|
||||
Apogée correspondant à votre nouveau semestre.
|
||||
|
||||
4. Cocher les modules de votre semestre, et associez leur un enseignant
|
||||
responsable (ce dernier pourra créer des évaluations dans ce module et
|
||||
déclarer des collègues pouvant saisir les notes).
|
||||
|
||||
5. Après relecture, cliquez sur le bouton *Créer ce semestre de formation*.
|
||||
|
||||
NB: toutes ces informations pourront être ultérieurement modifiées via le lien *Semestre / Modifer le semestre* du tableau de bord.
|
||||
|
||||
3. **Inscrire les étudiants** Sauf pour le premier semestre (S1), il est en général plus simple de s'appuyer sur les décisions de jury pour sélectionner rapidement les étudiants à inscrire. C'est ce que permet la page *Inscriptions / Passage des étudiants depuis d'autres semestres*. Voir les explications sur cette page.
|
||||
3. **Inscrire les étudiants** Sauf pour le premier semestre (S1), il est en
|
||||
général plus simple de s'appuyer sur les décisions de jury pour sélectionner
|
||||
rapidement les étudiants à inscrire. C'est ce que permet la page
|
||||
*Inscriptions / Passage des étudiants depuis d'autres semestres*. Voir les
|
||||
explications sur cette page.
|
||||
|
||||
4. Si vous avez un portail **Apogée** et que les inscriptions Apogée ont été effectuées (ou les changements de codes étapes), utiliser *Inscriptions / Synchroniser avec étape Apogée* pour vérifier et compléter la liste des inscrits. (Pour plus d'informations consulter aussi les pages [Vérifier les codes NIP](VerifCodeNIP.md) et [Synchroniser avec une étape Apogée](SynchroApogee.md).)
|
||||
4. Si vous avez un portail **Apogée** et que les inscriptions Apogée ont été
|
||||
effectuées (ou les changements de codes étapes), utiliser *Inscriptions /
|
||||
Synchroniser avec étape Apogée* pour vérifier et compléter la liste des
|
||||
inscrits. (Pour plus d'informations consulter aussi les pages [Vérifier les
|
||||
codes NIP](VerifCodeNIP.md) et [Synchroniser avec une étape
|
||||
Apogée](SynchroApogee.md).)
|
||||
|
||||
5. Si vous n'avez pas Apogée, qu'il s'agit du premier semestre, que vous n'utilisez pas non plus d'imports par fichiers Excel, et qu'il manque des étudiants (inscrits d'autres origines, cas particulier), il faut les créer individuellement (via le lien *créer un nouvel étudiant* en bas de la page d'accueil) puis les inscrire (via le menu *Inscriptions / Inscrire un étudiant* du tableau de bord semestre. **Avant cela, vérifiez bien que l'étudiant n'existe pas déjà dans ScoDoc afin de ne pas créer de doublons**.
|
||||
5. Si vous n'avez pas Apogée, qu'il s'agit du premier semestre, que vous
|
||||
n'utilisez pas non plus d'imports par fichiers Excel, et qu'il manque des
|
||||
étudiants (inscrits d'autres origines, cas particulier), il faut les créer
|
||||
individuellement (via le lien *créer un nouvel étudiant* en bas de la page
|
||||
d'accueil) puis les inscrire (via le menu *Inscriptions / Inscrire un
|
||||
étudiant* du tableau de bord semestre. **Avant cela, vérifiez bien que
|
||||
l'étudiant n'existe pas déjà dans ScoDoc afin de ne pas créer de doublons**.
|
||||
|
||||
6. (optionnel) Répartir les étudiants dans des groupes de TD (*Inscriptions / Modifier les groupes*).
|
||||
6. (optionnel) Répartir les étudiants dans des groupes de TD (*Inscriptions /
|
||||
Modifier les groupes*).
|
||||
|
||||
C'est prêt. Les enseignants autorisés peuvent créer des évaluations et saisir des notes.
|
||||
|
||||
## Problèmes couramment rencontrés
|
||||
|
||||
- **Etudiants en doubles**: ceci arrive lorsqu'on crée manuellement les étudiants. Il faut absolument éviter de créer un étudiant qui existe déjà, sinon on perd la possibilité de suivre le parcours de chacun. Le respect de la procédure ci-dessus garanti normalement que les étudiants restent uniques. N'utiliser *créer un nouvel étudiant* qu'après vous être assuré qu'il n'était pas déjà inscrit dans un autre semestre, et que l'on sait que l'on ne va pas l'importer depuis Apogée.
|
||||
- **Etudiants en double**: ceci arrive lorsqu'on crée manuellement les
|
||||
étudiants. Il faut absolument éviter de créer un étudiant qui existe déjà,
|
||||
sinon on perd la possibilité de suivre le parcours de chacun. Le respect de la
|
||||
procédure ci-dessus garanti que les étudiants restent uniques.
|
||||
N'utiliser *créer un nouvel étudiant* qu'après vous être assuré qu'il n'était
|
||||
pas déjà inscrit dans un autre semestre, et que l'on sait que l'on ne va pas
|
||||
l'importer depuis Apogée.
|
||||
|
||||
- **Désinscription d'un étudiant**: si vous avez inscrit par erreur un étudiant dans un semestre, ce n'est pas grave: vous pouvez le désinscrire en utilisant le menu *Scolarité / désinscrire* sur sa fiche individuelle (à droite du nom du semestre concerné).
|
||||
- **Désinscription d'un étudiant**: si vous avez inscrit par erreur un étudiant
|
||||
dans un semestre, ce n'est pas grave: vous pouvez le désinscrire en utilisant
|
||||
le menu *Scolarité / désinscrire* sur sa fiche individuelle (à droite du nom
|
||||
du semestre concerné).
|
||||
|
||||
- **Aucun étudiant à inscrire**: cela peut arriver si les dates de semestres sont incorrectes (chevauchement): en particulier, vérifier que la date de début du nouveau semestre est bien postérieure à la date de fin des semestres d'où proviennent les étudiants à inscrire.
|
||||
- **Aucun étudiant à inscrire**: cela peut arriver si les dates de semestres
|
||||
sont incorrectes (chevauchement): en particulier, vérifier que la date de
|
||||
début du nouveau semestre est bien postérieure à la date de fin des semestres
|
||||
d'où proviennent les étudiants à inscrire.
|
||||
|
||||
Pour toutes questions, n'hésitez pas à nous contacter (voir la [contacts](Contact.md)).
|
||||
Pour toute question, n'hésitez pas à nous contacter ([contacts](Contact.md)).
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Vérifier les codes NIP](VerifCodeNIP.md)
|
||||
- [Guide pour le ou la responsable de formation](GuideAdminFormation.md)
|
||||
- [Les jurys de BUT](BUTJurys.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
226
docs/UpgradeToDeb12Sco96.md
Normal file
226
docs/UpgradeToDeb12Sco96.md
Normal file
@ -0,0 +1,226 @@
|
||||
# Procédure pour la mise à jour vers Debian 12 et ScoDoc 9.6
|
||||
|
||||
Cette page documente la mise à jour d'un serveur ScoDoc 9.4 ou 9.5 tournant sous
|
||||
Linux Debian 11 vers la version suivante: ScoDoc 9.6 sous Debian 12.
|
||||
|
||||
On commence par mettre à jour normalement le système Debian, puis on change la
|
||||
version de la base de données postgresql puis on met à jour ScoDoc.
|
||||
|
||||
Si vous souhaitez installer ScoDoc 9.6 sans partir d'un serveur 9.5,
|
||||
[voir la page d'installation](GuideInstallDebian12.md)
|
||||
|
||||
Tout compris, la mise à jour d'un serveur typique prend environ 20 à 30 minutes
|
||||
et ne demande aucune compétence particulière, autre que de suivre
|
||||
scrupuleusement les instructions ci-dessous, sans oublier d'étape.
|
||||
|
||||
## Upgrade Debian 11 vers Debian 12
|
||||
|
||||
La documentation officielle est là:
|
||||
[DebianUpgrade](https://wiki.debian.org/DebianUpgrade). Elle couvre tous les
|
||||
cas, mais en général notre serveur ScoDoc est plus simple: résumé ci-dessous
|
||||
|
||||
### Sauvegarder
|
||||
|
||||
Avant tout, sauvegarder vos données et l'ensemble de votre serveur. Vérifiez que
|
||||
vous avez assez d'espace disque disponible (par exemple avec la commande `df -h`).
|
||||
|
||||
Prévenez les utilisateurs et arrêtez le service: `systemctl stop scodoc9`
|
||||
|
||||
### Mettre à jour Debian
|
||||
|
||||
Dans la suite, on suppose que vous avez un shell root. Sinon, utilisez `sudo`.
|
||||
|
||||
#### Vérifier qu'on est à jour
|
||||
|
||||
```bash
|
||||
apt-get update
|
||||
apt-get upgrade
|
||||
apt-get full-upgrade
|
||||
```
|
||||
|
||||
#### Modifier les sources de mise à jour
|
||||
|
||||
Si vous savez le faire, éditer le fichier `/etc/apt/sources.list` (par exemple
|
||||
avec la commande `nano /etc/apt/sources.list`) et remplacer le mot `bullseye`par
|
||||
`bookworm`. Vous pouvez aussi utiliser `sed`
|
||||
|
||||
```bash
|
||||
sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
|
||||
```
|
||||
|
||||
Bien vérifier le résultat. Sinon, il peut être plus simple de reprendre ce contenu:
|
||||
|
||||
```txt
|
||||
deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
|
||||
deb-src http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
|
||||
|
||||
deb http://security.debian.org/debian-security bookworm-security main
|
||||
deb-src http://security.debian.org/debian-security bookworm-security main
|
||||
|
||||
deb http://deb.debian.org/debian/ bookworm-updates main
|
||||
deb-src http://deb.debian.org/debian/ bookworm-updates main
|
||||
```
|
||||
|
||||
#### Mettre à jour
|
||||
|
||||
```bash
|
||||
/bin/rm /etc/apt/sources.list.d/scodoc.list
|
||||
apt-get clean
|
||||
apt-get update
|
||||
```
|
||||
|
||||
Les deux commandes suivantes sont longues, surtout ne pas les interrompre.
|
||||
Répondre "oui" (ou la réponse par défaut) aux diverses question, ou dire que
|
||||
vous conservez les versions locales modifiées de vos fichiers de configuration
|
||||
(lorsqu'un texte long s'affiche, taper 'q' puis "entrée"...).
|
||||
|
||||
```bash
|
||||
apt-get upgrade
|
||||
#
|
||||
|
||||
# Puis:
|
||||
apt-get full-upgrade
|
||||
```
|
||||
|
||||
Un petit nettoyage:
|
||||
|
||||
```bash
|
||||
apt-get autoremove
|
||||
```
|
||||
|
||||
Et un redémarrage
|
||||
|
||||
```bash
|
||||
shutdown -r now
|
||||
```
|
||||
|
||||
Après reconnexion, vous avez un serveur Debian 12. Reste à s'occuper de la base
|
||||
de données et de ScoDoc. D'abord, s'assurer que le service n'a pas redémarré:
|
||||
|
||||
```bash
|
||||
systemctl status scodoc9
|
||||
```
|
||||
|
||||
et si besoin le stopper avec :
|
||||
|
||||
```bash
|
||||
systemctl stop scodoc9
|
||||
```
|
||||
|
||||
## Problème avec proxmox
|
||||
|
||||
Si votre installation utilise des containers LXC/proxmox: on nous a signalé un
|
||||
problème de compatibilité proxmox / Debian 12, qui bloque le service REDIS
|
||||
(voire empêche le démarrage du container). Il semblerait que proxmox 7 ne soit
|
||||
pas compatible avec Debian 12. Faites des essais avant de migrer ScoDoc.
|
||||
|
||||
Au cas où ce lien peut servir: [Debian 12 et
|
||||
proxmox](https://www.abyssproject.net/2023/07/retex-sur-mes-upgrades-vers-debian-12-et-proxmox-ve-8)
|
||||
|
||||
Merci de vos retours si vous avez des informations sur ce problème.
|
||||
|
||||
## Upgrade Postgresql
|
||||
|
||||
Debian 12 est livré avec Postgresql 15, tandis que l'installation précédente
|
||||
tournait sous Postgresql 13. Il est donc nécessaire de migrer les données en
|
||||
base vers la nouvelle version.
|
||||
Procédure inspirée de
|
||||
[ce tuto en français](https://wiki.fiat-tux.fr/books/administration-syst%C3%A8mes/page/migration-d%E2%80%99une-version-majeure-de-postgresql-%C3%A0-une-autre)
|
||||
|
||||
Toujours dans un shell root, copier/coller les commandes suivantes:
|
||||
|
||||
```bash
|
||||
# Arrêter et mettre à jour
|
||||
service postgresql stop
|
||||
pg_dropcluster --stop 15 main
|
||||
pg_upgradecluster -m upgrade 13 main
|
||||
systemctl start postgresql
|
||||
# Vérifier l'etat du service
|
||||
systemctl status postgresql
|
||||
```
|
||||
|
||||
Puis
|
||||
|
||||
```bash
|
||||
/bin/su -c "/usr/lib/postgresql/15/bin/vacuumdb --all --analyze-in-stages" postgres
|
||||
|
||||
pg_dropcluster 13 main --stop
|
||||
apt-get autoremove --purge postgresql-13 postgresql-client-13
|
||||
```
|
||||
|
||||
Soyez attentif et vérifier que les commandes précédentes se sont exécutées sans erreur.
|
||||
|
||||
## Passage de ScoDoc 9.5 (ou 9.4) à 9.6
|
||||
|
||||
### Modification des sources de paquets Debian
|
||||
|
||||
- Supprimer l'ancien fichier:
|
||||
|
||||
```bash
|
||||
/bin/rm -f /etc/apt/sources.list.d/scodoc*
|
||||
```
|
||||
|
||||
- Ajouter le dépot scodoc: copier le fichier <a href="/attachments/scodoc.list"
|
||||
download>scodoc.list</a> dans `/etc/apt/sources.list.d/` à l'aide de la
|
||||
commande
|
||||
|
||||
```bash
|
||||
wget --directory-prefix=/etc/apt/sources.list.d/ https://scodoc.org/attachments/scodoc.list
|
||||
```
|
||||
|
||||
ou si vous préférez l'éditer pour qu'il contienne juste cette ligne:
|
||||
|
||||
```text
|
||||
# contenu du fichier /etc/apt/sources.list.d/scodoc.list
|
||||
deb http://scodoc.org/deb/bookworm bookworm main
|
||||
```
|
||||
|
||||
|
||||
|
||||
### Installation de la clé
|
||||
|
||||
L'ancienne clé crypto qui authentifie scodoc est toujours valide, mais il faut
|
||||
l'installer différemment. Comme root, lancer:
|
||||
|
||||
```bash
|
||||
apt-key export BBDA4CF7 | gpg --dearmour -o /etc/apt/trusted.gpg.d/scodoc.gpg
|
||||
```
|
||||
|
||||
### Mise à jour du paquet scodoc9
|
||||
|
||||
```bash
|
||||
apt update && apt upgrade
|
||||
```
|
||||
|
||||
devrait installer `scodoc9.6.x` (cette première install est un peu longue, il
|
||||
faut en effet charger et configurer de nombreux modules python).
|
||||
|
||||
### Migration des absences vers les assiduités
|
||||
|
||||
Le nouveau module de gestion des assiduité (absences/présences/justificatifs)
|
||||
permet d'importer les anciennes "absences" (et justificatifs). Pour cela, lancer
|
||||
les commandes suivantes:
|
||||
|
||||
```bash
|
||||
systemctl stop scodoc9 # le service DOIT etre stoppé !
|
||||
/bin/su scodoc
|
||||
#
|
||||
cd /opt/scodoc
|
||||
source venv/bin/activate
|
||||
flask migrate-abs-to-assiduites
|
||||
```
|
||||
|
||||
Pour plus de détails et paramétrages (plages horaires, ...), voir
|
||||
[la documentation sur la migration des absences](AssiduitesMigration.md).
|
||||
|
||||
Le traitement est assez long et peut prendre plusieurs minutes,
|
||||
suivant le nombre d'absences et la vitesse de votre serveur.
|
||||
|
||||
### Démarrage du service
|
||||
|
||||
Comme d'habitude, en tant que `root`: (faire `exit`si vous êtes resté dans le
|
||||
shell scodoc précédent):
|
||||
|
||||
```bash
|
||||
systemctl start scodoc9
|
||||
```
|
@ -1,33 +1,48 @@
|
||||
# Vérification des codes NIP
|
||||
|
||||
## Vérification des codes NIP
|
||||
Le code NIP est le code d'identification de l'étudiant utilisé par le service de la scolarité (logiciel Apogée) et qui apparait entre autre sur la carte d'étudiant. ScoDoc peut l'utiliser, ce qui est utile si le logiciel est interfacé à un portail qui le connecte à Apogée. Si vous utilisez ScoDoc seul, il n'est pas utile de saisir les codes NIP.
|
||||
Le code NIP est le code d'identification de l'étudiant utilisé par le service de
|
||||
la scolarité (logiciel Apogée) et qui apparait entre autre sur la carte
|
||||
d'étudiant. ScoDoc peut l'utiliser, ce qui est utile si le logiciel est
|
||||
interfacé à un portail qui le connecte à Apogée. Si vous utilisez ScoDoc seul,
|
||||
il n'est pas utile de saisir les codes NIP.
|
||||
|
||||
Lorsqu'on importe un étudiant depuis le portail, il est naturellement associé à son code NIP.
|
||||
Lorsqu'on importe un étudiant depuis le portail, il est naturellement associé à
|
||||
son code NIP.
|
||||
|
||||
Ce n'est pas le cas si l'on a importé l'étudiant à la main (via un formulaire ou l'importation d'une feuille Excel).
|
||||
Ce n'est pas le cas si l'on a importé l'étudiant à la main (via un formulaire ou
|
||||
l'importation d'une feuille Excel).
|
||||
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> Le code NIP est utilisé par le portail pour identifer les étudiants: *si ScoDoc ne le connait pas, l'étudiant n'a pas accès à son bulletin de notes sur le web*.
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
|
||||
alt="/!\" /> Le code NIP est utilisé par le portail pour identifier les
|
||||
étudiants: *si ScoDoc ne le connait pas, l'étudiant n'a pas accès à son bulletin
|
||||
de notes sur le web*.
|
||||
|
||||
## Fixer le code NIP d'un étudiant
|
||||
|
||||
Pour renseigner à postériori le code NIP d'un étudiant, passer par sa fiche
|
||||
individuelle, menu Etudiant, **Changer les données identité/admission**. En bas
|
||||
de cette page, la section "Informations Apogée" vous montre toutes les
|
||||
informations retrouvées dans Apogée.
|
||||
|
||||
Attention, dans la recherche est effectuée en utilisant le nom et le prénom.
|
||||
S'ils sont mal orthographiés (dans ScoDoc ou dans Apogée), elle peut échouer. Si
|
||||
on a des homonymes (cas fréquent), ScoDoc présente une liste d'étudiants
|
||||
d'Apogée pouvant correspondre à celui de ScoDoc: à vous de choisir.
|
||||
|
||||
Vous pouvez facilement copier le code de l'étudiant qui correspond via le bouton
|
||||
**copier ce code**. Cliquez ensuite sur le bouton **Modifier les données**.
|
||||
|
||||
## Vérifier les codes de tous les étudiants d'un semestre
|
||||
|
||||
Vous pouvez vérifier les codes et adresses mail de tous les étudiants d'un
|
||||
semestre via la page **vérification des codes Apogée**. Cette page est
|
||||
accessible via un lien en bas de la page **Synchroniser avec une étape Apogée**.
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
## Fixer le code NIP d'un étudiant
|
||||
Pour renseigner à postériori le code NIP d'un étudiant, passer par sa fiche individuelle, menu Etudiant, **Changer les données identité/admission**. En bas de cette page, la section "Informations Apogée" vous montre toutes les informations retrouvées dans Apogée.
|
||||
|
||||
Attention, dans la recherche est effectuée en utilisant le nom et le prénom. S'ils sont mal orthographiés (dans ScoDoc ou dans Apogée), elle peut échouer. Si on a des homonymes (cas fréquent), ScoDoc présente une liste d'étudiants d'Apogée pouvant correspondre à celui de ScoDoc: à vous de choisir.
|
||||
|
||||
Vous pouvez facilement copier le code de l'étudiant qui correspond via le bouton **copier ce code**.
|
||||
Cliquez ensuite sur le bouton **Modifier les données**.
|
||||
|
||||
|
||||
|
||||
## Vérifier les codes de tous les étudiants d'un semestre
|
||||
Vous pouvez vérifier les codes et adresses mail de tous les étudiants d'un semestre via la page **vérification des codes Apogée**. Cette page est accessible via un lien en bas de la page **Synchroniser avec une étape Apogée**.
|
||||
|
||||
|
||||
### Voir aussi:
|
||||
|
||||
- [Synchroniser avec une étape Apogée](SynchroApogee.md)
|
||||
- [Guide pour le chef de département](GuideAdminFormation.md)
|
||||
- [Opérations de fin de semestre](TransitionSemestre.md)
|
||||
|
||||
|
||||
- [Synchroniser avec une étape Apogée](SynchroApogee.md)
|
||||
- [Guide pour le ou la responsable de formation](GuideAdminFormation.md)
|
||||
- [Opérations de fin de semestre](TransitionSemestre.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
@ -1,112 +0,0 @@
|
||||
|
||||
# Modification d'un programme pédagogique et versions
|
||||
|
||||
Un programme pédagogique définit notamment les coefficients des modules qui le
|
||||
composent. Les semestres qui se réfèrent à ce programme utilisent ces
|
||||
coefficients pour calculer leurs notes. De même, les noms de UE et modules qui
|
||||
apparaissent sur les bulletins viennent du programme. Il faut être
|
||||
particulièrement vigilant lors des modifications du programme pédagogique.
|
||||
|
||||
Dans la configuration par défaut, seul le chef de département (rôle Admin) peut
|
||||
modifier les programmes pédagogiques.
|
||||
|
||||
(voir aussi des exemples de programmes en bas de la page
|
||||
[GuideAdminFormation](GuideAdminFormation.md)).
|
||||
|
||||
## Points importants
|
||||
|
||||
### Unités d'Enseignement (UE)
|
||||
|
||||
Les UE sont destinées à être *capitalisées* (voir
|
||||
[CapitalisationUE](CapitalisationUE.md)). Par conséquent, une formation en
|
||||
plusieurs semestres devrait normalement avoir un jeu d'UE différent dans chaque
|
||||
semestre.
|
||||
|
||||
* Il est parfois désirable de capitaliser au sein d'un parcours des UE
|
||||
appartenant à deux programmes ScoDoc différents (par exemple, on peut avoir
|
||||
changé de version du programme entre deux semestres, comme expliqué plus
|
||||
loin). Dans ce cas, il faut attribuer aux programmes le même code de formation
|
||||
(via le lien "modifier" sur la page d'accueil des programmes), et aussi
|
||||
attribuer les mêmes codes aux UE (via le lien "modifier l'UE" sur la page
|
||||
"programme détaillé et semestres").
|
||||
|
||||
* Les UE peuvent être de type "normal" ou "Sport&Culture". Ces dernières ne sont
|
||||
utilisées que pour les notes optionnelles (activités culturelles et sportives)
|
||||
utilisée dans certains établissements. Elles se voient attribuer une règle de
|
||||
calcul spécifique qui dépend généralement de l'établissement (il n'y à pas de
|
||||
règle nationale pour la prise en compte des notes de sport et culture).
|
||||
Typiquement, la note des UE de ce type spécial agit directement sur la moyenne
|
||||
générale de l'étudiant.
|
||||
|
||||
### Modules
|
||||
|
||||
* Le *code* du module va apparaitre sur les bulletins et certains tableaux
|
||||
récapitulatifs. Il comporte habituellement quelques caractères (comme "MATH",
|
||||
ou "SPO"). Si la version officielle de votre programme pédagogique n'utilise
|
||||
pas de codes de ce genre, inventez des codes à la fois courts (pas plus de 4
|
||||
ou 5 caractères) et évocateurs du nom du module.
|
||||
|
||||
* Le *titre* du module apparaitra sur le tableau de bord du semestre et sur les
|
||||
bulletins.
|
||||
|
||||
* L' *abréviation* est une version courte du titre. Si le titre n'est pas trop
|
||||
long (3 ou 4 mots), copier le. Sinon, inventer une abréviation en quelques
|
||||
mots qui soit lisible.
|
||||
|
||||
* Les volumes horaires ne sont présents que pour information et ne sont
|
||||
actuellement pas du tout utilisés par ScoDoc: il est donc facultatif de les
|
||||
indiquer.
|
||||
|
||||
* Le coefficient est utilisé pour le calcul de la moyenne d'UE et de la moyenne
|
||||
générale. Il s'agit d'un nombre réel positif ou nul.
|
||||
|
||||
* Choisir dans le menu la *matière* à laquelle appartient le module.
|
||||
|
||||
* Le semestre est un nombre indiquant dans quel semestre de la formation se
|
||||
place habituellement ce module. Il arrive que l'on décline la même formation
|
||||
selon différentes modalités (formation initiale, continue) avec des placements
|
||||
différents: dans ce cas, indiquer le semestre dans la modalité "habituelle";
|
||||
lors de la mise en place d'un semestre, on peut choisir manuellement des
|
||||
modules de tous les semestres.
|
||||
|
||||
### Ordre d'affichage des UE, matières et modules
|
||||
|
||||
Chaque élément (UE, matières et modules) possède un attribut *numéro* qui est un
|
||||
nombre entier utilisé pour le classement des éléments de même niveau dans la
|
||||
hiérarchie dans les tableaux et bulletins.
|
||||
|
||||
Il est conseillé d'attribuer les numéros de 10 en 10 afin de pouvoir plus
|
||||
facilement insérer un nouvel élément entre deux éléments existants. Par exemple,
|
||||
si l'on a dans une matière trois modules MA, MB, MC, on va leur attribuer les
|
||||
numéros 10, 20 et 30.
|
||||
|
||||
## Verrouillage et versions
|
||||
|
||||
Lorsque au moins l'un des semestres qui se réfèrent à ce programme est
|
||||
*verrouillé*, il devient impossible de modifier le programme (la page de
|
||||
présentation du programme ne comporte alors aucun lien). Deux cas peuvent se
|
||||
présenter:
|
||||
|
||||
* il s'agit d'une modification mineure (intitulé d'un module, ...) ne risquant
|
||||
pas affecter les notes existantes, et il y a peu de semestres verrouillés:
|
||||
dans ce cas, il est possible d'aller déverrouiller un à un les semestres
|
||||
concernés, puis d'effectuer la modification du programme avant de
|
||||
re-verrouiller les semestres.
|
||||
|
||||
* il s'agit d'une modification conséquente, on ne ne veut pas affecter les
|
||||
semestres existants: on crée alors une nouvelle *version* du programme. La
|
||||
version crée est une copie à l'identique du programme existant, que l'on peut
|
||||
modifier à sa guise.
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Guide du responsable de formation](GuideAdminFormation.md)
|
||||
- [Guide utilisateur](GuideUtilisateur.md)
|
||||
- [Tutoriels vidéo](https://www.youtube.com/channel/UCb0JYCBRi0CsE4XFp4ByhXg)
|
||||
- [Gestion des UE Bonus](https://www.youtube.com/watch?v=SVbjuDpq-lI)
|
||||
- [Mise en place des parcours BUT](https://www.youtube.com/watch?v=OnuOXJo-3ro)
|
||||
- [Saisie des codes Apogée](https://www.youtube.com/watch?v=MW0nNhbBjDM)
|
||||
- [Du DUT au BUT: comment transformer un programme](https://www.youtube.com/watch?v=9HizGTvYgck)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
2
docs/attachments/scodoc-bullseye.list
Normal file
2
docs/attachments/scodoc-bullseye.list
Normal file
@ -0,0 +1,2 @@
|
||||
# ScoDoc repository
|
||||
deb http://scodoc.org/repo bullseye main
|
@ -1,2 +1,2 @@
|
||||
# ScoDoc repository
|
||||
deb http://scodoc.org/repo bullseye main
|
||||
# ScoDoc repository for Debian 12 bookworm
|
||||
deb http://scodoc.org/deb/bookworm bookworm main
|
||||
|
Binary file not shown.
Binary file not shown.
Before Width: | Height: | Size: 260 KiB |
File diff suppressed because one or more lines are too long
Before Width: | Height: | Size: 336 KiB After Width: | Height: | Size: 442 KiB |
BIN
docs/img/ajouter_tags.png
Normal file
BIN
docs/img/ajouter_tags.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 646 KiB |
BIN
docs/img/regroupement_coherent_semestre.png
Normal file
BIN
docs/img/regroupement_coherent_semestre.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 548 KiB |
@ -1,6 +1,5 @@
|
||||
# ScoDoc: un logiciel libre pour le suivi de la scolarité
|
||||
|
||||
|
||||
ScoDoc est un logiciel libre créé par Emmanuel Viennet pour suivre la scolarité
|
||||
des étudiants universitaires. Il est principalement utilisé dans les IUT, mais
|
||||
aussi apprécié par plusieurs Écoles et Masters en France et à l'étranger. Il
|
||||
@ -20,8 +19,8 @@ ScoDoc est un *logiciel libre*: vous pouvez [participer à son développement](C
|
||||
|
||||
ScoDoc s'utilise sur un navigateur web standard: les utilisateurs n'ont rien à
|
||||
installer. Les établissements ou écoles doivent configurer un serveur: voir le
|
||||
[guide d'installation sur Debian 11](GuideInstallDebian11.md). La version ScoDoc
|
||||
9 est parue le 19 septembre 2021, la version 9.3 en juillet 2022. Les mises à jour sont
|
||||
[guide d'installation sur Debian 12](GuideInstallDebian12.md). La version ScoDoc
|
||||
9.6 est parue en juillet 2023. Les mises à jour (sécurité, améliorations) sont
|
||||
appliquées très fréquemment.
|
||||
|
||||
ScoDoc est utilisé dans de nombreux établissements français et étrangers, **dont
|
||||
@ -35,11 +34,11 @@ retourner à `Emmanuel.Viennet at gmail.com`.
|
||||
## Présentation générale
|
||||
|
||||
- [Présentation générale du logiciel avec copies d'écran](PresentationGenerale.md)
|
||||
|
||||
- [Les principaux objets de ScoDoc](IntroObjetsScoDoc.md)
|
||||
- Quelques <a href="https://www.youtube.com/playlist?list=PLw49h6RbvswhasBk9bXj7PzOD8GDW3kG1" target="_blank">vidéos d'introduction sur YouTube <img src="/img/tube.png" alt="" style="margin-top:0px; margin-bottom:0px; border-width:0px;"/></a>
|
||||
|
||||
- très ancienne présentation au colloque du [CRI-IUT](https://www.criiut.fr/) en 2013: [diapos en pdf](papers/presScoDocCRIIUT2013.pdf)
|
||||
- Un très très ancien [article sur ScoDoc](papers/scodoc-reunion2007.pdf)
|
||||
- Un *très* très ancien [article sur ScoDoc](papers/scodoc-reunion2007.pdf)
|
||||
|
||||
## Communauté d'utilisateurs
|
||||
|
||||
@ -49,11 +48,34 @@ retourner à `Emmanuel.Viennet at gmail.com`.
|
||||
|
||||
## Actualités
|
||||
|
||||
### ScoDoc 9.4.x
|
||||
### Mars 2024
|
||||
|
||||
Série en développement, centrés sur la gestion du *Bachelor Universitaire de
|
||||
technologie* (BUT) mais aussi sur la modernisation du logiciel et sa meilleure
|
||||
intégration dans les systèmes d'informations universitaires (API, CAS).
|
||||
La série **9.6.x** continue son développement, avec une gestion de l'assiduité
|
||||
toujours plus facile à utiliser, un nouveau module de génération des résultats
|
||||
pour les poursuites d'études, et de nombreuses améliorations.
|
||||
|
||||
### Septembre 2023: parution de ScoDoc 9.6.x pour Debian 12
|
||||
|
||||
**9.6.x** est la version en production de ScoDoc. Y sont régulièrement intégrées
|
||||
des améliorations et de nouvelles fonctionnalités. Elle inclue notamment le
|
||||
nouveau système de gestion des absences ("assiduités"), beaucoup plus riche que
|
||||
l'ancien.
|
||||
|
||||
**Il est conseillé de migrer au plus vite**: voir [la procédure de mise à
|
||||
jour](UpgradeToDeb12Sco96.md). Cette mise à jour n'est pas automatique car il
|
||||
faut passer le système d'exploitation de Debian 11 à Debian 12.
|
||||
|
||||
### Série 9.5.x
|
||||
|
||||
Version figée (Debian 11 seulement), seule de rares correctifs seront appliqués,
|
||||
ainsi que les éventuels correctifs de sécurité. **Fin de vie: 30 octobre 2023**.
|
||||
|
||||
### Série 9.4.x
|
||||
|
||||
Série en développement en 2022-2023, travaux centrés sur la gestion du *Bachelor
|
||||
Universitaire de technologie* (BUT) mais aussi sur la modernisation du logiciel
|
||||
et sa meilleure intégration dans les systèmes d'informations universitaires
|
||||
(API, CAS).
|
||||
|
||||
### Parution de ScoDoc 9 en 2021-2022
|
||||
|
||||
@ -64,14 +86,13 @@ gestion du *[Bachelor Universitaire de Technologie (BUT)](BUT.md)*.
|
||||
|
||||
### Contrats d'apprentissage
|
||||
|
||||
Depuis 2021, plusieurs étudiants ont été recrutés (BUT R&T Lannion, LP IUT
|
||||
Orléans, LP IUT Villetaneuse):
|
||||
|
||||
- développement d'une nouvelle API pour ScoDoc 9 (mise en service en juillet 2022);
|
||||
- développement d'un nouveau module de gestion des relations entreprises:
|
||||
fichier, contacts, stages, alternance (publiée en août 2022);
|
||||
- refonte du module de gestion des absences (en cours en 2022-2023).
|
||||
Depuis 2021, de nombreux étudiants ont été recrutés par l'association (BUT R&T
|
||||
Lannion, LP IUT Orléans, LP IUT Villetaneuse, BUT Informatique Lannion):
|
||||
|
||||
- développement d'une nouvelle API pour ScoDoc 9 (mise en service en juillet 2022);
|
||||
- développement d'un nouveau module de gestion des relations entreprises:
|
||||
fichier, contacts, stages, alternance (publiée en août 2022);
|
||||
- refonte du module de gestion des absences (en cours en 2022-2023, puis 2023-2024).
|
||||
|
||||
### Stagiaires
|
||||
|
||||
@ -108,9 +129,18 @@ entente.
|
||||
|
||||
### Feuille de route (roadmap)
|
||||
|
||||
Les prochaines versions de ScoDoc :
|
||||
|
||||
- ScoDoc 9.5 : printemps 2023
|
||||
9.6 évolue pour intégrer prochainement:
|
||||
|
||||
- de nouveaux bulletins spécifiques au BUT
|
||||
- le respect complet du RGPD
|
||||
|
||||
En parallèle, nous travaillons sur l'intégration avec les systèmes de gestion
|
||||
d'emplois du temps des universités, notamment pour faciliter le suivi de
|
||||
l'assiduité (lien emplois du temps / module ScoDoc).
|
||||
|
||||
Les anciennes versions de ScoDoc :
|
||||
|
||||
- ScoDoc 9.5 : printemps 2023 (*fin de vie octobre 2023*)
|
||||
|
||||
- Nouveau système de suivi de l'assiduité (absences, présences)
|
||||
|
||||
@ -144,11 +174,11 @@ Les prochaines versions de ScoDoc :
|
||||
- ScoDoc 9.0 : publiée le 19 sept. 2021, version complètement remaniée en
|
||||
Python 3/Flask.
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
|
||||
- [Guide utilisateur](GuideUtilisateur.md)
|
||||
- <a href="https://www.youtube.com/playlist?list=PLw49h6RbvswhasBk9bXj7PzOD8GDW3kG1" target="_blank">Tutoriels sur YouTube <img src="/img/tube.png" alt="" style="margin-top:0px; margin-bottom:0px; border-width:0px;"/></a>
|
||||
- [Contacts](Contact.md).
|
||||
|
Binary file not shown.
Binary file not shown.
BIN
docs/papers/Adhesion-2024-2025-Association-ScoDoc.docx
Normal file
BIN
docs/papers/Adhesion-2024-2025-Association-ScoDoc.docx
Normal file
Binary file not shown.
BIN
docs/papers/Adhesion-2024-2025-Association-ScoDoc.pdf
Normal file
BIN
docs/papers/Adhesion-2024-2025-Association-ScoDoc.pdf
Normal file
Binary file not shown.
22
docs/samples/sample_assiduite.json.md
Normal file
22
docs/samples/sample_assiduite.json.md
Normal file
@ -0,0 +1,22 @@
|
||||
### assiduite
|
||||
|
||||
#### GET /assiduite/1
|
||||
```json
|
||||
{
|
||||
"assiduite_id": 1,
|
||||
"code_nip": "1",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"desc": null,
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"est_just": false,
|
||||
"etat": "PRESENT",
|
||||
"etudid": 1,
|
||||
"external_data": null,
|
||||
"moduleimpl_id": 12,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
}
|
||||
```
|
||||
|
38
docs/samples/sample_assiduite_create.json.md
Normal file
38
docs/samples/sample_assiduite_create.json.md
Normal file
@ -0,0 +1,38 @@
|
||||
### assiduite_create
|
||||
|
||||
#### POST /assiduite/1/create
|
||||
> `Content-Type: application/json`
|
||||
>
|
||||
> `[{"date_debut": "2023-10-27T08:00","date_fin": "2023-10-27T10:00","etat": "absent"}]`
|
||||
|
||||
```json
|
||||
{
|
||||
"errors": [],
|
||||
"success": [
|
||||
{
|
||||
"indice": 0,
|
||||
"message": {
|
||||
"assiduite_id": 39
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
#### POST /assiduite/1/create
|
||||
> `Content-Type: application/json`
|
||||
>
|
||||
> `[{"date_debut": "2023-10-27T08:00","date_fin": "2023-10-27T10:00","etat": "absent"}]`
|
||||
|
||||
```json
|
||||
{
|
||||
"errors": [
|
||||
{
|
||||
"indice": 0,
|
||||
"message": "Duplication: la p\u00e9riode rentre en conflit avec une plage enregistr\u00e9e"
|
||||
}
|
||||
],
|
||||
"success": []
|
||||
}
|
||||
```
|
||||
|
28
docs/samples/sample_assiduite_delete.json.md
Normal file
28
docs/samples/sample_assiduite_delete.json.md
Normal file
@ -0,0 +1,28 @@
|
||||
### assiduite_delete
|
||||
|
||||
#### POST /assiduite/delete
|
||||
> `Content-Type: application/json`
|
||||
>
|
||||
> `[2,2,3]`
|
||||
|
||||
```json
|
||||
{
|
||||
"errors": [
|
||||
{
|
||||
"indice": 1,
|
||||
"message": "Assiduite non existante"
|
||||
}
|
||||
],
|
||||
"success": [
|
||||
{
|
||||
"indice": 0,
|
||||
"message": "OK"
|
||||
},
|
||||
{
|
||||
"indice": 2,
|
||||
"message": "OK"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
35
docs/samples/sample_assiduite_edit.json.md
Normal file
35
docs/samples/sample_assiduite_edit.json.md
Normal file
@ -0,0 +1,35 @@
|
||||
### assiduite_edit
|
||||
|
||||
#### POST /assiduite/1/edit
|
||||
> `Content-Type: application/json`
|
||||
>
|
||||
> `{"etat":"absent"}`
|
||||
|
||||
```json
|
||||
{
|
||||
"OK": true
|
||||
}
|
||||
```
|
||||
|
||||
#### POST /assiduite/1/edit
|
||||
> `Content-Type: application/json`
|
||||
>
|
||||
> `{"etat": "retard","moduleimpl_id":3}`
|
||||
|
||||
```json
|
||||
{
|
||||
"OK": true
|
||||
}
|
||||
```
|
||||
|
||||
#### POST /assiduite/1/edit
|
||||
> `Content-Type: application/json`
|
||||
>
|
||||
> `{"moduleimpl_id":2}`
|
||||
|
||||
```json
|
||||
{
|
||||
"OK": true
|
||||
}
|
||||
```
|
||||
|
32
docs/samples/sample_assiduite_justificatifs.json.md
Normal file
32
docs/samples/sample_assiduite_justificatifs.json.md
Normal file
@ -0,0 +1,32 @@
|
||||
### assiduite_justificatifs
|
||||
|
||||
#### GET /assiduite/1/justificatifs
|
||||
```json
|
||||
[
|
||||
1,
|
||||
"..."
|
||||
]
|
||||
```
|
||||
|
||||
#### GET /assiduite/1/justificatifs/long
|
||||
```json
|
||||
[
|
||||
{
|
||||
"code_nip": "1",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"etat": "MODIFIE",
|
||||
"etudid": 1,
|
||||
"external_data": null,
|
||||
"fichier": null,
|
||||
"justif_id": 1,
|
||||
"raison": null,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
},
|
||||
"..."
|
||||
]
|
||||
```
|
||||
|
79
docs/samples/sample_assiduites.json.md
Normal file
79
docs/samples/sample_assiduites.json.md
Normal file
@ -0,0 +1,79 @@
|
||||
### assiduites
|
||||
|
||||
#### GET /assiduites/1
|
||||
```json
|
||||
[
|
||||
{
|
||||
"assiduite_id": 1,
|
||||
"code_nip": "1",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"desc": null,
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"est_just": false,
|
||||
"etat": "PRESENT",
|
||||
"etudid": 1,
|
||||
"external_data": null,
|
||||
"moduleimpl_id": 12,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
},
|
||||
"..."
|
||||
]
|
||||
```
|
||||
|
||||
#### GET /assiduites/1/query?etat=retard
|
||||
```json
|
||||
[
|
||||
"..."
|
||||
]
|
||||
```
|
||||
|
||||
#### GET /assiduites/1/query?moduleimpl_id=1
|
||||
```json
|
||||
[
|
||||
"..."
|
||||
]
|
||||
```
|
||||
|
||||
#### GET /assiduites/1/query?with_justifs=
|
||||
```json
|
||||
[
|
||||
{
|
||||
"assiduite_id": 1,
|
||||
"code_nip": "1",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"desc": null,
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"est_just": false,
|
||||
"etat": "PRESENT",
|
||||
"etudid": 1,
|
||||
"external_data": null,
|
||||
"justificatifs": [
|
||||
{
|
||||
"code_nip": "1",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"etat": "MODIFIE",
|
||||
"etudid": 1,
|
||||
"external_data": null,
|
||||
"fichier": null,
|
||||
"justif_id": 1,
|
||||
"raison": null,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
}
|
||||
],
|
||||
"moduleimpl_id": 12,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
},
|
||||
"..."
|
||||
]
|
||||
```
|
||||
|
84
docs/samples/sample_assiduites_count.json.md
Normal file
84
docs/samples/sample_assiduites_count.json.md
Normal file
@ -0,0 +1,84 @@
|
||||
### assiduites_count
|
||||
|
||||
#### GET /assiduites/1/count
|
||||
```json
|
||||
{
|
||||
"compte": 1,
|
||||
"demi": 0,
|
||||
"heure": 0.0,
|
||||
"journee": 1
|
||||
}
|
||||
```
|
||||
|
||||
#### GET /assiduites/1/count/query?etat=present,retard&metric=compte,heure
|
||||
```json
|
||||
{
|
||||
"compte": 1,
|
||||
"heure": 0.0
|
||||
}
|
||||
```
|
||||
|
||||
#### GET /assiduites/1/count/query?etat=retard
|
||||
```json
|
||||
{
|
||||
"compte": 0,
|
||||
"demi": 0,
|
||||
"heure": 0,
|
||||
"journee": 0
|
||||
}
|
||||
```
|
||||
|
||||
#### GET /assiduites/1/count/query?split
|
||||
```json
|
||||
{
|
||||
"absent": {
|
||||
"compte": 0,
|
||||
"demi": 0,
|
||||
"heure": 0,
|
||||
"journee": 0,
|
||||
"justifie": {
|
||||
"compte": 0,
|
||||
"demi": 0,
|
||||
"heure": 0,
|
||||
"journee": 0
|
||||
},
|
||||
"non_justifie": {
|
||||
"compte": 0,
|
||||
"demi": 0,
|
||||
"heure": 0,
|
||||
"journee": 0
|
||||
}
|
||||
},
|
||||
"present": {
|
||||
"compte": 1,
|
||||
"demi": 0,
|
||||
"heure": 0.0,
|
||||
"journee": 1
|
||||
},
|
||||
"retard": {
|
||||
"compte": 0,
|
||||
"demi": 0,
|
||||
"heure": 0,
|
||||
"journee": 0,
|
||||
"justifie": {
|
||||
"compte": 0,
|
||||
"demi": 0,
|
||||
"heure": 0,
|
||||
"journee": 0
|
||||
},
|
||||
"non_justifie": {
|
||||
"compte": 0,
|
||||
"demi": 0,
|
||||
"heure": 0,
|
||||
"journee": 0
|
||||
}
|
||||
},
|
||||
"total": {
|
||||
"compte": 1,
|
||||
"demi": 0,
|
||||
"heure": 0.0,
|
||||
"journee": 1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
38
docs/samples/sample_assiduites_create.json.md
Normal file
38
docs/samples/sample_assiduites_create.json.md
Normal file
@ -0,0 +1,38 @@
|
||||
### assiduites_create
|
||||
|
||||
#### POST /assiduites/create
|
||||
> `Content-Type: application/json`
|
||||
>
|
||||
> `[{"etudid":-1,"date_debut": "2023-10-26T08:00","date_fin": "2023-10-26T10:00","etat": "absent"}]`
|
||||
|
||||
```json
|
||||
{
|
||||
"errors": [
|
||||
{
|
||||
"indice": 0,
|
||||
"message": "Cet \u00e9tudiant n'existe pas."
|
||||
}
|
||||
],
|
||||
"success": []
|
||||
}
|
||||
```
|
||||
|
||||
#### POST /assiduites/create
|
||||
> `Content-Type: application/json`
|
||||
>
|
||||
> `[{"etudid":1,"date_debut": "2023-10-26T08:00","date_fin": "2023-10-26T10:00","etat": "absent"}]`
|
||||
|
||||
```json
|
||||
{
|
||||
"errors": [],
|
||||
"success": [
|
||||
{
|
||||
"indice": 0,
|
||||
"message": {
|
||||
"assiduite_id": 40
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
17
docs/samples/sample_assiduites_evaluations.json.md
Normal file
17
docs/samples/sample_assiduites_evaluations.json.md
Normal file
@ -0,0 +1,17 @@
|
||||
### assiduites_evaluations
|
||||
|
||||
#### GET /assiduites/1/evaluations
|
||||
```json
|
||||
[
|
||||
{
|
||||
"assiduites": [],
|
||||
"evaluation_id": 1
|
||||
},
|
||||
{
|
||||
"assiduites": [],
|
||||
"evaluation_id": 2
|
||||
},
|
||||
"..."
|
||||
]
|
||||
```
|
||||
|
119
docs/samples/sample_assiduites_formsemestre.json.md
Normal file
119
docs/samples/sample_assiduites_formsemestre.json.md
Normal file
@ -0,0 +1,119 @@
|
||||
### assiduites_formsemestre
|
||||
|
||||
#### GET /assiduites/formsemestre/1
|
||||
```json
|
||||
[
|
||||
{
|
||||
"assiduite_id": 1,
|
||||
"code_nip": "1",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"desc": null,
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"est_just": false,
|
||||
"etat": "PRESENT",
|
||||
"etudid": 1,
|
||||
"external_data": null,
|
||||
"moduleimpl_id": 12,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
},
|
||||
{
|
||||
"assiduite_id": 2,
|
||||
"code_nip": "NIP2",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"desc": null,
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"est_just": false,
|
||||
"etat": "RETARD",
|
||||
"etudid": 2,
|
||||
"external_data": null,
|
||||
"moduleimpl_id": 4,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
},
|
||||
"..."
|
||||
]
|
||||
```
|
||||
|
||||
#### GET /assiduites/formsemestre/1/query?etat=retard
|
||||
```json
|
||||
[
|
||||
{
|
||||
"assiduite_id": 2,
|
||||
"code_nip": "NIP2",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"desc": null,
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"est_just": false,
|
||||
"etat": "RETARD",
|
||||
"etudid": 2,
|
||||
"external_data": null,
|
||||
"moduleimpl_id": 4,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
},
|
||||
{
|
||||
"assiduite_id": 7,
|
||||
"code_nip": "NIP4",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"desc": null,
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"est_just": false,
|
||||
"etat": "RETARD",
|
||||
"etudid": 4,
|
||||
"external_data": null,
|
||||
"moduleimpl_id": 6,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
},
|
||||
"..."
|
||||
]
|
||||
```
|
||||
|
||||
#### GET /assiduites/formsemestre/1/query?moduleimpl_id=1
|
||||
```json
|
||||
[
|
||||
{
|
||||
"assiduite_id": 26,
|
||||
"code_nip": "11",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"desc": null,
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"est_just": false,
|
||||
"etat": "PRESENT",
|
||||
"etudid": 11,
|
||||
"external_data": null,
|
||||
"moduleimpl_id": 1,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
},
|
||||
{
|
||||
"assiduite_id": 38,
|
||||
"code_nip": "NIP16",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"desc": null,
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"est_just": false,
|
||||
"etat": "RETARD",
|
||||
"etudid": 16,
|
||||
"external_data": null,
|
||||
"moduleimpl_id": 1,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
},
|
||||
"..."
|
||||
]
|
||||
```
|
||||
|
30
docs/samples/sample_assiduites_formsemestre_count.json.md
Normal file
30
docs/samples/sample_assiduites_formsemestre_count.json.md
Normal file
@ -0,0 +1,30 @@
|
||||
### assiduites_formsemestre_count
|
||||
|
||||
#### GET /assiduites/formsemestre/1/count
|
||||
```json
|
||||
{
|
||||
"compte": 38,
|
||||
"demi": 13,
|
||||
"heure": 39.0,
|
||||
"journee": 18
|
||||
}
|
||||
```
|
||||
|
||||
#### GET /assiduites/formsemestre/1/count/query?etat=present,retard&metric=compte,heure
|
||||
```json
|
||||
{
|
||||
"compte": 27,
|
||||
"heure": 28.0
|
||||
}
|
||||
```
|
||||
|
||||
#### GET /assiduites/formsemestre/1/count/query?etat=retard
|
||||
```json
|
||||
{
|
||||
"compte": 15,
|
||||
"demi": 9,
|
||||
"heure": 17.0,
|
||||
"journee": 12
|
||||
}
|
||||
```
|
||||
|
62
docs/samples/sample_assiduites_group.json.md
Normal file
62
docs/samples/sample_assiduites_group.json.md
Normal file
@ -0,0 +1,62 @@
|
||||
### assiduites_group
|
||||
|
||||
#### GET /assiduites/group/query?etudids=1,2,3
|
||||
```json
|
||||
{
|
||||
"1": [
|
||||
{
|
||||
"assiduite_id": 1,
|
||||
"code_nip": "1",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"desc": null,
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"est_just": false,
|
||||
"etat": "PRESENT",
|
||||
"etudid": 1,
|
||||
"external_data": null,
|
||||
"moduleimpl_id": 12,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
}
|
||||
],
|
||||
"2": [
|
||||
{
|
||||
"assiduite_id": 2,
|
||||
"code_nip": "NIP2",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"desc": null,
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"est_just": false,
|
||||
"etat": "RETARD",
|
||||
"etudid": 2,
|
||||
"external_data": null,
|
||||
"moduleimpl_id": 4,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
}
|
||||
],
|
||||
"3": [
|
||||
{
|
||||
"assiduite_id": 3,
|
||||
"code_nip": "3",
|
||||
"date_debut": "2022-08-20T12:00:00.000000+02:00",
|
||||
"date_fin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"desc": null,
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"est_just": false,
|
||||
"etat": "PRESENT",
|
||||
"etudid": 3,
|
||||
"external_data": null,
|
||||
"moduleimpl_id": 18,
|
||||
"user_id": null,
|
||||
"user_name": null,
|
||||
"user_nom_complet": null
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
21
docs/samples/sample_billets_absence_create.json.md
Normal file
21
docs/samples/sample_billets_absence_create.json.md
Normal file
@ -0,0 +1,21 @@
|
||||
### billets_absence_create
|
||||
|
||||
#### POST /billets_absence/create
|
||||
> `Content-Type: application/json`
|
||||
>
|
||||
> `{"etudid":"1","abs_begin":"2023-10-27T10:00","abs_end":"2023-10-28T10:00","description":"grave malade","justified":"1"}`
|
||||
|
||||
```json
|
||||
{
|
||||
"abs_begin": "2022-08-20T12:00:00.000000+02:00",
|
||||
"abs_end": "2022-08-20T12:00:00.000000+02:00",
|
||||
"billet_id": 1,
|
||||
"description": "grave malade",
|
||||
"entry_date": "2022-08-20T12:00:00.000000+02:00",
|
||||
"etat": false,
|
||||
"etudid": 1,
|
||||
"id": 1,
|
||||
"justified": true
|
||||
}
|
||||
```
|
||||
|
1042
docs/samples/sample_bulletin.json.md
Normal file
1042
docs/samples/sample_bulletin.json.md
Normal file
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,4 +1,4 @@
|
||||
### formsemestre-decisions_jury
|
||||
### decisions_jury
|
||||
|
||||
#### GET /formsemestre/1/decisions_jury
|
||||
```json
|
@ -1,9 +0,0 @@
|
||||
### departement-delete
|
||||
|
||||
#### POST /departement/NEWONE/delete
|
||||
```json
|
||||
{
|
||||
"OK": true
|
||||
}
|
||||
```
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user