Reprise de plusieurs pages / structure.

This commit is contained in:
Emmanuel Viennet 2023-06-09 15:45:16 +02:00
parent 7d27cf8bfa
commit 23642a9910
28 changed files with 1179 additions and 905 deletions

View File

@ -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)

View File

@ -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

View File

@ -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()`.

View File

@ -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
View 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.

View File

@ -1,16 +1,16 @@
# Quelques informations pour les développeurs
# Développement ScoDoc: Introduction
## Composants logiciels
- le code est écrit en Python 3.9 (passage à 3.10 prévu avec Debian 12).
- le code doit être formatté par [black](https://pypi.org/project/black/) qui
est normalement intégré à votre éditeur (VSCode et PyCharm sont deux choix
judicieux).
- outre Python, les principaux composants logiciels sont:
- le code est écrit en Python 3.9 (passage à 3.10 prévu avec Debian 12).
- le code doit être formatté par [black](https://pypi.org/project/black/) qui
est normalement intégré à votre éditeur (VSCode et PyCharm sont deux choix
judicieux).
- outre Python, les principaux composants logiciels sont:
- [Flask](https://flask-sqlalchemy.palletsprojects.com/en/2.x/): le
framework Web, dont on utilise notamment:
- l'ORM [SQLAlchemy](https://www.sqlalchemy.org/)
- les templates [Jinja2](https://jinja.palletsprojects.com/en/3.0.x/)
- l'ORM [SQLAlchemy](https://www.sqlalchemy.org/)
- les templates [Jinja2](https://jinja.palletsprojects.com/en/3.0.x/)
- [Postgresql](https://www.postgresql.org/)
- [Redis](https://redis.io/) cache persistant
- [NGINX](https://www.nginx.com/) serveur Web frontal
@ -27,19 +27,19 @@ Les modèles correspondant sont déclarés dans `/opt/scodoc/app/models/`.
Principales classes (les noms des classes Python sont en `CamelCase`).
- Étudiants (classe `Identite`): nom, codes INE/NIP, etc
- Formations: programmes pédagogiques, contenant
- Étudiants (classe `Identite`): nom, codes INE/NIP, etc
- Formations: programmes pédagogiques, contenant
- Unités d'Enseignement (`UniteEns`);
- Matières et Modules (`Module`, avec son type standard, bonus, ressources
ou SAÉ).
- FormSemestre: instanciation d'une session de formation, avec un programme
pédagogique donné (Formation), les dates de début et fin, des étudiants
inscrits, des responsables, divers codes, et les ModuleImpl mis en œuvre.
- ModuleImpl: la mise en place d'un module pédagogique (le ModuleImpl est au
Module ce que le FormSemestre est à la Formation): lié à un module, avec un
enseignant responsable et des étudiants inscrits.
- Inscriptions: tables d'association avec codes et/ou état (démission,
défaillant): FormsemestreInscription ModuleImplInscription.
- FormSemestre: instanciation d'une session de formation, avec un programme
pédagogique donné (Formation), les dates de début et fin, des étudiants
inscrits, des responsables, divers codes, et les ModuleImpl mis en œuvre.
- ModuleImpl: la mise en place d'un module pédagogique (le ModuleImpl est au
Module ce que le FormSemestre est à la Formation): lié à un module, avec un
enseignant responsable et des étudiants inscrits.
- Inscriptions: tables d'association avec codes et/ou état (démission,
défaillant): FormsemestreInscription ModuleImplInscription.
## Vues et décorateurs
@ -177,7 +177,7 @@ lancer flask (plus rapide).
!!! note "Voir aussi"
- [Informations pour les développeurs](Internals.md)
- [Guide développeurs](GuideDeveloppeurs.md)
- [API ScoDoc 9](ScoDoc9API.md)
- [Modélisation du BUT](ModelisationParcoursBUT.md)
- [Contacts](Contact.md)

220
docs/Formations.md Normal file
View 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:
![menu formsemestre](fig/formations_versions_association.jpg)
![association nouvelle version](fig/sem-assoc-formation.png)
## Évolution du programme d'une année sur l'autre
Imaginons que nous ayons les semestres S1, S2, S3, S4 dans un programme V1, et
que l'année suivante une nouvelle version du programme entre en vigueur
(adaptation locale, corrections diverses...).
Voici comment mettre en place les semestres de l'année suivante tout en
conservant le maximum d'éléments (évaluation, choix des ressources et SAE).
1. Cloner (menu **Semestre / Cloner**)les semestres concernés (S1 à S4 ici)
2. Prendre l'un des semestres copiés (peu importe laquelle), et suivre
**Semestre / Associer à une nouvelle version**. Il est alors possible d'associer
à cette nouvelle version (V2) les semestres: cochez les semestres créés à
l'étape précédente.
Cette façon de procéder permet de limiter le nombre de nouvelles versions de
formations créée.
<img src="/screens/formsemestre_associate_new_version.png" width="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.
![change formation](fig/sem-change-formation.png)
!!! 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)

View File

@ -1,5 +1,7 @@
# Suivi des absences (version <= 9.4)
## Suivi des absences
**Cette page se réfère l'ancien système de gestion des absences, remplacé en
juillet 2023 (ScoDoc 9.5) par le nouveau module Assiduité.**
ScoDoc permet d'enregistrer les absences des étudiants.
@ -7,60 +9,78 @@ Les absences sont notées par demi-journées (matin ou après midi).
Elles peuvent être "justifiées" ou non.
Dans les pages concernant un étudiant, un cadre en bas à gauche permet de visualiser le compte d'absences (comptées en demi-journées) et de les visualiser sur un calendrier de l'année scolaire. On peut simplement ajouter, justifier ou supprimer une absence pour un étudiant.
Dans les pages concernant un étudiant, un cadre en bas à gauche permet de
visualiser le compte d'absences (comptées en demi-journées) et de les visualiser
sur un calendrier de l'année scolaire. On peut simplement ajouter, justifier ou
supprimer une absence pour un étudiant.
Une absence:
* correspond à une demi-journée durant laquelle l'étudiant a été noté absent;
* peut être signalée plusieurs fois (ScoDoc ne la comptera qu'une fois).
* correspond à une demi-journée durant laquelle l'étudiant a été noté absent;
* peut être signalée plusieurs fois (ScoDoc ne la comptera qu'une fois).
Un justificatif:
* permet de signaler que l'absence est "excusée" (certificat médical...);
* peut être saisi à n'importe quel moment, avant ou après le signalement de l'absence.
* permet de signaler que l'absence est "excusée" (certificat médical...);
* peut être saisi à n'importe quel moment, avant ou après le signalement de l'absence.
Les absences peuvent aussi être saisies pour tout un groupe d'étudiants via un formulaire adapté (voir le menu "Saisir absences" sur le tableau de bord du semestre).
Les absences peuvent aussi être saisies pour tout un groupe d'étudiants via un
formulaire adapté (voir le menu "Saisir absences" sur le tableau de bord du
semestre).
Le compte des absences peut ou non figurer sur les bulletins de notes, suivant les réglages choisis (voir le menu "Préférences du semestre").
Le compte des absences peut ou non figurer sur les bulletins de notes, suivant
les réglages choisis (voir le menu "Préférences du semestre").
### Notification par mail des absences
## Notification par mail des absences
ScoDoc peut prévenir par email lorsqu'un étudiant a "trop d'absences".
Peuvent être prévenus:
* le chef du département;
* le responsable du semestre concerné (direction des études en IUT);
* une autre adresse indiquée dans les paramètres (cela peut être une liste de diffusion, par exemple);
* le responsable du module concerné par une évaluation dans laquelle un étudiant est signalé absent (voir plus bas).
* le chef du département;
* le responsable du semestre concerné (direction des études en IUT);
* une autre adresse indiquée dans les paramètres (cela peut être une liste de diffusion, par exemple);
* le responsable du module concerné par une évaluation dans laquelle un étudiant est signalé absent (voir plus bas).
Pour éviter d'inonder les utilisateurs de messages, plusieurs paramètres sont réglables:
* notifier les absences au chef (oui/non);
* notifier les absences au dir. des études (oui/non);
* notifier les absences aux resp. de modules (oui/non);
* notifier les absences aux étudiants (individuellement);
* autre adresse vers laquelle notifier;
* fréquence maximale de notification N (un utilisateur ne recevra pas plus de 1 message tous les N jours, *par étudiant*);
* seuil de première notification: nombre d'absences tolérées avant premier envoi de notification (comptées en demi-journées);
* seuil notifications suivantes: une notifications toutes les *N* absences, après le premier seuil;
* message notification e-mail (template modifiable).
* notifier les absences au chef (oui/non);
* notifier les absences au dir. des études (oui/non);
* notifier les absences aux resp. de modules (oui/non);
* notifier les absences aux étudiants (individuellement);
* autre adresse vers laquelle notifier;
* fréquence maximale de notification N (un utilisateur ne recevra pas plus de 1
message tous les N jours, *par étudiant*);
* seuil de première notification: nombre d'absences tolérées avant premier envoi
de notification (comptées en demi-journées);
* seuil notifications suivantes: une notifications toutes les *N* absences,
après le premier seuil;
* message notification e-mail (template modifiable).
Ces paramètres peuvent être spécifiés globalement ou par semestre (comme pour la plupart des paramètres ScoDoc, voir [PreferencesScoDoc](PreferencesScoDoc.md)).
Ces paramètres peuvent être spécifiés globalement ou par semestre (comme pour la
plupart des paramètres ScoDoc, voir [PreferencesScoDoc](PreferencesScoDoc.md)).
*Absences aux évaluations*: lorsqu'une absence concerne potentiellement une
évaluation, le responsable du module concerné peut être prévenu. Limitations: la
résolution temporelle de l'absence est la demi-journée, une évaluation peut être
plus courte; il appartient à l'enseignant de vérifier si l'étudiant était
réellement absent lors de son évaluation (ou si la justification d'absence
produite couvre bien sa plage horaire). Notons que ScoDoc se fonde sur la date
de l'évaluation déclarée, pas sur l'emploi du temps (qui n'est pas géré par
ScoDoc).
*Absences aux évaluations*: lorsqu'une absence concerne potentiellement une évaluation, le responsable du module concerné peut être prévenu. Limitations: la résolution temporelle de l'absence est la demi-journée, une évaluation peut être plus courte; il appartient à l'enseignant de vérifier si l'étudiant était réellement absent lors de son évaluation (ou si la justification d'absence produite couvre bien sa plage horaire). Notons que ScoDoc se fonde sur la date de l'évaluation déclarée, pas sur l'emploi du temps (qui n'est pas géré par ScoDoc).
### Billets d'absences
### Billets d'absences
Les "billets d'absences" sont issus d'une demande du département Informatique de l'IUT de Villetaneuse en 2009, et sont implémentés à titre expérimental.
Les "billets d'absences" sont issus d'une demande du département Informatique de
l'IUT de Villetaneuse en 2009, et sont implémentés à titre expérimental.
Le scénario d'utilisation est le suivant :
* l'étudiant absent remplit un formulaire web (sur le portail étudiant, donc hors ScoDoc) indiquant les dates (début et fin) de son absence et sa raison;
* ce billet rempli est alors envoyé à ScoDoc et doté d'un numéro unique ;
* il l'imprime et va au secrétariat porter cette impression du formulaire (faisant apparaitre le numéro) et le justificatif correspondant;
* le secrétariat, quand il en a le temps, rentre le numéro de la fiche d'absence et a juste une case à cocher : justifié/non justifié.
* l'étudiant absent remplit un formulaire web (sur le portail étudiant, donc
hors ScoDoc) indiquant les dates (début et fin) de son absence et sa raison;
* ce billet rempli est alors envoyé à ScoDoc et doté d'un numéro unique;
* il l'imprime et va au secrétariat porter cette impression du formulaire
(faisant apparaitre le numéro) et le justificatif correspondant;
* le secrétariat, quand il en a le temps, rentre le numéro de la fiche d'absence
et a juste une case à cocher : justifié/non justifié.
Voir détails techniques sur [ServicesXml](ServicesXml.md).

View File

@ -1,30 +1,41 @@
# Gestion des photos des étudiants
## Gestion des photos des étudiants
Une photo de chaque étudiant peut être stockée par ScoDoc. On peut aussi utiliser des photos externes (portail).
Une photo de chaque étudiant peut être stockée par ScoDoc.
## Associer une photo à l'étudiant
### Associer une photo à l'étudiant
#### Individuellement
Passer par la fiche individuelle de l'étudiant: menu "*Etudiant / Changer la photo*" et télécharger un fichier image (jpeg, gif, png...).
### Individuellement
ScoDoc réduit automatiquement la taille de la photo (actuellement pour obtenir une taille verticale de 90 pixels).
Passer par la fiche individuelle de l'étudiant: menu "*Etudiant / Changer la
photo*" et télécharger un fichier image (jpeg, gif, png...).
ScoDoc réduit automatiquement la taille de la photo (actuellement pour obtenir
une taille verticale de 90 pixels).
#### Import de plusieurs photos
Si vous n'avez pas la possibilité d'interfacer ScoDoc à un service fournissant les photos (via le service de la Scolarité de votre Université, par exemple), vous pouvez importer les photos via un fichier Zip et un fichier Excel permettant d'associer à chaque étudiant le bon fichier image.
### Import de plusieurs photos
Si vous n'avez pas la possibilité d'interfacer ScoDoc à un service fournissant
les photos (via le service de la Scolarité de votre Université, par exemple),
vous pouvez importer les photos via un fichier Zip et un fichier Excel
permettant d'associer à chaque étudiant le bon fichier image.
Le menu "Photo" de la page "Trombinoscope" offre pour cela une fonction "Charger des photos...": suivre les indications données sur la page.
Le menu "Photo" de la page "Trombinoscope" offre pour cela une fonction "Charger
des photos...": suivre les indications données sur la page.
### Afficher un trombinoscope
### Afficher un trombinoscope
Suivre le lien "*Photos*" du groupe qui vous intéresse.
Le menu en haut à droite de la page permet d'obtenir une version PDF du trombinoscope (pour impression ou distribution) et une archive zip avec tous les fichiers images.
Le menu en haut à droite de la page permet d'obtenir une version PDF du
trombinoscope (pour impression ou distribution) et une archive zip avec tous les
fichiers images.
La fonction "*Copier les photos du portail*" permet de copier dans ScoDoc les photos externes publiées sur le portail.
La fonction "*Copier les photos du portail*" permet de copier dans ScoDoc les
photos externes publiées sur le portail.
### Photos externes
### Photos externes
Lorsque ScoDoc ne possède pas de copie de la photo d'un étudiant et qu'il est configuré avec un portail, il place dans les pages un lien vers ```portal_url + '/getPhoto.php?nip=CODE_NIP```. Voir [InterrogationPortail](InterrogationPortail.md).
Lorsque ScoDoc ne possède pas de copie de la photo d'un étudiant et qu'il est
configuré avec un portail, il peut places dans les pages un lien vers
```portal_url + '/getPhoto.php?nip=CODE_NIP```. Voir
[InterrogationPortail](InterrogationPortail.md).

View File

@ -1,4 +1,3 @@
# Guide ScoDoc pour le ou la responsable de formation
Cette partie s'adresse plutôt aux responsables de formation (cheffes ou chefs de
@ -12,96 +11,7 @@ département IUT, responsable de filières, ...). Nous allons apprendre à:
## Définir un programme pédagogique
Le programme pédagogique d'une formation défini les unités d'enseignement; il
est destiné à être utilisé par plusieurs sessions de formation (semestres). On
doit apporter un soin particulier à la définition du programme, et éviter de le
modifier une fois que des semestres sont créés (il est toutefois possible d'en
créer de nouvelles *versions* pour permettre des modifications ultérieures sans
affecter les semestres achevés: voir [VersionProgrammes](VersionProgrammes.md)).
On définira en général dans le programme l'ensemble des enseignements d'un
diplôme (les 4 semestres d'un DUT par exemple). C'est dans une phase ultérieure
que l'on mettra en place les différents semestres.
Les programmes pédagogiques ScoDoc sont structurés en Unités d'Enseignements
(UE), Matières et Modules. Un module appartient forcément à une matière, qui
appartient elle même à une UE. Les modules (déclinés en *ressources*, *SAÉs* en
BUT) représentent les cours ("mathématique", "anglais", ...) et sont associés à
un volume horaire (cours/TD/TP) et à un coefficient: chaque module produit une
note moyenne (en général obtenue à travers plusieurs *évaluations* ou
contrôles). La note moyenne d'une UE est obtenue en calculant une moyenne
pondérée par les coefficients des notes moyennes de modules.
🚸 En BUT, c'est un peu différent, puisque les modules ont une note *pour chaque
UE*: la moyenne d'un module n'est pas définie. Voir [BUT](BUT.md)
Les matières n'ont pas d'autre utilité que d'aider à structurer le programme.
Par exemple, on pourrait définir dans un programme une matière "Sciences"
réunissant les modules de "mathématiques" et de "physique". Les matières n'ont
pas de coefficient. Si l'on ne souhaite pas utiliser de matière, il suffit d'en
créer une pour chaque module avec le même nom, ou au contraire (plus simplement)
de créer une matière par UE et d'y placer tous les modules.
Les UE jouent un rôle particulier dans l'évaluation. En effet, selon les règles
du LMD, les UE sont *capitalisables* (voir
[CapitalisationUE](CapitalisationUE.md)). De plus, l'obtention de droit des
semestres d'un DUT est soumise à une moyenne supérieure à 8/20 dans chacune des
UE.
Notons qu'une UE ne possède pas de coefficient. Le coefficient d'une UE n'est
autre que la somme des coefficient des modules qui composent cette UE. Par
conséquent, le coefficient d'UE est potentiellement variable d'un étudiant à
l'autre, si les étudiants ne sont pas inscrits aux mêmes modules (options ou
parcours).
Vous trouverez plus d'informations sur la définition des programmes sur la page
[VersionProgrammes](VersionProgrammes.md).
## Versions des programmes de formation
Chaque semestre ("FormSemestre" dans le jargon ScoDoc) se réfère à un programme
pédagogique, appelé sa *formation*. cette formation définit l'ensemble des UE et
modules, leurs intitulés, et leurs coefficients et ECTS.
Les programmes sont le plus souvent adaptés localement, et peuvent varier d'une
année sur l'autre. Lorsqu'une formation est modifié (par exemple, un changement
de coefficient), ScoDoc doit recalculer l'ensemble des notes de tous les
semestres utilisant cette formation. De même, si un intitulé change, il faut
re-générer les bulletins et procès-verbaux. On conçoit donc que la modification
d'une formation ne s'aborde pas à la légère. ScoDoc empêche d'ailleurs toute
modification d'une formation (ou partie de, selon les cas) lorsqu'un semestre a
été verrouillé (ce qui indique en général qu'il est achevé et que l'on souhaite
conserver ses données et résultats inchangés pour utilisation future dans des
jurys ou avis).
Si vous devez modifier une formation pour la nouvelle année scolaire, vous
pouvez créer une nouvelle version d'une formation existante afin d'éviter
d'avoir à saisir de nouveau l'ensemble des éléments. Il arrive même que, l'année
scolaire déjà commencée, on se rende compte que l'on doit modifier la formation
d'un semestre en cours (bien sûr, cela ne devrait pas arriver, les modalités
d'évaluation étant souvent votées par des instances officielles avant le début
de l'année, mais le monde n'est pas parfait et de petites corrections sont
parfois nécessaires). Dans ce cas, ScoDoc vous permet d'associer un ou plusieurs
semestres existants dans une formation à une nouvelle version de celle-ci, créée
par copie.
![menu formsemestre](fig/menu-formsemestre-assoc.png)
La figure suivante montre la distinction entre formations et semestres, et les opérations possibles:
![menu formsemestre](fig/formations_versions_association.jpg)
![association nouvelle version](fig/sem-assoc-formation.png)
### Changement de la formation d'un semestre
Il peut arriver que l'on ai créé deux versions de formations, qui sont encore
identique, et que l'on souhaite rattacher un formsemestre de l'une à l'autre.
C'est possible, à condition que les deux formations soient vraiment identiques
(mêmes UEs, titres, coefficients, etc). Le lien est accessible en bas de la page
"Associer à une nouvelle version du programme" mentionnée ci-dessus.
![change formation](fig/sem-change-formation.png)
Voir [Programmes pédagogiques et versions](Formations.md).
## Créer un semestre de formation
@ -124,6 +34,11 @@ le langage IUT).
* [Données sur scolarité antérieure et admission](DonneesAdmissions.md)
## Jurys
* [Saisie des décisions](SaisieDecisionsJury.md)
* [Gestion des commissions et jurys, édition des PV](GestionJury.md)
## Suivi de la Scolarité
* [Récapitulatif des opérations en fin de semestre et début du suivant](TransitionSemestre.md)
@ -140,7 +55,7 @@ fichiers sur la page
!!! note "Voir aussi"
- [Édition des programmes de formation](VersionProgrammes.md)
- [Programmes de formation](Formations.md)
- [Guide utilisateur](GuideUtilisateur.md)
- [Modélisation BUT: exemple complet](BUTExempleInfo.md)
- [Tutoriels vidéo](https://www.youtube.com/channel/UCb0JYCBRi0CsE4XFp4ByhXg)

View File

@ -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

View File

@ -1,5 +1,4 @@
# Prise en main et paramétrage de ScoDoc 9
# Prise en main et paramétrage de ScoDoc 9
Ce document suppose que le logiciel a été installé suivant la procédure décrite dans
[GuideInstallDebian11](GuideInstallDebian11.md).

View File

@ -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)

View File

@ -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

View File

@ -1,35 +1,52 @@
# Importation d'étudiants (cas où l'on a pas de connexion directe à Apogée)
## Importation d'étudiants (cas où l'on a pas de connexion directe à Apogée)
Les étudiants ne doivent être créés dans le système qu'une seule fois (lors de leur première inscription). Il sont ensuite suivi grâce à leur identifiant Apogée (ou à défaut leur code interne ScoDoc) qui ne varie pas. Insistons: les étudiants ne doivent être créés dans ScoDoc que lors de leur arrivée (premier semestre), ils sont ensuite suivis d'un semestre à l'autre.
Les étudiants ne doivent être créés dans le système qu'une seule fois (lors de
leur première inscription). Il sont ensuite suivi grâce à leur identifiant
Apogée (ou à défaut leur code interne ScoDoc) qui ne varie pas. Insistons: les
étudiants ne doivent être créés dans ScoDoc que lors de leur arrivée (premier
semestre), ils sont ensuite suivis d'un semestre à l'autre.
Il est possible de créer les étudiants un par un (voir [CreationEtudIndividuel](CreationEtudIndividuel.md)) mais cela
est rapidement fastidieux si l'on a plus d'une dizaine d'étudiants à inscrire. De plus, ce mode de fonctionnement tend à produire des erreurs de saisie et des doublons (le même étudiant créé deux fois dans des semestres différents, ce qui empêche le suivi de sa scolarité). Ces doublons posent de grandes difficultés et empêchent la gestion automatique des jurys: soyez vigilants lors des inscriptions.
Il est possible de créer les étudiants un par un (voir
[CreationEtudIndividuel](CreationEtudIndividuel.md)) mais cela est rapidement
fastidieux si l'on a plus d'une dizaine d'étudiants à inscrire. De plus, ce mode
de fonctionnement tend à produire des erreurs de saisie et des doublons (le même
étudiant créé deux fois dans des semestres différents, ce qui empêche le suivi
de sa scolarité). Ces doublons posent de grandes difficultés et empêchent la
gestion automatique des jurys: soyez vigilants lors des inscriptions.
***On privilégiera donc l'import des étudiants depuis le portail (Apogée) à chaque fois que c'est possible. Voir [SynchroApogee](SynchroApogee.md).***
***On privilégiera donc l'import des étudiants depuis le portail (Apogée) à
chaque fois que c'est possible. Voir [SynchroApogee](SynchroApogee.md).***
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> Le texte ci-dessous ne s'applique qu'aux établissement sans liaison ScoDoc-Apogée, et donc ***ne concerne pas l'IUT de Villetaneuse ! ***
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
alt="/!\" /> Le texte ci-dessous ne s'applique qu'aux établissement sans liaison
ScoDoc-Apogée, et donc ***ne concerne pas l'IUT de Villetaneuse !***
Si vous souhaitez importer une liste de nouveaux étudiants (inconnus de ScoDoc, même dans d'autres semestres) sans utiliser un portail Apogée, il suffit de créer un fichier tableur comportant
toutes les informations requises. Le lien "importer de nouveaux étudiants"
vous permet de télécharger une feuille Excel avec les colonnes. Une fois cette feuille remplie
(une ligne par étudiant), cette feuille doit être renvoyée vers le
logiciel (indiquer le nom du fichier et cliquer sur le bouton "Télécharger").
Si vous souhaitez importer une liste de nouveaux étudiants (inconnus de ScoDoc,
même dans d'autres semestres) sans utiliser un portail Apogée, il suffit de
créer un fichier tableur comportant toutes les informations requises. Le lien
"*importer de nouveaux étudiants*" vous permet de télécharger une feuille Excel
avec les colonnes. Une fois cette feuille remplie (une ligne par étudiant),
cette feuille doit être renvoyée vers le logiciel (indiquer le nom du fichier et
cliquer sur le bouton "Télécharger").
![imprtetud1.png](screens/imprtetud1.png).
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> Vous devez *impérativement* utiliser la feuille excel proposée par le site pour
importer vos étudiants. Utiliser copier/coller pour remplir ses différentes colonnes.
Seules les colonnes dont le titre est en rouge sont obligatoires, les autres peuvent
être laissées vides, ou partiellement remplies.
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
alt="/!\" /> Vous devez *impérativement* utiliser la feuille excel proposée par
le site pour importer vos étudiants. Utiliser copier/coller pour remplir ses
différentes colonnes. Seules les colonnes dont le titre est en rouge sont
obligatoires, les autres peuvent être laissées vides, ou partiellement remplies.
Les étudiants importés vont être automatiquement inscrits dans le semestre
choisi (et inscrits à tous les modules de ce semestre, sauf ceux de sport et
culture). Il est donc nécessaire de créer le semestre *avant d'importer les
étudiants*.
Les étudiants importés vont être automatiquement inscrits dans le semestre choisi (et inscrits à tous les modules de ce semestre, sauf ceux de sport et culture).
Il est donc nécessaire de créer le semestre *avant d'importer les étudiants*.
Le plus simple est de passer par le lien "importer des étudiants" présent en bas du **tableau de bord semestre**.
Le plus simple est de passer par le lien "importer des étudiants" présent en bas
du **tableau de bord semestre**.
Autres remarques:
* le champ 'SEXE' doit contenir ```MR``` (masculin) ou ```MLLE``` (féminin).
* l'identité d'un étudiant (nom, prénom, civilité) peut quelquefois subir quelques variantes (voir [DonneesEtudiant](DonneesEtudiant.md))
- le champ 'SEXE' doit contenir ```MR``` (masculin) ou ```MME``` (féminin).
- l'identité d'un étudiant (nom, prénom, civilité) peut quelquefois subir
quelques variantes (voir [DonneesEtudiant](DonneesEtudiant.md))

View File

@ -1,47 +1,56 @@
# Inscription des étudiants via Apogée
# Inscription des étudiants via Apogée
Les informations données ici ne concernent que les établissement qui ont mis en place une interface entre ScoDoc et le logiciel d'administration Apogée, comme à l'IUT de Villetaneuse.
Cette interface repose sur l'utilisation d'un "portail" offrant les services décrits sur la page [InterrogationPortail](InterrogationPortail.md).
Les informations données ici ne concernent que les établissement qui ont mis en
place une interface entre ScoDoc et le logiciel d'administration Apogée, comme à
l'IUT de Villetaneuse. Cette interface repose sur l'utilisation d'un "portail"
offrant les services décrits sur la page
[InterrogationPortail](InterrogationPortail.md).
## Généralités
On conserve la possibilité de créer les étudiants individuellement, ou de les
importer d'un tableau Excel. Cependant, il est plus rationnel d'importer
directement les étudiants depuis Apogée (le logiciel utilisé par la scolarité
centrale).
## Généralités
On conserve la possibilité de créer les étudiants individuellement, ou
de les importer d'un tableau Excel. Cependant, il est plus rationnel d'importer directement les étudiants depuis Apogée (le logiciel utilisé par la scolarité centrale).
Apogée identifie les sessions de formation (semestres) par un "code étape". Nous
associons donc un code étape à chaque semestre ScoDoc. Lors de la création ou
modification d'un semestre, ScoDoc présente la liste d'étapes disponible (cette
liste peut être paramétrée dans ScoDoc via le fichier de configuration
`config/default-etapes.txt` et/ou est fournie par le service `getEtapes` du
portail, voir [détail techniques](InterrogationPortail.md)).
Apogée identifie les sessions de formation (semestres) par un "code étape". Nous associons donc un code étape à chaque semestre ScoDoc. Lors de la création ou modification
d'un semestre, ScoDoc présente la liste d'étapes disponible (cette liste
peut être paramétrée dans ScoDoc via le fichier de configuration `config/default-etapes.txt` et/ou est fournie par le service `getEtapes` du portail.
Note: Apogée réutilise les mêmes codes étapes pour les sessions d'années
différentes, ces codes changent donc rarement.
Note: Apogée réutilise les mêmes codes étapes pour les sessions d'années différentes, ces codes changent donc
rarement.
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
alt="/!\" /> certaines formations utilisent encore des codes Apogée *annuels*
alors qu'elles sont semestrialisées.
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> certaines formations utilisent encore des codes Apogée *annuels* alors qu'elles sont semestrialisées.
Une fois le code étape défini, ScoDoc peut interroger Apogée pour obtenir la
liste des étudiants inscrits dans cette étape. Les informations récupérées sont:
Une fois le code étape défini, ScoDoc peut interroger Apogée pour obtenir la liste des étudiants inscrits dans cette
étape. Les informations récupérées sont:
- identité (nom, prénom, civilité);
- adresse (et téléphone).
* identité (nom, prénom, civilité);
Apogée ne conserve pas (en général) les informations de type "admission" (lycée
d'origine, notes et type du bac, ...), il faudra donc les importer séparément si
on le souhaite (via le menu "Importer données admission").
* adresse (et téléphone).
## Procédure à suivre pour le premier semestre (S1)
Apogée ne conserve pas (en général) les informations de type "admission" (lycée d'origine, notes et type du bac, ...),
il faudra donc les importer séparément si on le souhaite (via le menu "Importer données admission").
Listes Apogée presque complètes, faire l'import depuis le portail fin juillet,
puis re-synchroniser fréquemment courant septembre. Voir
[SynchroApogee](SynchroApogee.md)
- nouveaux étudiants, modification données personnelles
## Procédure à suivre pour le premier semestre (S1)
- import données admission (depuis fichier Excel)
Listes Apogée presques complètes, faire l'import depuis le portail fin juillet,
puis synchros courant septembre. Voir [SynchroApogee](SynchroApogee.md)
* nouveaux etudiants, modifs données personnelles
* import données admission (depuis fichier Excel)
## Réinscriptions
## Réinscriptions
Les étudiants ont jusqu'à fin octobre pour se réinscrire, il est probable que
les listes Apogée ne soient pas à jour la semaine de la rentrée. On va donc
utiliser le mécanisme de passage interne à ScoDoc, et faire une synchro fin
octobre. Voir [TransitionSemestre](TransitionSemestre.md)
octobre. Voir [TransitionSemestre](TransitionSemestre.md).

View File

@ -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)

View File

@ -1,16 +1,23 @@
# Saisie des décisions de jury
# Saisie des décisions de jury
ScoDoc guide les travaux de la commission (et/ou du jury) en présentant le parcours et
les résultats de chaque étudiant, et les différentes décisions possibles
(voir explications dans [GestionJury](GestionJury.md)).
ScoDoc guide les travaux de la commission (et/ou du jury) en présentant le
parcours et les résultats de chaque étudiant, et les différentes décisions
possibles (voir explications dans [GestionJury](GestionJury.md)).
Note: pour le BUT, une page spéciale est présentée.
## Saisie des décisions pour un étudiant
On accède à cette page soit via la fiche étudiant (menu **Scolarité** du semestre à considérer),
soit via la page **Saisie des décisions du jury** accessible depuis le tableau de bord du semestre.
## Saisie des décisions pour un étudiant
On accède à cette page soit via la fiche étudiant (menu **Scolarité** du
semestre à considérer), soit via la page **Saisie des décisions du jury**
accessible depuis le tableau de bord du semestre.
![ValidationSemestre.png](screens/ValidationSemestre.png)
(source de ce dessin: <a class="attachment" href="/attachments/ValidationSemestre.dia" download>ValidationSemestre.dia</a>)
!!! note "Voir aussi"
- [Guide responsable de formation](GuideAdminFormation.md)
- [FAQ](FAQ.md)
- [Contacts](Contact.md)

View File

@ -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)

View File

@ -1,28 +1,35 @@
# Services XML pour l'export des données (obsolète)
# Services XML pour l'export des données
ScoDoc offre un certain nombre de services XML pour faciliter son intégration dans
!!! warning "Obsolète"
- Cette page est obsolète. Utiliser [l'API ScoDoc 9](ScoDoc9API.md)
ScoDoc offrait un certain nombre de services XML pour faciliter son intégration dans
d'autres composants (typiquement un portail de services pour étudiant,
comme le portail eSup CEVIF à l'IUT de Villetaneuse).
## Identification des étudiants
## Identification des étudiants
les étudiants peuvent être identifiés au choix par l'un des trois codes:
Les étudiants peuvent être identifiés au choix par l'un des trois codes:
- **`etudid`** : code interne ScoDoc, toujours disponible.
* **`etudid`** : code interne ScoDoc, toujours disponible.
- **`code_ine`** : code INE Apogée, s'il a été renseigné
* **`code_ine`** : code INE Apogée, s'il a été renseigné
- **`code_nip`** : code NIP Apogée, s'il a été renseigné
* **`code_nip`** : code NIP Apogée, s'il a été renseigné
## Listes des principaux points d'entrée
## Listes des principaux points d'entrée
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> pour des raisons historiques, les noms des fonctions ne sont pas homogènes :-(
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
alt="/!\" /> pour des raisons historiques, les noms des fonctions ne sont pas
homogènes :-(
* **`XMLgetEtudInfos`**
* Paramètre: etudid ou code_ine ou code_nip
* Donne des informations sur l'étudiant et les semestres où il est (ou a été) inscrit.
* Exemple:
```
* **`XMLgetEtudInfos`**
* Paramètre: etudid ou code_ine ou code_nip
* Donne des informations sur l'étudiant et les semestres où il est (ou a été) inscrit.
* Exemple:
```xml
<etudiant nom="DUPOND" prenom="FREDERIC" sexe="M." code_ine="250308450" nomprenom="M. Frederic MARSAUD" code_nip="105022504" etudid="ADCDEF" email="toto@xxx.com" photo_url="https://scodoc.example.com/Dept/Fotos/dcp_2777.h90.jpg">
<insemestre etat="I" formsemestre_id="SEM4740" date_fin="2007-06-30" date_debut="2007-01-22" />
<insemestre etat="I" formsemestre_id="SEM3608" date_fin="2007-01-31" date_debut="2006-09-01" />
@ -30,11 +37,11 @@ les étudiants peuvent être identifiés au choix par l'un des trois codes:
</etudiant>
```
* **`XMLgetGroupsInPartition`**
* Paramètres: `partition_id=X`
* Donne la liste des étudiants dans un semestre, par groupes.
* Exemple:
```
* **`XMLgetGroupsInPartition`**
* Paramètres: `partition_id=X`
* Donne la liste des étudiants dans un semestre, par groupes.
* Exemple:
```xml
<ajax-response>
<response type="object" id="MyUpdater">
@ -51,13 +58,13 @@ les étudiants peuvent être identifiés au choix par l'un des trois codes:
</ajax-response>
```
* **`XMLgetFormsemestres`**
* Paramètres optionnels:
* `formsemestre_id` code semestre ScoDoc
* `etape_apo` code étape Apogée
* Donne informations sur le ou les semestres sélectionnés (par défaut, sur tous les semestres).
* Exemple:
```
* **`XMLgetFormsemestres`**
* Paramètres optionnels:
* `formsemestre_id` code semestre ScoDoc
* `etape_apo` code étape Apogée
* Donne informations sur le ou les semestres sélectionnés (par défaut, sur tous les semestres).
* Exemple:
```xml
<formsemestrelist>
<formsemestre
formsemestre_id="SEM4741"
@ -71,12 +78,12 @@ les étudiants peuvent être identifiés au choix par l'un des trois codes:
</formsemestrelist>
```
* **`formation_export_xml`**
* Paramètre: `formation_id`
* Export XML du programme pédagogique complet (UE, matières, modules). Ce format XML est réimportable pour créer une nouvelle formation.
* Exemple:
```
* **`formation_export_xml`**
* Paramètre: `formation_id`
* Export XML du programme pédagogique complet (UE, matières, modules). Ce
format XML est réimportable pour créer une nouvelle formation.
* Exemple:
```xml
<formation acronyme="DUT R&amp;T" titre_officiel="DUT Réseaux et Télécommunications" formation_code="FCOD2" version="0" titre="DUT Réseaux et Télécommunications" formation_id="FORM1130">
<ue acronyme="UE 1" ue_code="UCOD5" numero="1" ue_id="UE1131" titre="Formation Générale" formation_id="FORM1130" type="0">
<matiere titre="Mathématiques" matiere_id="MAT1132" numero="10" ue_id="UE1131">
@ -84,14 +91,14 @@ les étudiants peuvent être identifiés au choix par l'un des trois codes:
titre="Fondamentaux d'algèbre et de trigonométrie" module_id="MOD1138" formation_id="FORM1130" heures_td="30.0"/>
...
...
```
```xml
* **`formsemestre_bulletinetud`**
* Paramètres: `format=xml&formsemestre_id=XXX&etudid=YYYX`
* Paramètre optionnel: xml_with_decisions (force l'envoi des décisions même si elles ne doivent pas être montrées aux étudiants)
* Bulletin de notes de l'étudiant. Toutes les notes obtenues dans ce semestres et prises en compte pour le calcul des moyennes (intégralement saisies), et décisions du jury si elles sont affichées (voir réglage des options du semestre).
* Exemple:
```
* **`formsemestre_bulletinetud`**
* Paramètres: `format=xml&formsemestre_id=XXX&etudid=YYYX`
* Paramètre optionnel: `xml_with_decisions` (force l'envoi des décisions même si elles ne doivent pas être montrées aux étudiants)
* Bulletin de notes de l'étudiant. Toutes les notes obtenues dans ce semestres et prises en compte pour le calcul des moyennes (intégralement saisies), et décisions du jury si elles sont affichées (voir réglage des options du semestre).
* Exemple:
```xml
<bulletinetud date="2007-07-11T18:50:48.164292" formsemestre_id="SEM4729" publie="1" etudid="10408738" etape_apo="V1TR">
<etudiant nom="DUPONT" prenom="YACINE" sexe="M." code_ine="2222222" etudid="11111111" code_nip="1033333333" email="toto@hotmail.com" photo_url="https://www-gtr.iutv.univ-paris13.fr/Dept/Fotos/dcp_n_01919.h90.jpg"/>
<note value="12.92"/>
@ -112,25 +119,29 @@ les étudiants peuvent être identifiés au choix par l'un des trois codes:
```
Si les décisions du jury sont publiées, on a un élément:
```
```xml
<decision etat="I" code="ADM"/>
```
et le cas échéant dans la décision une autorisation d'inscription (passage à un autre semestre) sous la forme:
```
et le cas échéant dans la décision une autorisation d'inscription (passage à un
autre semestre) sous la forme:
```xml
<autorisation_inscription semestre_id="3"/>
```
Le bulletin comporte aussi le décompte des absences enregistrées au cours de ce semestre (comptées en nombre de demi-journées):
```
Le bulletin comporte aussi le décompte des absences enregistrées au cours de ce
semestre (comptées en nombre de demi-journées):
```xml
<absences nbabsjust="0" nbabs="2"/>
```
* **`formsemestre_recapcomplet`**
* Paramètres: `formsemestre_id=XXXX&tabformat=xml`
* Paramètre optionnel: xml_with_decisions (force l'envoi des décisions même si elles ne doivent pas être montrées aux étudiants)
* L'ensemble des bulletins de toutes la promotion d'étudiants (au même format que `formsemestre_bulletinetud`).
* Exemple:
```
* **`formsemestre_recapcomplet`**
* Paramètres: `formsemestre_id=XXXX&tabformat=xml`
* Paramètre optionnel: xml_with_decisions (force l'envoi des décisions même
si elles ne doivent pas être montrées aux étudiants)
* L'ensemble des bulletins de toutes la promotion d'étudiants (au même
format que `formsemestre_bulletinetud`).
* Exemple:
```xml
<recapsemestre date="2007-07-11T19:00:12.370531" formsemestre_id="SEM4729">
<evals_info date_derniere_note="2007-07-02 14:04:11.00" nb_evals_vides="0" nb_evals_en_cours="0" nb_evals_completes="28"/>
<bulletinetud ...>
@ -141,26 +152,33 @@ Le bulletin comporte aussi le décompte des absences enregistrées au cours de c
```
## Absences
* **`XMLgetAbsEtud`**
* Paramètres: etudid ou code_ine ou code_nip, beg_date, end_date (au format ISO 2009-11-04)
* La liste des absences entre les dates indiquées (inclues):
```
## Absences
* **`XMLgetAbsEtud`**
* Paramètres: etudid ou code_ine ou code_nip, beg_date, end_date (au format
ISO 2009-11-04)
* La liste des absences entre les dates indiquées (inclues):
```xml
<absences beg_date="2009-11-03" end_date="2009-11-29" etudid="EID1911">
<abs begin="2009-11-04 08:00:00" end="2009-11-04 11:59:59" justified="1" description="malade"/>
<abs begin="2009-11-04 12:00:00" end="2009-11-04 17:59:59" justified="0" description=""/>
</absences>
```
* Les billets d'absences sont entrés via l'appel **`AddBilletAbsence`**:
* Paramètres: etudid ou code_ine ou code_nip, begin, end, description
* Résultat: XML contenant l'ID du billet créé.
* Les billets d'absences sont entrés via l'appel **`AddBilletAbsence`**:
* Paramètres: etudid ou code_ine ou code_nip, begin, end, description
* Résultat: XML contenant l'ID du billet créé.
* **`XMLgetBilletsEtud`**
* Paramètre: etudid ou code_ine ou code_nip
* Les "billets" d'absence reçus pour cet étudiant (`etat` vaut 0 si le billet n'a pas été traité, 1 sinon, et `description` est la raison déclarée de l'absence).
* Exemple (1 row par billet):
```
* **`XMLgetBilletsEtud`**
* Paramètre: etudid ou code_ine ou code_nip
* Les "billets" d'absence reçus pour cet étudiant (`etat` vaut 0 si le billet
n'a pas été traité, 1 sinon, et `description` est la raison déclarée de
l'absence).
* Exemple (1 row par billet):
```xml
<table origin="" caption="" id="gt_920276">
<row>
<billet_id value="ABS-3"/>
@ -171,4 +189,3 @@ Le bulletin comporte aussi le décompte des absences enregistrées au cours de c
</row>
</table>
```

View File

@ -1,27 +1,48 @@
La page **Synchroniser avec étape Apogée** est accessible depuis le tableau de bord du semestre (via le menu **Inscriptions**). Elle permet de vérifier et modifier les inscriptions au semestre en utilisant l'étape Apogée (les inscriptions dans Apogée sont normalement gérées par le service de la Scolarité, cette opération ne concerne donc que les étudiants régulièrement inscrits).
# Synchronisation avec Apogée
La page **Synchroniser avec étape Apogée** est accessible depuis le tableau de
bord du semestre (via le menu **Inscriptions**). Elle permet de vérifier et
modifier les inscriptions au semestre en utilisant l'étape Apogée (les
inscriptions dans Apogée sont normalement gérées par le service de la Scolarité,
cette opération ne concerne donc que les étudiants régulièrement inscrits).
![MenuSynchroEtape.png](screens/MenuSynchroEtape.png).
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> Cette opération ne fonctionnera que si vous avez correctement renseigné le code étape du semestre (menu **Modifier le semestre**).
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
alt="/!\" /> Cette opération ne fonctionnera que si vous avez correctement
renseigné le code étape du semestre (menu **Modifier le semestre**).
ScoDoc peut rencontrer quatre cas de figure pour chaque étudiant:
1- étudiant présent dans Apogée et inscrit dans le semestre ScoDoc (*tout va bien*)
1- étudiant présent dans Apogée et inscrit dans le semestre ScoDoc (*tout va
bien*)
2- étudiant dans Apogée, dans ScoDoc, mais pas inscrit dans le semestre (*non incrit, on devrait l'inscrire*)
2- étudiant dans Apogée, dans ScoDoc, mais pas inscrit dans le semestre (*non
inscrit, on devrait l'inscrire*)
3- étudiant dans Apogée et pas dans ScoDoc (*on devrait l'importer et l'inscrire*)
3- étudiant dans Apogée et pas dans ScoDoc (*on devrait l'importer et
l'inscrire*)
4- étudiant inscrit dans le semestre ScoDoc, mais pas trouvé dans Apogée (sur la base du code NIP) (*peut être pas encore inscrit, ou bien une erreur de saisie ?*)
4- étudiant inscrit dans le semestre ScoDoc, mais pas trouvé dans Apogée (sur la
base du code NIP) (*peut être pas encore inscrit, ou bien une erreur de saisie
?*)
Ces quatre cas sont présentés dans des cadres différents.
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)

View File

@ -1,71 +1,142 @@
# Récapitulatif des opérations en fin de semestre (et début du suivant)
Cette page récapitule les opérations typiquement effectuées par un chef de département en IUT à la fin d'un semestre. Selon les cas, certaines opérations peuvent être effectuées par les directeurs des études. La plupart des étapes mentionnées ici sont aussi applicables pour d'autres types de formation.
Cette page récapitule les opérations typiquement effectuées par un chef de
département en IUT à la fin d'un semestre. Selon les cas, certaines opérations
peuvent être effectuées par les directeurs des études. La plupart des étapes
mentionnées ici sont aussi applicables pour d'autres types de formation.
Voir aussi le [Guide pour la cheffe ou le chef de département](GuideAdminFormation.md).
Voir aussi le [Guide pour la cheffe ou le chef de
département](GuideAdminFormation.md).
## À la fin d'un semestre
1. Vérifier que les réglages de votre semestre correspondent bien à ce que vous voulez. En particulier, les options comme *proposer compensation* et *jurys avec semestres décalés* (accessibles via *Modifier le semestre*, voir figure).
1. Vérifier que les réglages de votre semestre correspondent bien à ce que vous
voulez. En particulier, les options comme *proposer compensation* et *jurys
avec semestres décalés* (accessibles via *Modifier le semestre*, voir
figure).
![reglages-semestres-check.png](screens/reglages-semestres-check.png)
2. Vérifier que le parcours choisi est correct (menu *Semestre* / *Voir la formation*): ainsi, le parcours affiché doit être "DUT selon l'arrêté d'août 2005" pour le DUT.
2. Vérifier que le cursus choisi est correct (menu *Semestre* / *Voir la
formation*): ainsi, le parcours affiché doit être "DUT selon l'arrêté d'août
2005" pour le DUT.
3. Vérifier que toutes les notes ont été saisies: regarder le tableau de bord, qui affiche dans chaque module les évaluations et indique si des notes manquent ou sont en attente.
3. Vérifier que toutes les notes ont été saisies: regarder le tableau de bord,
qui affiche dans chaque module les évaluations et indique si des notes
manquent ou sont en attente.
4. (optionnel) Vérifier les absences si cela n'a pas déjà été fait. Dans le menu *Semestre* du tableau de bord, suivre *Vérifier les absences aux évaluations*.
Attention, actuellement ScoDoc enregistre les absences par demi-journées, ce qui fait qu'un étudiant peut être noté absent alors qu'il a assisté à un examen sur une partie de la demi-journée et sèché le cours suivant.
4. (optionnel) Vérifier les absences si cela n'a pas déjà été fait. Dans le
menu *Semestre* du tableau de bord, suivre *Vérifier les absences aux
évaluations*.
Attention, actuellement ScoDoc enregistre les absences par demi-journées, ce
qui fait qu'un étudiant peut être noté absent alors qu'il a assisté à un
examen sur une partie de la demi-journée et sèché le cours suivant.
5. Réunir la commission (ou le jury):
a. Il peut être utile de préparer des documents pour les membres de la commission: suivre *Générer feuille préparation Jury* dans le menu *Jury*.
a. Il peut être utile de préparer des documents pour les membres de la
commission: suivre *Générer feuille préparation Jury* dans le menu *Jury*.
b. Durant la commission, nous recommandons de saisir en temps réel les décisions (menu *Jury / Saisie des décisions*). **Pour éviter que les étudiants n'aient accès aux décisions pendant le jury, décocher l'option *publier le bulletin sur le portail* ** (menu *Semestre / Options du semestre*).
b. Durant la commission, nous recommandons de saisir en temps réel les
décisions (menu *Jury / Saisie des décisions*). **Pour éviter que les
étudiants n'aient accès aux décisions pendant le jury, décocher l'option
*publier le bulletin sur le portail* ** (menu *Semestre / Options du
semestre*).
6. Édition du procès-verbal: menu *Jury / Voir les décisions du jury*.
1. En bas de la page, un lien *Courriers individuels (classeur pdf)* permet de générer les courriers à adresser aux étudiants (penser à vérifier leurs adresses postales au préalable sur leurs fiches).
1. En bas de la page, un lien *Courriers individuels (classeur pdf)* permet
de générer les courriers à adresser aux étudiants (penser à vérifier
leurs adresses postales au préalable sur leurs fiches).
2. Le lien *PV officiel (pdf)* permet de générer le procès verbal avec la liste des décisions pour chaque étudiant.
2. Le lien *PV officiel (pdf)* permet de générer le procès verbal avec la
liste des décisions pour chaque étudiant.
A ce stade, le semestre est terminé. Il est recommandé de le **verrouiller** après les prises de décisions définitives.
A ce stade, le semestre est terminé. Il est recommandé de le **verrouiller**
après les prises de décisions définitives.
## Mise en place du semestre suivant
1. **Créer une instance du semestre suivant** (par exemple un S2 après un S1). Pour cela, aller sur la page *Programmes*, choisir la formation (rappelons que ScoDoc appelle "formation" la définition d'un programme pédagogique) et suivre le lien *UE, modules, semestres*.
1. **Créer une instance du semestre suivant** (par exemple un S2 après un S1).
Pour cela, aller sur la page *Programmes*, choisir la formation (rappelons
que ScoDoc appelle "formation" la définition d'un programme pédagogique) et
suivre le lien *UE, modules, semestres*.
2. En bas de la page qui détaille le programme, suivre le lien *Mettre en place un nouveau semestre de formation* et remplissez le formulaire.
2. En bas de la page qui détaille le programme, suivre le lien *Mettre en place
un nouveau semestre de formation* et remplissez le formulaire.
Une autre approche, souvent plus rapide, consiste à créer un semestre en utilisant un semestre existant comme modèle: on reprend la même liste de modules; pour cela, se placer sur le semestre modèle, et utiliser le menu ** *Cloner ce semestre* **.
Une autre approche, souvent plus rapide, consiste à créer un semestre en
utilisant un semestre existant comme modèle: on reprend la même liste de
modules; pour cela, se placer sur le semestre modèle, et utiliser le menu **
*Cloner ce semestre* **.
1. Indiquez les dates correctes de début et de fin du semestre (attention: il est important que les dates ne se chevauchent pas: le nouveau semestre doit commencer quelques jours (ou semaines) après le précédent !)
1. Indiquez les dates correctes de début et de fin du semestre (attention:
il est important que les dates ne se chevauchent pas: le nouveau semestre
doit commencer quelques jours (ou semaines) après le précédent !)
2. Désignez le responsable (directeur des études en DUT).
3. Si vous êtes interfacé à Apogée (via un portail), indiquez le code étape Apogée correspondant à votre nouveau semestre.
3. Si vous êtes interfacé à Apogée (via un portail), indiquez le code étape
Apogée correspondant à votre nouveau semestre.
4. Cocher les modules de votre semestre, et associez leur un enseignant responsable (ce dernier pourra créer des évaluations dans ce module et déclarer des collègues pouvant saisir les notes).
4. Cocher les modules de votre semestre, et associez leur un enseignant
responsable (ce dernier pourra créer des évaluations dans ce module et
déclarer des collègues pouvant saisir les notes).
5. Après relecture, cliquez sur le bouton *Créer ce semestre de formation*.
NB: toutes ces informations pourront être ultérieurement modifiées via le lien *Semestre / Modifer le semestre* du tableau de bord.
3. **Inscrire les étudiants** Sauf pour le premier semestre (S1), il est en général plus simple de s'appuyer sur les décisions de jury pour sélectionner rapidement les étudiants à inscrire. C'est ce que permet la page *Inscriptions / Passage des étudiants depuis d'autres semestres*. Voir les explications sur cette page.
3. **Inscrire les étudiants** Sauf pour le premier semestre (S1), il est en
général plus simple de s'appuyer sur les décisions de jury pour sélectionner
rapidement les étudiants à inscrire. C'est ce que permet la page
*Inscriptions / Passage des étudiants depuis d'autres semestres*. Voir les
explications sur cette page.
4. Si vous avez un portail **Apogée** et que les inscriptions Apogée ont été effectuées (ou les changements de codes étapes), utiliser *Inscriptions / Synchroniser avec étape Apogée* pour vérifier et compléter la liste des inscrits. (Pour plus d'informations consulter aussi les pages [Vérifier les codes NIP](VerifCodeNIP.md) et [Synchroniser avec une étape Apogée](SynchroApogee.md).)
4. Si vous avez un portail **Apogée** et que les inscriptions Apogée ont été
effectuées (ou les changements de codes étapes), utiliser *Inscriptions /
Synchroniser avec étape Apogée* pour vérifier et compléter la liste des
inscrits. (Pour plus d'informations consulter aussi les pages [Vérifier les
codes NIP](VerifCodeNIP.md) et [Synchroniser avec une étape
Apogée](SynchroApogee.md).)
5. Si vous n'avez pas Apogée, qu'il s'agit du premier semestre, que vous n'utilisez pas non plus d'imports par fichiers Excel, et qu'il manque des étudiants (inscrits d'autres origines, cas particulier), il faut les créer individuellement (via le lien *créer un nouvel étudiant* en bas de la page d'accueil) puis les inscrire (via le menu *Inscriptions / Inscrire un étudiant* du tableau de bord semestre. **Avant cela, vérifiez bien que l'étudiant n'existe pas déjà dans ScoDoc afin de ne pas créer de doublons**.
5. Si vous n'avez pas Apogée, qu'il s'agit du premier semestre, que vous
n'utilisez pas non plus d'imports par fichiers Excel, et qu'il manque des
étudiants (inscrits d'autres origines, cas particulier), il faut les créer
individuellement (via le lien *créer un nouvel étudiant* en bas de la page
d'accueil) puis les inscrire (via le menu *Inscriptions / Inscrire un
étudiant* du tableau de bord semestre. **Avant cela, vérifiez bien que
l'étudiant n'existe pas déjà dans ScoDoc afin de ne pas créer de doublons**.
6. (optionnel) Répartir les étudiants dans des groupes de TD (*Inscriptions / Modifier les groupes*).
6. (optionnel) Répartir les étudiants dans des groupes de TD (*Inscriptions /
Modifier les groupes*).
C'est prêt. Les enseignants autorisés peuvent créer des évaluations et saisir des notes.
## Problèmes couramment rencontrés
- **Etudiants en doubles**: ceci arrive lorsqu'on crée manuellement les étudiants. Il faut absolument éviter de créer un étudiant qui existe déjà, sinon on perd la possibilité de suivre le parcours de chacun. Le respect de la procédure ci-dessus garanti normalement que les étudiants restent uniques. N'utiliser *créer un nouvel étudiant* qu'après vous être assuré qu'il n'était pas déjà inscrit dans un autre semestre, et que l'on sait que l'on ne va pas l'importer depuis Apogée.
- **Etudiants en doubles**: ceci arrive lorsqu'on crée manuellement les
étudiants. Il faut absolument éviter de créer un étudiant qui existe déjà,
sinon on perd la possibilité de suivre le parcours de chacun. Le respect de la
procédure ci-dessus garanti normalement que les étudiants restent uniques.
N'utiliser *créer un nouvel étudiant* qu'après vous être assuré qu'il n'était
pas déjà inscrit dans un autre semestre, et que l'on sait que l'on ne va pas
l'importer depuis Apogée.
- **Désinscription d'un étudiant**: si vous avez inscrit par erreur un étudiant dans un semestre, ce n'est pas grave: vous pouvez le désinscrire en utilisant le menu *Scolarité / désinscrire* sur sa fiche individuelle (à droite du nom du semestre concerné).
- **Désinscription d'un étudiant**: si vous avez inscrit par erreur un étudiant
dans un semestre, ce n'est pas grave: vous pouvez le désinscrire en utilisant
le menu *Scolarité / désinscrire* sur sa fiche individuelle (à droite du nom
du semestre concerné).
- **Aucun étudiant à inscrire**: cela peut arriver si les dates de semestres sont incorrectes (chevauchement): en particulier, vérifier que la date de début du nouveau semestre est bien postérieure à la date de fin des semestres d'où proviennent les étudiants à inscrire.
- **Aucun étudiant à inscrire**: cela peut arriver si les dates de semestres
sont incorrectes (chevauchement): en particulier, vérifier que la date de
début du nouveau semestre est bien postérieure à la date de fin des semestres
d'où proviennent les étudiants à inscrire.
Pour toutes questions, n'hésitez pas à nous contacter (voir la [contacts](Contact.md)).
Pour toute question, n'hésitez pas à nous contacter ([contacts](Contact.md)).
!!! note "Voir aussi"
- [Vérifier les codes NIP](VerifCodeNIP.md)
- [Guide pour le ou la responsable de formation](GuideAdminFormation.md)
- [FAQ](FAQ.md)
- [Contacts](Contact.md)

View File

@ -1,33 +1,48 @@
# Vérification des codes NIP
## Vérification des codes NIP
Le code NIP est le code d'identification de l'étudiant utilisé par le service de la scolarité (logiciel Apogée) et qui apparait entre autre sur la carte d'étudiant. ScoDoc peut l'utiliser, ce qui est utile si le logiciel est interfacé à un portail qui le connecte à Apogée. Si vous utilisez ScoDoc seul, il n'est pas utile de saisir les codes NIP.
Le code NIP est le code d'identification de l'étudiant utilisé par le service de
la scolarité (logiciel Apogée) et qui apparait entre autre sur la carte
d'étudiant. ScoDoc peut l'utiliser, ce qui est utile si le logiciel est
interfacé à un portail qui le connecte à Apogée. Si vous utilisez ScoDoc seul,
il n'est pas utile de saisir les codes NIP.
Lorsqu'on importe un étudiant depuis le portail, il est naturellement associé à son code NIP.
Lorsqu'on importe un étudiant depuis le portail, il est naturellement associé à
son code NIP.
Ce n'est pas le cas si l'on a importé l'étudiant à la main (via un formulaire ou l'importation d'une feuille Excel).
Ce n'est pas le cas si l'on a importé l'étudiant à la main (via un formulaire ou
l'importation d'une feuille Excel).
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> Le code NIP est utilisé par le portail pour identifer les étudiants: *si ScoDoc ne le connait pas, l'étudiant n'a pas accès à son bulletin de notes sur le web*.
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
alt="/!\" /> Le code NIP est utilisé par le portail pour identifier les
étudiants: *si ScoDoc ne le connait pas, l'étudiant n'a pas accès à son bulletin
de notes sur le web*.
## Fixer le code NIP d'un étudiant
Pour renseigner à postériori le code NIP d'un étudiant, passer par sa fiche
individuelle, menu Etudiant, **Changer les données identité/admission**. En bas
de cette page, la section "Informations Apogée" vous montre toutes les
informations retrouvées dans Apogée.
Attention, dans la recherche est effectuée en utilisant le nom et le prénom.
S'ils sont mal orthographiés (dans ScoDoc ou dans Apogée), elle peut échouer. Si
on a des homonymes (cas fréquent), ScoDoc présente une liste d'étudiants
d'Apogée pouvant correspondre à celui de ScoDoc: à vous de choisir.
Vous pouvez facilement copier le code de l'étudiant qui correspond via le bouton
**copier ce code**. Cliquez ensuite sur le bouton **Modifier les données**.
## Vérifier les codes de tous les étudiants d'un semestre
Vous pouvez vérifier les codes et adresses mail de tous les étudiants d'un
semestre via la page **vérification des codes Apogée**. Cette page est
accessible via un lien en bas de la page **Synchroniser avec une étape Apogée**.
!!! note "Voir aussi"
## Fixer le code NIP d'un étudiant
Pour renseigner à postériori le code NIP d'un étudiant, passer par sa fiche individuelle, menu Etudiant, **Changer les données identité/admission**. En bas de cette page, la section "Informations Apogée" vous montre toutes les informations retrouvées dans Apogée.
Attention, dans la recherche est effectuée en utilisant le nom et le prénom. S'ils sont mal orthographiés (dans ScoDoc ou dans Apogée), elle peut échouer. Si on a des homonymes (cas fréquent), ScoDoc présente une liste d'étudiants d'Apogée pouvant correspondre à celui de ScoDoc: à vous de choisir.
Vous pouvez facilement copier le code de l'étudiant qui correspond via le bouton **copier ce code**.
Cliquez ensuite sur le bouton **Modifier les données**.
## Vérifier les codes de tous les étudiants d'un semestre
Vous pouvez vérifier les codes et adresses mail de tous les étudiants d'un semestre via la page **vérification des codes Apogée**. Cette page est accessible via un lien en bas de la page **Synchroniser avec une étape Apogée**.
### Voir aussi:
- [Synchroniser avec une étape Apogée](SynchroApogee.md)
- [Guide pour le chef de département](GuideAdminFormation.md)
- [Opérations de fin de semestre](TransitionSemestre.md)
- [Synchroniser avec une étape Apogée](SynchroApogee.md)
- [Guide pour le ou la responsable de formation](GuideAdminFormation.md)
- [Opérations de fin de semestre](TransitionSemestre.md)
- [FAQ](FAQ.md)
- [Contacts](Contact.md)

View File

@ -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)

Binary file not shown.

After

Width:  |  Height:  |  Size: 203 KiB

View File

Before

Width:  |  Height:  |  Size: 70 KiB

After

Width:  |  Height:  |  Size: 70 KiB

View File

Before

Width:  |  Height:  |  Size: 88 KiB

After

Width:  |  Height:  |  Size: 88 KiB

View File

@ -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