Explications jurys BUT

This commit is contained in:
Emmanuel Viennet 2023-07-04 15:59:43 +02:00
parent 23642a9910
commit ed8c651df6
3 changed files with 229 additions and 8 deletions

View File

@ -316,13 +316,50 @@ Un exemple préliminaire:
## Tenue des Jury BUT
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).
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.
- Validation des semestres (bien que cela ait peu de conséquences concrètes
pour les semestres impairs.
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).
On va enregistrer:
- 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.
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.
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).
A la fin, les validations enregistrées pour cet étudiant sont:
- UE11/2021: AJ
- UE12/2021: AJ
- UE11/2022: ADM
- UE12/2022: ADM
- RCUE1: ADM
- Années BUT1 : ADM
- Règles de compensation au sein de chaque niveau, pour validation de l'année.
!!! note "Voir aussi"

183
docs/DevJuryBUT.md Normal file
View 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.

View File

@ -16,9 +16,10 @@ Discord ouvert sur invitation aux développeur actifs. Contacter Emmanuel Vienne
- [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
- [Discussions pour la future gestion des absences](IdeesGestionAbsences.md)
- 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
@ -31,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