forked from ScoDoc/DocScoDoc
Compare commits
6 Commits
007987db88
...
8ce4ca0f28
Author | SHA1 | Date |
---|---|---|
Emmanuel Viennet | 8ce4ca0f28 | |
Emmanuel Viennet | cf57787c45 | |
Emmanuel Viennet | d5ff90dc7f | |
Emmanuel Viennet | 055a85e274 | |
Emmanuel Viennet | ed8c651df6 | |
Emmanuel Viennet | 23642a9910 |
|
@ -1,91 +1,45 @@
|
|||
## Module "Assiduités"
|
||||
# Module "Assiduités"
|
||||
|
||||
Ce module de ScoDoc a pour but de remplacer le module d'Absences présent dans Scodoc.
|
||||
En plus de moderniser l'ancien module, le module assiduités met à disposition une api complète.
|
||||
Ce module de ScoDoc remplace l'ancien module de suivi des absences de Scodoc.
|
||||
En plus de moderniser l'ancien module, le module assiduités met à disposition une API complète.
|
||||
|
||||
Ce projet a été développé en 2022-2023, par Matthias Hartmann, apprenti de l'IUT de
|
||||
Lannion financé par l'Association ScoDoc.
|
||||
|
||||
[Vidéo de présentation du module d'assiduités ](#)
|
||||
**Ce module est disponible à partir de ScoDoc version 9.6**.
|
||||
|
||||
[Vidéo de présentation du module d'assiduités ](#) TODO EV à publier sur la chaîne YT
|
||||
|
||||
## Fonctionnalités
|
||||
|
||||
Le module, intégrée à ScoDoc, fournit pour l'instant:
|
||||
Le module fournit:
|
||||
|
||||
- Gestion des absences/présences/retard
|
||||
- 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 numériques.
|
||||
- API complète
|
||||
- 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)
|
||||
|
||||
## Guide d'utilisation
|
||||
|
||||
- [Migration de l'ancien module](#migration-de-lancien-module)
|
||||
- [Personnalisation du module](#personnalisation-du-module)
|
||||
- [Saisie des Assiduités](#saisie-des-assiduités)
|
||||
- [Module "Assiduités"](#module-assiduités)
|
||||
- [Fonctionnalités](#fonctionnalités)
|
||||
- [Guide d'utilisation](#guide-dutilisation)
|
||||
- [Migration de l'ancien module](#migration-de-lancien-module)
|
||||
- [Personnalisation du module](#personnalisation-du-module)
|
||||
- [Saisie des Assiduités](#saisie-des-assiduités)
|
||||
- [Saisie d'un groupe](#saisie-dun-groupe)
|
||||
- [Saisie Journalière](#saisie-journalière)
|
||||
- [Saisie différée](#saisie-différée)
|
||||
|
||||
### Migration de l'ancien module
|
||||
|
||||
Afin de favoriser la transition de l'ancien module au nouveau, un script de migration a été développé.
|
||||
|
||||
#### Script de Migration
|
||||
|
||||
Le script se nomme `migrate-abs-to-assiduites` et ne peut se lancer qu'en ligne de commande.
|
||||
|
||||
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`
|
||||
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
|
||||
|
||||
|
@ -97,9 +51,12 @@ Le module possède deux types de configuration, une générale et une par dépar
|
|||
|
||||
Route : `/ScoDoc/config_assiduites`
|
||||
|
||||
- `Début de la journée` : l'heure de début de la ligne temporelle (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 de la ligne temporelle (par défaut : 18h00)
|
||||
- `Début de la journée` : l'heure de début de la ligne temporelle (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 de la ligne temporelle (par défaut :
|
||||
18h00)
|
||||
- `Granularité` : La granularité de la ligne temporelle. (par défaut : 15 min)
|
||||
|
||||
**La configuration par département/semestre permet de configurer certaines actions liés à l'assiduité**
|
||||
|
@ -108,41 +65,57 @@ Route : `/ScoDoc/config_assiduites`
|
|||
|
||||
Route : `/ScoDoc/<Dept>/Scolarite/edit_preferences`
|
||||
|
||||
- `Forcer la déclaration du module` : Forcer les utilisateurs de ScoDoc à renseigner le module à chaque saisie d'assiduités.
|
||||
- `Forcer l'appel des présents` : Force les utilisateurs à noter les présences/absences/retard lors d'une saisie.
|
||||
- `Durée par défaut d'un créneau` : Détermine la durée classique d'un cours. (Ce sera la période préenregistrée sur la ligne temporelle)
|
||||
- `Définir l'état par défaut` : Défini l'état par défaut qui sera appliqué aux étudiants avant validation d'une saisie d'assiduité.
|
||||
- `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
|
||||
- `Forcer la déclaration du module` : Forcer les utilisateurs de ScoDoc à
|
||||
renseigner le module à chaque saisie d'assiduités.
|
||||
- `Forcer l'appel des présents` : Force les utilisateurs à noter les
|
||||
présences/absences/retard lors d'une saisie.
|
||||
- `Durée par défaut d'un créneau` : Détermine la durée classique d'un cours. (Ce
|
||||
sera la période préenregistrée sur la ligne temporelle)
|
||||
- `Définir l'état par défaut` : Défini l'état par défaut qui sera appliqué aux
|
||||
étudiants avant validation d'une saisie d'assiduité.
|
||||
- `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
|
||||
|
||||
### Saisie des Assiduités
|
||||
|
||||
La saisie se fait soit sur un groupe soit sur un étudiant. Dans tous les cas il y a deux façons de saisir l'assiduité.
|
||||
Une saisie `Journalière` et une saisie `Différée`.
|
||||
La saisie se fait soit sur un groupe soit sur un étudiant. Dans tous les cas il
|
||||
y a deux façons de saisir l'assiduité. Une saisie `Journalière` et une saisie
|
||||
`Différée`.
|
||||
|
||||
**Saisie d'un groupe**
|
||||
#### Saisie d'un groupe
|
||||
|
||||
Tout comme l'ancien module, pour saisir l'assiduité d'un groupe il faut se rendre sur la page un semestre du département concerné.
|
||||
Comme dans l'ancien système, pour saisir l'assiduité d'un groupe il faut se
|
||||
rendre sur la page un semestre du département concerné.
|
||||
|
||||
![Page du semestre concerné](#)
|
||||
|
||||
Au bas de cette page vous retrouverez la liste des groupes du semestre. Si vous avez la permission de modifier l'assiduité, vous observerez 3 boutons supplémentaires sur chaque groupe vous permettant de voir ou saisir l'assiduité du groupe.
|
||||
Au bas de cette page vous retrouverez la liste des groupes du semestre. Si vous
|
||||
avez la permission de modifier l'assiduité, vous observerez 3 boutons
|
||||
supplémentaires sur chaque groupe vous permettant de voir ou saisir l'assiduité
|
||||
du groupe.
|
||||
|
||||
#### Saisie Journalière
|
||||
|
||||
La première chose à faire lorsque vous êtes arrivés sur la page "Saisie Journalière" c'est de compléter les informations de la séance :
|
||||
La première chose à faire lorsque vous êtes arrivés sur la page "Saisie
|
||||
Journalière" c'est de compléter les informations de la séance :
|
||||
|
||||
![Capture des sélecteurs](#)
|
||||
|
||||
- Le ou les groupes sélectionnés (dans la plupart des cas, le groupe est déjà
|
||||
présélectionné)
|
||||
- Le module concerné (par défaut il n'est pas obligatoire de sélectionner un
|
||||
module, cependant une configuration permet de forcer la sélection)
|
||||
- La date de la saisie. Attention, seule les dates comprises dans le semestre
|
||||
sont valides. (Un message d'erreur vous le signalera si la date n'est pas
|
||||
valide)
|
||||
|
||||
- Le ou les groupes sélectionnés (dans la plupart des cas, le groupe est déjà présélectionné)
|
||||
- Le module concerné (par défaut il n'est pas obligatoire de sélectionner un module, cependant une configuration permet de forcer la sélection)
|
||||
- La date de la saisie. Attention, seule les dates comprises dans le semestre sont valides. (Un message d'erreur vous le signalera si la date n'est pas valide)
|
||||
Lorsque vous êtes sûr de vous, appuyer sur le bouton `Valider`.
|
||||
|
||||
Lorsque vous êtes sûr de vous, appuyer sur le bouton `Valider`.
|
||||
**Attention : La validation est définitive, si vous avez fait une erreur il faudra recharger la page**
|
||||
|
||||
Après la validation, les champs précédents seront grisés.
|
||||
|
@ -151,86 +124,137 @@ Explication de l'interface
|
|||
|
||||
![Capture de l'interface](#)
|
||||
|
||||
|
||||
1. La ligne temporelle (Timeline) sert à désigner la période de l'assiduité qui sera saisie.
|
||||
|
||||
Il est possible de la déplacer en maintenant le clique gauche dessus puis en bougeant la souris.
|
||||
Il est possible de la déplacer en maintenant le clic gauche dessus puis en
|
||||
bougeant la souris.
|
||||
|
||||
Si la période n'est pas de la bonne taille, il est possible de l'agrandir ou de la réduire en plaçant sa souris à l'extrémité droite.
|
||||
Si la période n'est pas de la bonne taille, il est possible de l'agrandir ou
|
||||
de la réduire en plaçant sa souris à l'extrémité droite.
|
||||
|
||||
Votre curseur devrait changer, à partir de ce moment là vous pouvez cliquer puis bouger l'extrémité pour modifier la taille de la période.
|
||||
Votre curseur devrait changer, à partir de ce moment là vous pouvez cliquer
|
||||
puis bouger l'extrémité pour modifier la taille de la période.
|
||||
|
||||
Si la période bouge toujours alors que vous avez lâché le clique gauche, cliquer à nouveau.
|
||||
Si la période bouge toujours alors que vous avez lâché le clic gauche,
|
||||
cliquer à nouveau.
|
||||
|
||||
2. Les boutons d'actions de masse `Mettre tout le monde : `. Ces boutons définirons le même état pour chaque étudiant sur la période sélectionnée.
|
||||
2. Les boutons d'actions de masse `Mettre tout le monde : `. Ces boutons
|
||||
définirons le même état pour chaque étudiant sur la période sélectionnée.
|
||||
|
||||
En cliquant sur un bouton d'état, l'état sera mis pour chaque étudiant, pour modifier cet état il faut appuyer sur un autre bouton d'état.
|
||||
En cliquant sur un bouton d'état, l'état sera mis pour chaque étudiant, pour
|
||||
modifier cet état il faut appuyer sur un autre bouton d'état.
|
||||
|
||||
Si vous souhaitez retirer les assiduités, il faut cliquer sur le bouton d'état ayant le même état que les étudiants.
|
||||
Si vous souhaitez retirer les assiduités, il faut cliquer sur le bouton
|
||||
d'état ayant le même état que les étudiants.
|
||||
|
||||
3. Les lignes étudiants sont des lignes montrant les informations d'assiduité de chaque étudiant. Chaque ligne est composée de 3 parties :
|
||||
3. Les lignes étudiants sont des lignes montrant les informations d'assiduité de
|
||||
chaque étudiant. Chaque ligne est composée de 3 parties :
|
||||
|
||||
1. Le nom, le prénom et une photo de l'étudiant afin de le reconnaître facilement
|
||||
1. Le nom, le prénom et une photo de l'étudiant afin de le reconnaître
|
||||
facilement
|
||||
|
||||
2. Une petite ligne temporelle montrant l'assiduité de l'étudiant sur la journée.
|
||||
2. Une petite ligne temporelle montrant l'assiduité de l'étudiant sur la
|
||||
journée.
|
||||
|
||||
Le carré au début de la ligne montre la dernière assiduité du jour précédent.
|
||||
Le carré au début de la ligne montre la dernière assiduité du jour
|
||||
précédent.
|
||||
|
||||
En passant votre souris au dessus des couleurs, vous aurez accès à plus d'informations sur l'assiduité de l'étudiant.
|
||||
En passant votre souris au dessus des couleurs, vous aurez accès à plus
|
||||
d'informations sur l'assiduité de l'étudiant.
|
||||
|
||||
Cliquer sur une assiduité positionnera la ligne temporelle globale sur la période de l'assiduité.
|
||||
Cliquer sur une assiduité positionnera la ligne temporelle globale sur
|
||||
la période de l'assiduité.
|
||||
|
||||
La période globale est représentée par un encadré bleu sur la ligne temporelle.
|
||||
La période globale est représentée par un encadré bleu sur la ligne
|
||||
temporelle.
|
||||
|
||||
Les assiduités justifiées et validés sont représentés par leur couleur respective + un hachage bleu
|
||||
Les assiduités justifiées et validés sont représentés par leur couleur
|
||||
respective + un hachage bleu
|
||||
|
||||
Les assiduités justifiées mais non validées sont représentés par leur couleur respective + un hachage rouge.
|
||||
Les assiduités justifiées mais non validées sont représentés par leur
|
||||
couleur respective + un hachage rouge.
|
||||
|
||||
3. Les boutons d'assiduités individuels. Ces boutons permettent de déterminer l'état de l'étudiant.
|
||||
|
||||
Ils fonctionnent de la même façon que les boutons `mettre tout le monde :`.
|
||||
|
||||
Si la ligne de l'étudiant est rouge, cela signifie que la période sélectionnée rentre en conflit avec les assiduités de l'étudiant. Cliquer sur une bouton d'assiduité ne modifiera pas l'état de l'étudiant mais ouvrira un menu de résolution de conflit.
|
||||
Si la ligne de l'étudiant est rouge, cela signifie que la période
|
||||
sélectionnée rentre en conflit avec les assiduités de l'étudiant.
|
||||
Cliquer sur un bouton d'assiduité ne modifiera pas l'état de l'étudiant
|
||||
mais ouvrira un menu de résolution de conflit.
|
||||
|
||||
![Résolution de conflit](#)
|
||||
|
||||
Les assiduités de la page sont enregistrées en temps réel. Lorsque la saisie est terminée vous pouvez fermer la page.
|
||||
Les assiduités de la page sont enregistrées en temps réel. Lorsque la saisie est
|
||||
terminée vous pouvez fermer la page.
|
||||
|
||||
#### Saisie différée
|
||||
|
||||
La page saisie différée à pour but de faciliter la saisie d'assiduités avec plusieurs périodes.
|
||||
La page saisie différée a pour but de faciliter la saisie d'assiduités avec
|
||||
plusieurs périodes.
|
||||
|
||||
![Page différée](#)
|
||||
|
||||
La page est composée d'un tableau et d'un bouton valider. **Cette page ne sauvegarde pas automatiquement les modifications**
|
||||
La page est composée d'un tableau et d'un bouton valider.
|
||||
**Cette page ne sauvegarde pas automatiquement les modifications**
|
||||
|
||||
Explication du tableau :
|
||||
Explication du tableau :
|
||||
|
||||
- La colonne `Noms` : Vous y retrouverez tous les étudiants du groupe
|
||||
sélectionné. En cliquant sur le titre de la colonne vous pourrez changer
|
||||
l'ordre des étudiants (croissant ou décroissant)
|
||||
- Les colonnes `Assiduités` : Lorsque vous arrivez sur la page, une seule
|
||||
colonne d'assiduité est présente.
|
||||
|
||||
- La colonne `Noms` : Vous y retrouverez tous les étudiants du groupe sélectionné. En cliquant sur le titre de la colonne vous pourrez changer l'ordre des étudiants (croissant ou décroissant)
|
||||
- Les colonnes `Assiduités` : Lorsque vous arrivez sur la page, une seule colonne d'assiduité est présente.
|
||||
|
||||
Si vous avez besoins d'autres colonnes, appuyer sur le bouton `+`.
|
||||
|
||||
Si vous souhaitez supprimer une colonne appuyer sur la `croix X` de la colonne.
|
||||
Si vous souhaitez supprimer une colonne appuyer sur la `croix X` de la
|
||||
colonne.
|
||||
|
||||
Il vous faudra remplir la colonne afin de pouvoir saisir l'assiduité des étudiants :
|
||||
Il vous faudra remplir la colonne afin de pouvoir saisir l'assiduité des
|
||||
étudiants :
|
||||
|
||||
1. La date de début : Sur la première colonne, la date par défaut sera la date du jour, sur les nouvelles colonnes, la date par défaut sera la date de fin de la colonne précédente.
|
||||
2. La date de fin : La date de fin n'est pas renseignée par défaut, cependant la première fois que vous changer la date de début de la colonne, la date de fin sera automatiquement mise à jour de façon à prendre la taille d'un créneau classique (configuration du semestre/département).
|
||||
3. Le module concerné par l'assiduité. Ce sélecteur n'est pas obligatoire par défaut (configuration du semestre/département).
|
||||
4. `Sélectionner une assiduité` permet de mettre tous les étudiants à un certain état. Ce sélecteur n'est pas obligatoire.
|
||||
1. La date de début : Sur la première colonne, la date par défaut sera la
|
||||
date du jour, sur les nouvelles colonnes, la date par défaut sera la date
|
||||
de fin de la colonne précédente.
|
||||
2. La date de fin : La date de fin n'est pas renseignée par défaut,
|
||||
cependant la première fois que vous changer la date de début de la
|
||||
colonne, la date de fin sera automatiquement mise à jour de façon à
|
||||
prendre la taille d'un créneau classique (configuration du
|
||||
semestre/département).
|
||||
3. Le module concerné par l'assiduité. Ce sélecteur n'est pas obligatoire
|
||||
par défaut (configuration du semestre/département).
|
||||
4. `Sélectionner une assiduité` permet de mettre tous les étudiants à un
|
||||
certain état. Ce sélecteur n'est pas obligatoire.
|
||||
|
||||
- Chaque ligne du tableau correspond à un étudiant. Vous pouvez alors sélectionner l'état de l'assiduité de chaque étudiant pour chaque colonne.
|
||||
- Chaque ligne du tableau correspond à un étudiant. Vous pouvez alors
|
||||
sélectionner l'état de l'assiduité de chaque étudiant pour chaque colonne.
|
||||
|
||||
Après avoir rempli le tableau il faudra valider en cliquant sur `valider les assiduités`.
|
||||
|
||||
Après validation, toutes les colonnes seront désactivées, si besoins vous pouvez les réactiver en cliquant sur `Activer` pour chaque colonne.
|
||||
Après validation, toutes les colonnes seront désactivées, si besoins vous pouvez
|
||||
les réactiver en cliquant sur `Activer` pour chaque colonne.
|
||||
|
||||
Il est possible que des erreurs apparaissent. Les erreurs sont gérées par colonnes puis par étudiant. Cela signifie qu'une erreur de colonne (ex: une mauvaise date) désactivera complètement la colonne alors qu'une erreur d'étudiant (ex: l'étudiant possède déjà une assiduité sur cette période) désactivera uniquement l'envoie de l'assiduité le concernant.
|
||||
Il est possible que des erreurs apparaissent. Les erreurs sont gérées par
|
||||
colonnes puis par étudiant. Cela signifie qu'une erreur de colonne (ex: une
|
||||
mauvaise date) désactivera complètement la colonne alors qu'une erreur
|
||||
d'étudiant (ex: l'étudiant possède déjà une assiduité sur cette période)
|
||||
désactivera uniquement l'envoie de l'assiduité le concernant.
|
||||
|
||||
Vous pouvez obtenir plus d'informations sur l'erreur en plaçant votre souris au dessus du `ℹ️`.
|
||||
|
||||
Il est possible de forcer la mise à jour des assiduités : **Attention, cela ne fonctionnera que pour les assiduités ayant exactement la même période**
|
||||
(Cela a été mis en place pour facilement corriger les oubli de module)
|
||||
Il est possible de forcer la mise à jour des assiduités : **Attention, cela ne
|
||||
fonctionnera que pour les assiduités ayant exactement la même période** (ceci
|
||||
permet de corriger facilement les saisies où l'on aurait oublié d'indiquer le
|
||||
module).
|
||||
|
||||
Chaque colonne possède un numéro distinctif qui est visible en laissant la souris au dessus de l'entête de la colonne. Ce numéro est utilisé dans les messages d'erreurs.
|
||||
Chaque colonne possède un numéro distinctif qui est visible en laissant la
|
||||
souris au dessus de l'entête de la colonne. Ce numéro est utilisé dans les
|
||||
messages d'erreurs.
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Migration des absences vers les assiduités](AssiduitesMigration.md)
|
||||
- [API](ScoDoc9API.md) : API pour interfaçage avec d'autres applications
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
||||
|
|
|
@ -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)
|
47
docs/BUT.md
47
docs/BUT.md
|
@ -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"
|
||||
|
||||
|
|
|
@ -199,7 +199,8 @@ Dans chaque module, on peut régler les inscriptions:
|
|||
|
||||
- [Le BUT: détails et calculs](BUT.md)
|
||||
- [Guide du responsable de formation](GuideAdminFormation/md)
|
||||
- [Édition des programmes de formation](VersionProgrammes.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)
|
||||
|
|
|
@ -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)
|
|
@ -1,6 +1,8 @@
|
|||
# Capitalisation des UEs de DUT
|
||||
|
||||
Brève note expliquant le système de capitalisation de UE dans le cadre des DUT.
|
||||
Pour le Bachelor (BUT), voir [Capitalisation des Unités d'Enseignement en
|
||||
BUT](BUTCapitalisationUE.md).
|
||||
|
||||
## Principe
|
||||
|
||||
|
|
|
@ -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`).
|
||||
|
|
|
@ -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
|
||||
|
|
@ -0,0 +1,396 @@
|
|||
# Utilisation de git pour ScoDoc
|
||||
|
||||
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é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://scodoc.org/git/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://scodoc.org/git/viennet/ScoDoc.git
|
||||
git remote -v
|
||||
mon_origin https://xxx.xxx (fetch)
|
||||
mon_origin https://xxx.xxx (push)
|
||||
origin https://scodoc.org/git/viennet/ScoDoc.git (fetch)
|
||||
origin https://scodoc.org/git/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://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 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 [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.
|
|
@ -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:
|
||||
- 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:
|
||||
- l'ORM [SQLAlchemy](https://www.sqlalchemy.org/)
|
||||
- les templates [Jinja2](https://jinja.palletsprojects.com/en/3.0.x/)
|
||||
- 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.
|
||||
|
||||
|
||||
## Principaux objets
|
||||
|
||||
Les objets manipulés par ScoDoc sont pour la plupart stockés en base postgres et
|
||||
|
@ -27,19 +27,19 @@ 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
|
||||
- É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.
|
||||
- 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
|
||||
|
||||
|
@ -177,7 +177,7 @@ lancer flask (plus rapide).
|
|||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Informations pour les développeurs](Internals.md)
|
||||
- [Guide développeurs](GuideDeveloppeurs.md)
|
||||
- [API ScoDoc 9](ScoDoc9API.md)
|
||||
- [Modélisation du BUT](ModelisationParcoursBUT.md)
|
||||
- [Contacts](Contact.md)
|
|
@ -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.
|
|
@ -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,78 @@ 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).
|
||||
|
||||
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)).
|
||||
|
||||
*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,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,7 +55,7 @@ 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)
|
||||
|
|
|
@ -31,8 +31,7 @@ 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
|
||||
|
||||
|
||||
|
|
|
@ -1,5 +1,4 @@
|
|||
|
||||
# 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).
|
||||
|
@ -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
|
||||
|
|
|
@ -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://scodoc.org/git).
|
||||
|
||||
## 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,392 +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
|
||||
```
|
||||
|
||||
#### Autre exemple pour les développeurs
|
||||
|
||||
Vous travaillez sur un clone du dépôt principal ("origin"), obtenu par exemple via
|
||||
|
||||
```bash
|
||||
git clone https://scodoc.org/git/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://scodoc.org/git/viennet/ScoDoc.git
|
||||
git remote -v
|
||||
mon_origin https://xxx.xxx (fetch)
|
||||
mon_origin https://xxx.xxx (push)
|
||||
origin https://scodoc.org/git/viennet/ScoDoc.git (fetch)
|
||||
origin https://scodoc.org/git/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)
|
||||
|
||||
#### 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
|
||||
|
||||
|
@ -514,6 +138,10 @@ Note: la mise à jour par `apt` recrée le virtualenv à chaque fois.
|
|||
|
||||
|
||||
!!! note "Voir aussi"
|
||||
|
||||
|
||||
- [API ScoDoc 9](ScoDoc9API.md)
|
||||
- [Guide installation](GuideInstallDebian11.md)
|
||||
- [Gestion des utilisateurs](AdminUsers.md)
|
||||
- [Guide administrateur ScoDoc](GuideAdminSys.md)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
|
@ -109,7 +109,7 @@ Checklist minimale de votre système Linux Debian:
|
|||
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 !
|
||||
|
@ -228,8 +228,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
|
||||
|
|
|
@ -11,7 +11,7 @@ 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)
|
||||
|
@ -40,7 +40,7 @@ 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
|
||||
|
||||
|
|
|
@ -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,47 +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)
|
||||
- import données admission (depuis fichier Excel)
|
||||
|
||||
Listes Apogée presques complètes, faire l'import depuis le portail fin juillet,
|
||||
puis synchros courant septembre. Voir [SynchroApogee](SynchroApogee.md)
|
||||
|
||||
* nouveaux etudiants, modifs données personnelles
|
||||
|
||||
* import données admission (depuis fichier Excel)
|
||||
|
||||
|
||||
## Réinscriptions
|
||||
## 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)
|
||||
octobre. Voir [TransitionSemestre](TransitionSemestre.md).
|
||||
|
||||
|
|
|
@ -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,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)
|
||||
|
|
|
@ -1,27 +1,33 @@
|
|||
<!-- markdownlint-disable MD041 MD040 MD033 MD051 -->
|
||||
## API pour ScoDoc 9
|
||||
# API pour ScoDoc 9
|
||||
|
||||
L'API ScoDoc permet à des applications tierces d'interroger ScoDoc. Elle offre un accès aux informations aux formats XML et JSON.
|
||||
L'API ScoDoc permet à des applications tierces d'interroger ScoDoc. Elle offre
|
||||
un accès aux informations aux formats XML et JSON.
|
||||
|
||||
Les composants internes de ScoDoc, et notamment le schéma de la base de données,
|
||||
sont susceptibles d'évoluer à tout moment sans préavis: il est vivement
|
||||
déconseillé d'écrire une extension ne passant pas par l'API. Vous ne devez même
|
||||
pas supposer qu'il existe une base de données SQL.
|
||||
|
||||
La version ScoDoc 9 a introduit une nouvelle API avec un nouveau mécanisme d'authentification.
|
||||
**Les clients de l'ancienne API ScoDoc 7 doivent être adaptés pour fonctionner avec ScoDoc 9.**
|
||||
|
||||
Cette API est encore incomplète: n'hésitez pas à demander de nouveaux accès en
|
||||
écrivant à la liste de diffusion, ou sur le canal `#API` du Discord développeurs.
|
||||
Cette API est encore incomplète: n'hésitez pas à demander de nouveaux accès ([contacts](Contact.md))
|
||||
(et canal `#API` du Discord développeurs si vous y avez accès).
|
||||
|
||||
L'API fournit des données JSON, sauf exception (bulletins PDF par exemple).
|
||||
|
||||
Les objets ScoDoc manipulables sont identifiés par des id numériques.
|
||||
|
||||
* etudid: étudiant
|
||||
* formation_id: un programme de formation (page "programmes");
|
||||
* ue_id: une UE dans un programme;
|
||||
* matiere_id: une matière dans un programme;
|
||||
* module_id: un module dans un programme;
|
||||
* moduleimpl_id: un module réalisé dans un semestre;
|
||||
* formsemestre_id: un "semestre" de formation.
|
||||
- `etudid` : étudiant
|
||||
- `formation_id` : un programme de formation (page "programmes");
|
||||
- `ue_id` : une UE dans un programme;
|
||||
- `matiere_id` : une matière dans un programme;
|
||||
- `module_id` : un module dans un programme;
|
||||
- `moduleimpl_id` : un module réalisé dans un semestre;
|
||||
- `formsemestre_id` : un "semestre" de formation.
|
||||
|
||||
(pour plus de précisions, voir la [doc interne](Internals.md))
|
||||
(pour plus de précisions, voir le [guide développeurs](GuideDeveloppeurs.md))
|
||||
|
||||
L'URL complète est de la forme:
|
||||
`https://scodoc.example.com/ScoDoc/api/<fonction>`.
|
||||
|
@ -71,8 +77,8 @@ flask user-password lecteur_api
|
|||
|
||||
Si vous êtes intéressé par le développement, voir
|
||||
|
||||
* [la section sur les tests unitaires de l'API](TestsScoDoc.md#tests-de-lapi-scodoc9);
|
||||
* [la documentation interne](Internals.md#vues-de-lapi-et-permissions).
|
||||
- [la section sur les tests unitaires de l'API](TestsScoDoc.md#tests-de-lapi-scodoc9);
|
||||
- [la documentation développeurs](GuideDeveloppeurs.md) et sur les [vues de l'API](DevInternals.md#vues-de-lapi-et-permissions).
|
||||
|
||||
!!! note
|
||||
|
||||
|
@ -154,7 +160,7 @@ donnée ci-dessous dans [Référence](#reference).
|
|||
|
||||
#### Authentification
|
||||
|
||||
Lors de votre authentification (*connexion avec login et mdp*) à Scodoc, il
|
||||
Lors de votre authentification (*connexion avec login et mot de passe*) à Scodoc, il
|
||||
vous sera attribué un jeton (token jwt *généré automatiquement*) vous permettant
|
||||
d'utiliser l'api suivant les droits correspondant à votre session.
|
||||
|
||||
|
@ -201,8 +207,8 @@ par le serveur ScoDoc.
|
|||
## Règles générales
|
||||
|
||||
* une route s'écrit comme une suite de noms et d'identifiants;
|
||||
* les noms token, departement, formation, formsemestre, groupe, etudiant,
|
||||
bulletin, absence, logo, programme, évaluation, resultat, decision désignent
|
||||
* les noms token, département, formation, formsemestre, groupe, etudiant,
|
||||
bulletin, absence, logo, programme, évaluation, résultat, décision désignent
|
||||
des types d'objets;
|
||||
* les noms (verbes ou groupes verbaux): set_etudiant, remove_etudiant, query,
|
||||
create, delete, edit, order sont des actions;
|
||||
|
@ -258,7 +264,7 @@ Ce tableau est trié selon le type des informations renvoyées:
|
|||
| justificatif:IMPORT | importation de fichier justificatif | POST | [justificatif-import](#justificatif-import) | ScoJustifChange |
|
||||
| justificatif:EXPORT | exportation de fichier justificatif | POST | [justificatif-export](#justificatif-export) | ScoJustifChange |
|
||||
| justificatif:REMOVE | suppression de fichier justificatif | POST | [justificatif-remove](#justificatif-remove) | ScoJustifChange |
|
||||
| departement**`*`** | tous les depts | GET | [departements](#departements) | |
|
||||
| departement**`*`** | tous les depts | GET | [departements](#departements) | |
|
||||
| departement**`#`** | tous les ids des depts | GET | [departements-ids](#departements-ids) | ScoView |
|
||||
| departement | recherche par id | GET | [departement](#departement) | ScoView |
|
||||
| departement | recherche par acronyme | GET | [departement](#departement) | ScoView |
|
||||
|
@ -332,9 +338,9 @@ Ce tableau est trié selon le type des informations renvoyées:
|
|||
|
||||
Pour uniformiser les résultats des exemples, ceux sont soumis à quelques post-traitements non réalisés par l'API. Il n'est par exemple pas garanti que les clés des objets json sont triées:
|
||||
|
||||
* les clés sont triées
|
||||
* les listes de plus de 2 éléments sont tronquées à 2 éléments, la fin de la liste étant représentée par la notation en json '...'
|
||||
* les dates (au format ISO) sont systématiquement remplacées par une date fixe (la date de modification d'un mot de passe peut évidement être différente de sa date de création)
|
||||
- les clés sont triées
|
||||
- les listes de plus de 2 éléments sont tronquées à 2 éléments, la fin de la liste étant représentée par la notation en json '...'
|
||||
- les dates (au format ISO) sont systématiquement remplacées par une date fixe (la date de modification d'un mot de passe peut évidement être différente de sa date de création)
|
||||
|
||||
### **API Départements**
|
||||
|
||||
|
@ -351,76 +357,76 @@ Pour uniformiser les résultats des exemples, ceux sont soumis à quelques post-
|
|||
|
||||
#### **departements**
|
||||
|
||||
* **Méthode:** GET
|
||||
* **Routes:** `/departements`
|
||||
* **Exemple d'utilisation:** `/api/departements`
|
||||
* **Résultat:** Liste de tous les départements (visibles ou non).
|
||||
* **Exemple de résultat:** [departements.json](samples/sample_departements.json.md)
|
||||
- **Méthode:** GET
|
||||
- **Routes:** `/departements`
|
||||
- **Exemple d'utilisation:** `/api/departements`
|
||||
- **Résultat:** Liste de tous les départements (visibles ou non).
|
||||
- **Exemple de résultat:** [departements.json](samples/sample_departements.json.md)
|
||||
|
||||
#### **departements-ids**
|
||||
|
||||
* **Méthode:** GET
|
||||
* **Permission: `ScoView`**
|
||||
* **Routes:** `/departements_ids`
|
||||
* **Résultat:** Liste des id départements (visibles ou non).
|
||||
* **Exemple de résultat:**
|
||||
* **Exemple de résultat:** [departements-ids.json](samples/sample_departements-ids.json.md)
|
||||
- **Méthode:** GET
|
||||
- **Permission: `ScoView`**
|
||||
- **Routes:** `/departements_ids`
|
||||
- **Résultat:** Liste des id départements (visibles ou non).
|
||||
- **Exemple de résultat:**
|
||||
- **Exemple de résultat:** [departements-ids.json](samples/sample_departements-ids.json.md)
|
||||
|
||||
#### **departement**
|
||||
|
||||
* **Méthode:** GET
|
||||
* **Permission: `ScoView`**
|
||||
* **Routes:**
|
||||
* `/departement/id/<int:dept_id>`
|
||||
* `/departement/<string:dept>`
|
||||
* **Résultat:** Un département
|
||||
* **Exemple de résultat:** [departement.json](samples/sample_departement.json.md)
|
||||
- **Méthode:** GET
|
||||
- **Permission: `ScoView`**
|
||||
- **Routes:**
|
||||
- `/departement/id/<int:dept_id>`
|
||||
- `/departement/<string:dept>`
|
||||
- **Résultat:** Un département
|
||||
- **Exemple de résultat:** [departement.json](samples/sample_departement.json.md)
|
||||
|
||||
#### **`departement-create`**
|
||||
|
||||
* **Méthode: POST**
|
||||
* **Permission: `ScoSuperAdmin`**
|
||||
* **Paramètres:** aucun
|
||||
* **Data:** `{ "acronym": str, "visible":bool }`
|
||||
* **Routes:** `/departement/create`
|
||||
* **Exemple d'utilisation:** `/departement/create`
|
||||
- **Méthode: POST**
|
||||
- **Permission: `ScoSuperAdmin`**
|
||||
- **Paramètres:** aucun
|
||||
- **Data:** `{ "acronym": str, "visible":bool }`
|
||||
- **Routes:** `/departement/create`
|
||||
- **Exemple d'utilisation:** `/departement/create`
|
||||
|
||||
>`{ "acronym": "QLIO", "visible": true }`
|
||||
|
||||
* **Résultat:** Crée un nouveau département. L'acronyme du département (RT,
|
||||
- **Résultat:** Crée un nouveau département. L'acronyme du département (RT,
|
||||
GEII, ...) doit être unique (il est d'usage de le mettre en majuscules, mais
|
||||
ce n'est pas obligatoire). Le paramètre optionnel `visible`indique si le
|
||||
département est affiché sur la page d'accueil de ScoDoc. Notez qu'un
|
||||
département "invisible" peut quand même être utilisé si l'on connait son
|
||||
adresse (URL). Renvoie le département créé.
|
||||
* **Exemple de résultat:** [departements-create.json](samples/sample_departement-create.json.md)
|
||||
- **Exemple de résultat:** [departements-create.json](samples/sample_departement-create.json.md)
|
||||
|
||||
#### **`departement-edit`**
|
||||
|
||||
* **Méthode: POST**
|
||||
* **Permission: `ScoSuperAdmin`**
|
||||
* **Paramètres:** `dept_acronym`
|
||||
* **Data:** `{ "visible":bool }`
|
||||
* **Routes:** `/departement/<string:dept_acronym>/edit`
|
||||
* **Exemple d'utilisation:** `/departement/edit`
|
||||
- **Méthode: POST**
|
||||
- **Permission: `ScoSuperAdmin`**
|
||||
- **Paramètres:** `dept_acronym`
|
||||
- **Data:** `{ "visible":bool }`
|
||||
- **Routes:** `/departement/<string:dept_acronym>/edit`
|
||||
- **Exemple d'utilisation:** `/departement/edit`
|
||||
|
||||
>`{ "visible": false }`
|
||||
|
||||
* **Résultat:** Modifie un département. Seul le champs `visible` peut être
|
||||
- **Résultat:** Modifie un département. Seul le champs `visible` peut être
|
||||
modifié. L'acronyme ne peut pas être changé car il peut être mentionné dans de
|
||||
nombreux objets et documents, y compris à l'extérieur de ScoDoc.
|
||||
* **Exemple de résultat:** [departements-edit.json](samples/sample_departement-edit.json.md)
|
||||
- **Exemple de résultat:** [departements-edit.json](samples/sample_departement-edit.json.md)
|
||||
|
||||
#### **`departement-delete`**
|
||||
|
||||
* **Méthode: POST**
|
||||
* **Permission: `ScoSuperAdmin`**
|
||||
* **Paramètres:** `dept_acronym`
|
||||
* **Routes:** `/departement/<string:dept_acronym>/delete`
|
||||
* **Exemple d'utilisation:** `/departement/delete/EARTH`
|
||||
* **Résultat:** supprime définitivement un département. *Toutes les données sont effacées*
|
||||
- **Méthode: POST**
|
||||
- **Permission: `ScoSuperAdmin`**
|
||||
- **Paramètres:** `dept_acronym`
|
||||
- **Routes:** `/departement/<string:dept_acronym>/delete`
|
||||
- **Exemple d'utilisation:** `/departement/delete/EARTH`
|
||||
- **Résultat:** supprime définitivement un département. *Toutes les données sont effacées*
|
||||
(étudiants, formations, ...).
|
||||
* **Exemple de résultat:** [departements-delete.json](samples/sample_departement-delete.json.md)
|
||||
- **Exemple de résultat:** [departements-delete.json](samples/sample_departement-delete.json.md)
|
||||
|
||||
### **API Etudiant**
|
||||
|
||||
|
@ -1210,7 +1216,7 @@ version est `short_mat`ou `long_mat`, il sera structuré en
|
|||
|
||||
#### **etudiant-formsemestre-bulletin**
|
||||
|
||||
Récapitulatif par étudiant (état, groupe(s), moyennes d'UEs et de modules
|
||||
Récapitulatif par étudiant (état, groupe(s), moyennes d'UEs et de modules)
|
||||
pour un formsemestre spécifié par son id.
|
||||
Par défaut les valeurs numériques sont formatées en chaînes. Si format=raw, valeurs numériques
|
||||
mais pas JSON compliant à cause des `NaN`.
|
||||
|
@ -1260,9 +1266,9 @@ mais pas JSON compliant à cause des `NaN`.
|
|||
* **Exemple d'utilisation:** `/ScoDoc/api/formsemestre/1/programme`
|
||||
* **Résultat:** Retourne la structure d'un formsemestre sous 5 entrées d'un dictionnaire:
|
||||
|
||||
* **`ues`**: liste des UEs,
|
||||
* **`ressources`**: liste des ressources (BUT),
|
||||
* **`saes`**: liste des saes (BUT),
|
||||
* **`ues`**: liste des UEs
|
||||
* **`ressources`**: liste des ressources (BUT)
|
||||
* **`saes`**: liste des SAÉs (BUT)
|
||||
* **`modules`**: liste des modules classiques (DUT ou sport/culture)
|
||||
* **`malus`**: listes des modules de type bonus/malus.
|
||||
|
||||
|
@ -1278,7 +1284,7 @@ mais pas JSON compliant à cause des `NaN`.
|
|||
* **Exemple d'utilisation:** `/api/formsemestre/1/resultats`
|
||||
* **Résultat:** [formsemestre-resultats.json](samples/sample_formsemestre-resultats.json.md)
|
||||
|
||||
Récapitulatif par étudiant (état, groupe(s), moyennes d'UEs et de modules
|
||||
Récapitulatif par étudiant (état, groupe(s), moyennes d'UEs et de modules)
|
||||
pour un formsemestre spécifié par son id.
|
||||
Par défaut les valeurs numériques sont formatées en chaînes. Si format=raw,
|
||||
valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
||||
|
@ -1387,7 +1393,7 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
* **Paramètres :** Aucun
|
||||
* **Route:** `/logo/<string:nom>`
|
||||
* **Exemple d'utilisation :** `/ScoDoc/api/logo/header`
|
||||
* **Résultat :** l'image (format png ou jpg. le format retourné dépend du format sous lequel l'image a été initialement enregistrée)
|
||||
* **Résultat :** l'image (format png ou jpg; le format retourné dépend du format sous lequel l'image a été initialement enregistrée)
|
||||
* **Exemple de résultat:** [logo.json](samples/sample_logo.json.md)
|
||||
|
||||
#### **`departement-logos`**
|
||||
|
@ -1425,6 +1431,9 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
* **Exemple de résultat:** [departement-logo.json](samples/sample_departement-logo.json.md)
|
||||
|
||||
### **API Assiduités**
|
||||
|
||||
Cette API est disponible à partir de ScoDoc 9.6 et remplace les absences.
|
||||
|
||||
<!-- TODO: faire les samples -->
|
||||
#### Structure Assiduité
|
||||
|
||||
|
@ -1435,7 +1444,7 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
| *moduleimpl_id* | int ou null | identifiant unique du module concerné par l'assiduité si indiqué |
|
||||
| *date_debut* | string | date ISO du début de la période d'assiduité |
|
||||
| *date_fin* | string | date ISO de la fin de la période d'assiduité |
|
||||
| *etat* | string | état de l'assiduité (present, absent, retard) |
|
||||
| *etat* | string | état de l'assiduité (présent, absent, retard) |
|
||||
| *desc* | string ou null | description de l'assiduité |
|
||||
| *user_id* | int ou null | utilisateur ayant créé l'assiduité |
|
||||
| *est_just* | boolean | l'assiduité est-elle justifiée |
|
||||
|
@ -1485,8 +1494,8 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
* **Query string:**
|
||||
* `etat` ('present','retard','absent)
|
||||
* `moduleimpl_id` (X : id du moduleimpl concerné)
|
||||
* `date_debut` (X : date format iso)
|
||||
* `date_fin` (X : date format iso)
|
||||
* `date_debut` (X : date format ISO)
|
||||
* `date_fin` (X : date format ISO)
|
||||
* `formsemestre_id` (X : id du formsemestre)
|
||||
* `est_just` (v,t,f,vrai,faux,true,false)
|
||||
* `user_id` (X : id de l'utilisateur)
|
||||
|
@ -1510,8 +1519,8 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
* **Query string:**
|
||||
* `etat` ('present','retard','absent)
|
||||
* `moduleimpl_id` (X : id du moduleimpl concerné)
|
||||
* `date_debut` (X : date format iso)
|
||||
* `date_fin` (X : date format iso)
|
||||
* `date_debut` (X : date format ISO)
|
||||
* `date_fin` (X : date format ISO)
|
||||
* `est_just` (v,t,f,vrai,faux,true,false)
|
||||
* `user_id` (X : id de l'utilisateur)
|
||||
* **Routes:**
|
||||
|
@ -1532,8 +1541,8 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
* **Query string:**
|
||||
* `etat` ('present','retard','absent)
|
||||
* `moduleimpl_id` (X : id du moduleimpl concerné)
|
||||
* `date_debut` (X : date format iso)
|
||||
* `date_fin` (X : date format iso)
|
||||
* `date_debut` (X : date format ISO)
|
||||
* `date_fin` (X : date format ISO)
|
||||
* `est_just` (v,t,f,vrai,faux,true,false)
|
||||
* `user_id` (X : id de l'utilisateur)
|
||||
* **Routes:**
|
||||
|
@ -1543,7 +1552,7 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
* `/api/assiduites/formsemestre/1/count`
|
||||
* `/api/assiduites/formsemestre/1/count/query?etat=retard`
|
||||
* `/api/assiduites/formsemestre/1/count/query?moduleimpl=1&metric=demi,journee`
|
||||
* **Résultat:** les métriques obtenu à partir des assiduitées de tous les étudiants du formsemestre correspondant aux critères sélectionnés
|
||||
* **Résultat:** les métriques obtenu à partir des assiduités de tous les étudiants du formsemestre correspondant aux critères sélectionnés
|
||||
* **Exemple de résultat:** [assiduites_formsemestre-count.json](samples/sample_assiduites_formsemestre_count.json.md)
|
||||
|
||||
#### **assiduites-group[-query]**
|
||||
|
@ -1554,8 +1563,8 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
* `etudids` **Obligatoire** (liste des etudids sous la forme `x,y,z,...`)
|
||||
* `etat` ('present','retard','absent)
|
||||
* `moduleimpl_id` (X : id du moduleimpl concerné)
|
||||
* `date_debut` (X : date format iso)
|
||||
* `date_fin` (X : date format iso)
|
||||
* `date_debut` (X : date format ISO)
|
||||
* `date_fin` (X : date format ISO)
|
||||
* `est_just` (v,t,f,vrai,faux,true,false)
|
||||
* `user_id` (X : id de l'utilisateur)
|
||||
* **Routes:**
|
||||
|
@ -1600,7 +1609,7 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
|
||||
> `[{date_debut: "2022-10-27T08:00",date_fin: "2022-10-27T10:00",etat: "absent",etudid:1}]`
|
||||
|
||||
* **Résultat:** Retourne un objet en deux partie (errors et success) contenant le retour de chaque objet donné dans la requête post.
|
||||
* **Résultat:** Retourne un objet en deux parties (errors et success) contenant le retour de chaque objet donné dans la requête POST.
|
||||
|
||||
|
||||
#### **assiduite-create**
|
||||
|
@ -1629,7 +1638,7 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
|
||||
> `[{date_debut: "2022-10-27T08:00",date_fin: "2022-10-27T10:00",etat: "absent"}]`
|
||||
|
||||
* **Résultat:** Retourne un objet en deux partie (errors et success) contenant le retour de chaque objet donné dans la requête post.
|
||||
* **Résultat:** Retourne un objet en deux parties (errors et success) contenant le retour de chaque objet donné dans la requête POST.
|
||||
* **Exemple de résultat:** [assiduite_create.json](samples/sample_assiduite_create.json.md)
|
||||
|
||||
#### **assiduite-edit**
|
||||
|
@ -1652,7 +1661,9 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
|
||||
> `{etat: "absent"}`
|
||||
|
||||
* **Résultat:** Modifie l'assiduité désignée. Renvoie une erreur si la modification rend incompatible la plage de l'assiduité par rapport aux autres assiduités du même étudiant
|
||||
* **Résultat:** Modifie l'assiduité désignée. Renvoie une erreur si la
|
||||
modification rend incompatible la plage de l'assiduité par rapport aux autres
|
||||
assiduités du même étudiant.
|
||||
* **Exemple de résultat:** [assiduite_edit.json](samples/sample_assiduite_edit.json.md)
|
||||
|
||||
#### **assiduites-edit**
|
||||
|
@ -1679,7 +1690,7 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
|
||||
> `[{etat: "absent",assiduite_id:1},{etat: "retard",moduleimpl_id:12,assiduite_id:2}]`
|
||||
|
||||
* **Résultat:** Retourne un objet en deux partie (errors et success) contenant le retour de chaque objet donné dans la requête post.
|
||||
* **Résultat:** Retourne un objet en deux parties (errors et success) contenant le retour de chaque objet donné dans la requête POST.
|
||||
|
||||
#### **assiduite-delete**
|
||||
|
||||
|
@ -1700,7 +1711,7 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
|
||||
> `[2,3,5,7]`
|
||||
|
||||
* **Résultat:** Retourne un objet en deux partie (errors et success) contenant le retour de chaque objet donné dans la requête post.
|
||||
* **Résultat:** Retourne un objet en deux parties (errors et success) contenant le retour de chaque objet donné dans la requête POST.
|
||||
* **Exemple de résultat:** [assiduite_delete.json](samples/sample_assiduite_delete.json.md)
|
||||
|
||||
#### Structure Justificatif
|
||||
|
@ -1733,8 +1744,8 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
* **Paramètres:** `etudid`
|
||||
* **Query string:**
|
||||
* `etat` ( attente, valide, non_valide, modifie)
|
||||
* `date_debut` (X : date format iso)
|
||||
* `date_fin` (X : date format iso)
|
||||
* `date_debut` (X : date format ISO)
|
||||
* `date_fin` (X : date format ISO)
|
||||
* **Routes:**
|
||||
* `/justificatifs/<int:etudid>`
|
||||
* `/justificatifs/<int:etudid>/query?etat=VALIDE`
|
||||
|
@ -1780,7 +1791,8 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
]
|
||||
```
|
||||
|
||||
* **Résultat:** Retourne un objet en deux partie (errors et success) contenant le retour de chaque objet donné dans la requête post.
|
||||
* **Résultat:** Retourne un objet en deux parties (errors et success) contenant
|
||||
le retour de chaque objet donné dans la requête POST.
|
||||
* **Exemple de résultat:** [justificatif-create.json](samples/sample_justificatif_create.json.md)
|
||||
|
||||
#### **justificatif-edit**
|
||||
|
@ -1804,7 +1816,7 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
|
||||
> `{etat: "valide"}`
|
||||
|
||||
* **Résultat:** Modifie le justificatif désignée.
|
||||
* **Résultat:** Modifie le justificatif désigné.
|
||||
* **Exemple de résultat:** [justificatif-edit.json](samples/sample_justificatif_edit.json.md)
|
||||
|
||||
#### **justificatif-delete**
|
||||
|
@ -1830,7 +1842,7 @@ valeurs numériques mais pas JSON compliant à cause des `NaN`.
|
|||
]
|
||||
```
|
||||
|
||||
* **Résultat:** Retourne un objet en deux partie (errors et success) contenant le retour de chaque objet donné dans la requête post.
|
||||
* **Résultat:** Retourne un objet en deux partie (errors et success) contenant le retour de chaque objet donné dans la requête POST.
|
||||
* **Exemple de résultat:** [justificatif-delete.json](samples/sample_justificatif_delete.json.md)
|
||||
|
||||
#### **justificatif-import**
|
||||
|
@ -1947,5 +1959,6 @@ Note:
|
|||
|
||||
- [Guide configuration et ligne de commande](GuideConfig.md)
|
||||
- [Guide administrateur ScoDoc](GuideAdminSys.md)
|
||||
- [ServicesXml](ServicesXml.md) : anciens web services XML (obsolète)
|
||||
- [FAQ](FAQ.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)
|
|
@ -1,71 +1,142 @@
|
|||
# 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 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.
|
||||
|
||||
Voir aussi le [Guide pour la cheffe ou le chef de département](GuideAdminFormation.md).
|
||||
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).
|
||||
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)
|
||||
|
||||
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 le cursus 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.
|
||||
|
||||
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.
|
||||
|
||||
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) 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.
|
||||
|
||||
5. Réunir la commission (ou le jury):
|
||||
|
||||
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*.
|
||||
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*.
|
||||
|
||||
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*).
|
||||
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*).
|
||||
|
||||
6. Édition du procès-verbal: menu *Jury / Voir les décisions du jury*.
|
||||
|
||||
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).
|
||||
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).
|
||||
|
||||
2. Le lien *PV officiel (pdf)* permet de générer le procès verbal avec la liste des décisions pour chaque étudiant.
|
||||
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 ce stade, le semestre est terminé. Il est recommandé de le **verrouiller** après les prises de décisions définitives.
|
||||
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.
|
||||
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* **.
|
||||
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 !)
|
||||
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.
|
||||
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).
|
||||
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 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.
|
||||
|
||||
- **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)
|
||||
- [FAQ](FAQ.md)
|
||||
- [Contacts](Contact.md)
|
|
@ -0,0 +1,171 @@
|
|||
# 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.
|
||||
|
||||
## 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`.
|
||||
|
||||
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
|
||||
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 stop scodoc9
|
||||
```
|
||||
|
||||
## En cas de problème avec proxmox
|
||||
|
||||
Pour l'instant on ne nous a pas signalé de problèmes, mais 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)
|
||||
|
||||
## 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
|
||||
service postgresql stop
|
||||
pg_dropcluster --stop 15 main
|
||||
pg_upgradecluster -m upgrade 13 main
|
||||
systemctl start postgresql
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
## Passage de ScoDoc 9.5 (ou 9.4) à 9.6
|
||||
|
||||
### Modification des sources de paquets Debian
|
||||
|
||||
- Supprimer l'ancien fichier:
|
||||
|
||||
```bash
|
||||
rm /etc/apt/sources.list.d/scodoc*
|
||||
```
|
||||
|
||||
- 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 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
|
||||
```
|
||||
|
||||
### Mise à jour du paquet scodoc9
|
||||
|
||||
```bash
|
||||
apt update && apt upgrade
|
||||
```
|
||||
|
||||
devrait installer `scodoc9.6.x`.
|
||||
|
||||
### 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é !
|
||||
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 dizaines de minutes,
|
||||
suivant le nombre d'absences et la vitesse de votre serveur.
|
||||
|
||||
### Démarrage du service
|
||||
|
||||
Comme d'habitude, en tant que `root`:
|
||||
```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)
|
|
@ -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.
After Width: | Height: | Size: 275 KiB |
Binary file not shown.
After Width: | Height: | Size: 203 KiB |
Before Width: | Height: | Size: 70 KiB After Width: | Height: | Size: 70 KiB |
Before Width: | Height: | Size: 88 KiB After Width: | Height: | Size: 88 KiB |
33
mkdocs.yml
33
mkdocs.yml
|
@ -22,18 +22,34 @@ plugins:
|
|||
- inline-svg
|
||||
|
||||
nav:
|
||||
- Accueil: index.md
|
||||
- Accueil:
|
||||
- "Accueil": index.md
|
||||
- "Documentation": GuideUtilisateur.md
|
||||
- "Installation": GuideAdminSys.md
|
||||
- "Association": AssociationScoDoc.md
|
||||
- "Développement": GuideDeveloppeurs.md
|
||||
|
||||
- Documentation:
|
||||
- "Guide utilisateur": GuideUtilisateur.md
|
||||
- "Tutos vidéos": https://www.youtube.com/playlist?list=PLw49h6RbvswhasBk9bXj7PzOD8GDW3kG1
|
||||
- "Responsables de formations": GuideAdminFormation.md
|
||||
- "Responsables de formations":
|
||||
- "Guide": GuideAdminFormation.md
|
||||
- "Programmes de formations": Formations.md
|
||||
- "Capitalisation des UEs": CapitalisationUE.md
|
||||
- "Inscription Apogée": InscriptionsEtudApogee.md
|
||||
- "Synchro Apogée": SynchroApogee.md
|
||||
- "Importation d'étudiants": ImportationEtuds.md
|
||||
- "Fin de semestre": TransitionSemestre.md
|
||||
|
||||
- "Le BUT":
|
||||
- "Introduction": BUT.md
|
||||
- "Exemple complet": BUTExempleInfo.md
|
||||
- "Capitalisation UEs": BUTCapitalisationUE.md
|
||||
- "Relations entreprises": RelationsEntreprises.md
|
||||
- "Développeurs":
|
||||
- "Guide": GuideDeveloppeurs.md
|
||||
- "Git": DevGit.md
|
||||
- "FAQ": FAQ.md
|
||||
|
||||
- Installation:
|
||||
- "Guide administration": GuideAdminSys.md
|
||||
- "Installation": GuideInstallDebian11.md
|
||||
|
@ -41,16 +57,17 @@ nav:
|
|||
- "Interfaces SI": InterrogationPortail.md
|
||||
- "Publication des notes": PublicationEtudiants.md
|
||||
- "Export Apogée": ScoDocApogee.md
|
||||
|
||||
- Association:
|
||||
- "Association 1901": AssociationScoDoc.md
|
||||
- "Utilisateurs": UtilisateursScoDoc.md
|
||||
|
||||
- Développement:
|
||||
- "Git": https://scodoc.org/git
|
||||
- "Guide Développeurs": GuideDeveloppeurs.md
|
||||
- "API (interfaçages autres logiciels)": ScoDoc9API.md
|
||||
|
||||
- "Gitea": https://scodoc.org/git
|
||||
- "API": ScoDoc9API.md
|
||||
- "Introduction": DevInternals.md
|
||||
- "Utiliser Git": DevGit.md
|
||||
- "Config serveur dev.": ConseilServeurDev.md
|
||||
- "Tests unitaires": TestsScoDoc.md
|
||||
- "Contacts": Contact.md
|
||||
|
||||
# theme: readthedocs
|
||||
|
|
Loading…
Reference in New Issue