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
|
||||
|
||||
|
||||
@ -8,7 +8,9 @@ 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
|
||||
|
||||
```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,21 +40,25 @@ 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
|
||||
```
|
||||
|
||||
```py
|
||||
g.scodoc_dept = "RT" # l'acronyme du dept
|
||||
g.scodoc_dept_id = 5 # l'id du dept
|
||||
```
|
||||
@ -59,9 +67,11 @@ Le décorateur suivant, `permission_required` peut ainsi vérifier que la
|
||||
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,7 +120,7 @@ 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
|
||||
`app.auth.logic.load_user_from_request()`.
|
||||
|
||||
@ -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,4 +1,4 @@
|
||||
# Quelques informations pour les développeurs
|
||||
# Développement ScoDoc: Introduction
|
||||
|
||||
## Composants logiciels
|
||||
|
||||
@ -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,7 +9,10 @@ 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:
|
||||
|
||||
@ -19,12 +24,14 @@ 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.
|
||||
|
||||
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:
|
||||
@ -41,26 +48,39 @@ Pour éviter d'inonder les utilisateurs de messages, plusieurs paramètres sont
|
||||
* 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;
|
||||
* 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)).
|
||||
|
||||
|
||||
*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).
|
||||
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).
|
||||
|
||||
### 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;
|
||||
* 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é.
|
||||
* 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
|
||||
|
||||
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.
|
||||
|
||||
La fonction "*Copier les photos du portail*" permet de copier dans ScoDoc les photos externes publiées sur le portail.
|
||||
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.
|
||||
|
||||
### 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,4 +1,3 @@
|
||||
|
||||
# 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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -515,5 +138,9 @@ 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)
|
||||
|
||||
### 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").
|
||||
|
||||
.
|
||||
|
||||
<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
|
||||
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).
|
||||
|
||||
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.
|
||||
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).
|
||||
|
||||
Note: Apogée réutilise les mêmes codes étapes pour les sessions d'années différentes, ces codes changent donc
|
||||
rarement.
|
||||
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)).
|
||||
|
||||
<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.
|
||||
Note: Apogée réutilise les mêmes codes étapes pour les sessions d'années
|
||||
différentes, ces codes changent donc rarement.
|
||||
|
||||
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:
|
||||
<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.
|
||||
|
||||
* identité (nom, prénom, civilité);
|
||||
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:
|
||||
|
||||
* adresse (et téléphone).
|
||||
|
||||
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").
|
||||
- identité (nom, prénom, civilité);
|
||||
- adresse (et téléphone).
|
||||
|
||||
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").
|
||||
|
||||
## Procédure à suivre pour le premier semestre (S1)
|
||||
|
||||
Listes Apogée presques complètes, faire l'import depuis le portail fin juillet,
|
||||
puis synchros courant septembre. Voir [SynchroApogee](SynchroApogee.md)
|
||||
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 etudiants, modifs données personnelles
|
||||
|
||||
* import données admission (depuis fichier Excel)
|
||||
- nouveaux étudiants, modification données personnelles
|
||||
|
||||
- import données admission (depuis fichier Excel)
|
||||
|
||||
## 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
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
(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,26 +1,32 @@
|
||||
# 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>`.
|
||||
@ -70,8 +76,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
|
||||
|
||||
@ -1447,5 +1453,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
|
||||
les étudiants peuvent être identifiés au choix par l'un des trois codes:
|
||||
|
||||
- **`etudid`** : code interne ScoDoc, toujours disponible.
|
||||
Les étudiants peuvent être identifiés au choix par l'un des trois codes:
|
||||
|
||||
- **`code_ine`** : code INE Apogée, s'il a été renseigné
|
||||
* **`etudid`** : code interne ScoDoc, toujours disponible.
|
||||
|
||||
- **`code_nip`** : code NIP 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é
|
||||
|
||||
## 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:
|
||||
```
|
||||
|
||||
```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" />
|
||||
@ -34,7 +41,7 @@ les étudiants peuvent être identifiés au choix par l'un des trois codes:
|
||||
* Paramètres: `partition_id=X`
|
||||
* Donne la liste des étudiants dans un semestre, par groupes.
|
||||
* Exemple:
|
||||
```
|
||||
```xml
|
||||
<ajax-response>
|
||||
<response type="object" id="MyUpdater">
|
||||
|
||||
@ -57,7 +64,7 @@ les étudiants peuvent être identifiés au choix par l'un des trois codes:
|
||||
* `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.
|
||||
* 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)
|
||||
* 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`).
|
||||
* 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 ...>
|
||||
@ -142,10 +153,13 @@ 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)
|
||||
* 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=""/>
|
||||
@ -157,10 +171,14 @@ Le bulletin comporte aussi le décompte des absences enregistrées au cours de c
|
||||
* 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).
|
||||
* 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).
|
||||
|
||||
.
|
||||
|
||||
<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.
|
||||
|
||||
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).
|
||||
|
||||
|
||||
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)
|
||||
@ -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.
|
||||
|
||||
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*.
|
||||
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).
|
||||
|
||||
<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**.
|
||||
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**.
|
||||
|
||||
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:
|
||||
!!! note "Voir aussi"
|
||||
|
||||
- [Synchroniser avec une étape Apogée](SynchroApogee.md)
|
||||
- [Guide pour le chef de département](GuideAdminFormation.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)
|
||||
BIN
docs/screens/formsemestre_associate_new_version.png
Normal file
BIN
docs/screens/formsemestre_associate_new_version.png
Normal file
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
Block a user