forked from ScoDoc/DocScoDoc
Reprise de plusieurs pages / structure.
This commit is contained in:
parent
7d27cf8bfa
commit
23642a9910
@ -199,7 +199,7 @@ 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)
|
||||
- [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)
|
||||
|
||||
@ -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
|
||||
|
||||
396
docs/DevGit.md
Normal file
396
docs/DevGit.md
Normal file
@ -0,0 +1,396 @@
|
||||
# Utilisation de git pour ScoDoc
|
||||
|
||||
Le dépôt est <https://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)
|
||||
220
docs/Formations.md
Normal file
220
docs/Formations.md
Normal file
@ -0,0 +1,220 @@
|
||||
# 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:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## É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="50%">
|
||||
|
||||
## 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.
|
||||
|
||||
|
||||
|
||||
!!! 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)
|
||||
@ -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.
|
||||
|
||||
|
||||
|
||||
La figure suivante montre la distinction entre formations et semestres, et les opérations possibles:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
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,24 @@
|
||||
|
||||
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)
|
||||
- [API](ScoDoc9API.md) : API 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)
|
||||
|
||||
## Développer sur ScoDoc
|
||||
|
||||
@ -60,392 +68,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 +137,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)
|
||||
@ -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)
|
||||
|
||||