forked from ScoDoc/DocScoDoc
Compare commits
20 Commits
ca7a2fe546
...
d7df642b71
Author | SHA1 | Date | |
---|---|---|---|
|
d7df642b71 | ||
1f9a09c70c | |||
bb1caaf32c | |||
6d1e4d1ece | |||
69c5ad9b23 | |||
|
4d56488159 | ||
|
6360782fb4 | ||
e62c81338d | |||
0e79f99e1a | |||
7cd56f4059 | |||
7f64c8c111 | |||
bec9f78764 | |||
aed7133ab2 | |||
a039e71c06 | |||
e76e441e90 | |||
69e528a5bc | |||
d409fd66a9 | |||
fe583938e0 | |||
8be16fa32e | |||
3825e37fbb |
194
.gitignore
vendored
194
.gitignore
vendored
@ -1 +1,193 @@
|
||||
.idea
|
||||
# ---> Emacs
|
||||
# -*- mode: gitignore; -*-
|
||||
*~
|
||||
\#*\#
|
||||
/.emacs.desktop
|
||||
/.emacs.desktop.lock
|
||||
*.elc
|
||||
auto-save-list
|
||||
tramp
|
||||
.\#*
|
||||
|
||||
# Org-mode
|
||||
.org-id-locations
|
||||
*_archive
|
||||
|
||||
# flymake-mode
|
||||
*_flymake.*
|
||||
|
||||
# eshell files
|
||||
/eshell/history
|
||||
/eshell/lastdir
|
||||
|
||||
# elpa packages
|
||||
/elpa/
|
||||
|
||||
# reftex files
|
||||
*.rel
|
||||
|
||||
# AUCTeX auto folder
|
||||
/auto/
|
||||
|
||||
# cask packages
|
||||
.cask/
|
||||
dist/
|
||||
|
||||
# Flycheck
|
||||
flycheck_*.el
|
||||
|
||||
|
||||
|
||||
|
||||
# ---> Python
|
||||
# Byte-compiled / optimized / DLL files
|
||||
__pycache__/
|
||||
*.py[cod]
|
||||
*$py.class
|
||||
|
||||
# C extensions
|
||||
*.so
|
||||
|
||||
# Distribution / packaging
|
||||
.Python
|
||||
build/
|
||||
develop-eggs/
|
||||
dist/
|
||||
downloads/
|
||||
eggs/
|
||||
.eggs/
|
||||
lib/
|
||||
lib64/
|
||||
parts/
|
||||
sdist/
|
||||
var/
|
||||
wheels/
|
||||
share/python-wheels/
|
||||
*.egg-info/
|
||||
.installed.cfg
|
||||
*.egg
|
||||
MANIFEST
|
||||
|
||||
# PyInstaller
|
||||
# Usually these files are written by a python script from a template
|
||||
# before PyInstaller builds the exe, so as to inject date/other infos into it.
|
||||
*.manifest
|
||||
*.spec
|
||||
|
||||
# Installer logs
|
||||
pip-log.txt
|
||||
pip-delete-this-directory.txt
|
||||
|
||||
# Unit test / coverage reports
|
||||
htmlcov/
|
||||
.tox/
|
||||
.nox/
|
||||
.coverage
|
||||
.coverage.*
|
||||
.cache
|
||||
nosetests.xml
|
||||
coverage.xml
|
||||
*.cover
|
||||
*.py,cover
|
||||
.hypothesis/
|
||||
.pytest_cache/
|
||||
cover/
|
||||
|
||||
# Translations
|
||||
*.mo
|
||||
*.pot
|
||||
|
||||
# Django stuff:
|
||||
*.log
|
||||
local_settings.py
|
||||
db.sqlite3
|
||||
db.sqlite3-journal
|
||||
|
||||
# Flask stuff:
|
||||
instance/
|
||||
.webassets-cache
|
||||
|
||||
# Scrapy stuff:
|
||||
.scrapy
|
||||
|
||||
# Sphinx documentation
|
||||
docs/_build/
|
||||
|
||||
# PyBuilder
|
||||
.pybuilder/
|
||||
target/
|
||||
|
||||
# Jupyter Notebook
|
||||
.ipynb_checkpoints
|
||||
|
||||
# IPython
|
||||
profile_default/
|
||||
ipython_config.py
|
||||
|
||||
# pyenv
|
||||
# For a library or package, you might want to ignore these files since the code is
|
||||
# intended to run in multiple environments; otherwise, check them in:
|
||||
# .python-version
|
||||
|
||||
# pipenv
|
||||
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
|
||||
# However, in case of collaboration, if having platform-specific dependencies or dependencies
|
||||
# having no cross-platform support, pipenv may install dependencies that don't work, or not
|
||||
# install all needed dependencies.
|
||||
#Pipfile.lock
|
||||
|
||||
# PEP 582; used by e.g. github.com/David-OConnor/pyflow
|
||||
__pypackages__/
|
||||
|
||||
# Celery stuff
|
||||
celerybeat-schedule
|
||||
celerybeat.pid
|
||||
|
||||
# SageMath parsed files
|
||||
*.sage.py
|
||||
|
||||
# Environments
|
||||
.env
|
||||
.venv
|
||||
env/
|
||||
venv/
|
||||
ENV/
|
||||
env.bak/
|
||||
venv.bak/
|
||||
|
||||
# Spyder project settings
|
||||
.spyderproject
|
||||
.spyproject
|
||||
|
||||
# Rope project settings
|
||||
.ropeproject
|
||||
|
||||
# mkdocs documentation
|
||||
/site
|
||||
|
||||
# mypy
|
||||
.mypy_cache/
|
||||
.dmypy.json
|
||||
dmypy.json
|
||||
|
||||
# Pyre type checker
|
||||
.pyre/
|
||||
|
||||
# pytype static type analyzer
|
||||
.pytype/
|
||||
|
||||
# Cython debug symbols
|
||||
cython_debug/
|
||||
|
||||
# Mac OSX OS generated files
|
||||
.DS_Store?
|
||||
Thumbs.db
|
||||
*.DS_Store
|
||||
|
||||
# Other source repository archive directories (protects when importing)
|
||||
.hg
|
||||
.svn
|
||||
CVS
|
||||
|
||||
# MkDocs ScoDoc
|
||||
site/
|
||||
|
@ -88,6 +88,18 @@ Exemple: création d'une rôle "Observateur" ayant juste la persmision de "voir"
|
||||
|
||||
Ajoute ou retire une permission.
|
||||
|
||||
## Ajout/retrait d'un rôle à un utilisateur
|
||||
|
||||
flask user-role username [-d departement] [-a RoleAAjouter] [-r RoleARetirer]
|
||||
|
||||
Exemple:
|
||||
|
||||
flask user-role dupont -d MMI -a Observateur
|
||||
|
||||
donne le rôle `Observateur` (qui doit déjà exister) à l'utilisateur `dupont` dans
|
||||
le département `MMI`.
|
||||
|
||||
Si le département n'est pas spécifié, le rôle est donné dans *tous* les départements.
|
||||
|
||||
## Migration des données de ScoDoc 7
|
||||
Les données dans ScoDoc 9 ayant un format et une organisation très différents
|
||||
|
74
docs/Internals.md
Normal file
74
docs/Internals.md
Normal file
@ -0,0 +1,74 @@
|
||||
# Code de ScoDoc 9
|
||||
|
||||
Quelques informations pour les développeurs.
|
||||
|
||||
- le code est écrit en Python 3.9 (passage à 3.10 prévu en 2022).
|
||||
- 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/)
|
||||
- [Postgresql](https://www.postgresql.org/)
|
||||
- [NGINX](https://www.nginx.com/) serveur Web frontal
|
||||
- [gunicorn](https://gunicorn.org/) WSGI HTTP server
|
||||
- et bien sûr Linux (Debian) et systemd.
|
||||
|
||||
# Principaux objets
|
||||
|
||||
Les objets manipulés par ScoDoc sont pour la plupart stockés en base postgres et
|
||||
accédé soit directement en SQL (anciennes parties de ScoDoc), soit à travers
|
||||
l'ORM SQLAlchemy (recommandé pour tout nouveau code).
|
||||
|
||||
Les modèles correspondant sont déclarés dans `/opt/scodoc/app/models/`.
|
||||
|
||||
Principales classes (le nom de certaines classes Python est donné en
|
||||
`CaractèresCommeCa`).
|
||||
|
||||
- É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.
|
||||
|
||||
# Vues et décorateurs
|
||||
|
||||
Une vue ordinaire (Web) pourrait ressembler à cela. Noter la présence de
|
||||
décorateurs:
|
||||
|
||||
- `@scodoc` récupère le département (présent dans l'URL) et initialise quelques
|
||||
trucs;
|
||||
- `@permission_required`: permet de contrôler l'accès, en se basant sur les
|
||||
permissions définies dans la classe `Permission`.
|
||||
|
||||
```
|
||||
@bp.route("/un_exemple")
|
||||
@scodoc
|
||||
@permission_required(Permission.ScoChangeFormation)
|
||||
def un_exemple():
|
||||
# Récupérer le ou les arguments: exemple avec formation_id
|
||||
formation_id = int(request.args["formation_id"])
|
||||
# Charger le ou les objets utilies:
|
||||
formation = models.Formation.query.get(
|
||||
formation_id=formation_id
|
||||
).first_or_404()
|
||||
# Effectuer au besoin un traitement
|
||||
resultat = ...
|
||||
# Afficher le résultat
|
||||
return render_template(
|
||||
"exemple_template.html",
|
||||
resultat=resultat, # par exemple
|
||||
formation=formation,
|
||||
... # etc
|
||||
)
|
||||
```
|
@ -96,10 +96,42 @@ Le balisage XML est celui de [ReportLab](http://www.reportlab.com/) (intra-parag
|
||||
### Logos
|
||||
Une balise supplémentaire est interprétée par ScoDoc pour insérer des logos (images).
|
||||
|
||||
Les logos doivent être des images au format JPEG (extension `.jpg` uniquement), placées dans le répertoire `.../logos/`, et nommées `logo_xxx.jpg`.
|
||||
Les logos sont des images au format JPEG (extension `.jpg` ou `.jpeg`) ou PNG (expension `.png`), téléversés sur le serveur scodoc et intégrables dans les documents html ou pdf.
|
||||
|
||||
La balise `<logo name="xxx" width="44mm" height="22mm" valign="+5mm"/>`, placée dans un paragraphe, insère alors le logo `xxx` avec les dimensions indiquées. Le paramètre `valign` règle le positionnement vertical par rapport à la ligne de texte courante.
|
||||
Principes généraux :
|
||||
|
||||
* Un logo est désigné par un identifiant (nom) et peut être défini soit globalement, soit pour un département;
|
||||
|
||||
* le nom d'un logo est exclusiement composé de caractères alphanumériques ou du caractère '`-`';
|
||||
|
||||
* les logos définis globalement sont accessibles pour tous les départements. Toutefois, si un logo de même nom est également présent dans un département,
|
||||
, c'est le logo du département qui sera utilisé en lieu et place de logo global;
|
||||
|
||||
* les logos de nom '`header`' et '`footer`' définis globalement ne peuvent être supprimés (mais peuvent être redéfinis).
|
||||
|
||||
L'enregistrement, la modification ou la suppression d'un logo peut être réalisé via la page de configuration qui est accessible aux
|
||||
administrateurs Scodoc depuis la page d'accueil.
|
||||
|
||||
Ce formulaire comporte une section pour les définitions globales plus une section par département.
|
||||
|
||||
Une section présente la liste des logos avec leurs propriétés (la dimension est donnée à titre indicatif quand elle est disponible).
|
||||
|
||||
Pour chaque logo, les actions diponibles sont :
|
||||
|
||||
* Le remplacement de l'image existante par un nouveau fichier ;
|
||||
|
||||
* la suppression du logo (sauf pour `header`et `footer`dans la section globale) ;
|
||||
|
||||
* l'ajout d'un nouveau logo dans une section (global ou département) et indiquant le nom.
|
||||
|
||||
*NB*. Quelle que soit l'opération effectuée, le nom du fichier téléversé n'a aucune importance
|
||||
(Seul le nom indiqué dans le formulaire est pris en compte et le format du fichier est déduit des données propres du fichier)
|
||||
|
||||
La balise `<logo name="xxx" width="44mm" height="22mm" valign="+5mm"/>`, placée dans un paragraphe, insère le logo de nom `xxx` avec les dimensions indiquées.
|
||||
Le paramètre `valign` règle le positionnement vertical par rapport à la ligne de texte courante.
|
||||
|
||||
Notez qu'il est possible de ne préciser que l'une des deux dimensions hauteur ou largeur.
|
||||
Dans ce cas, la dimension manquante est déduite du ratio (rapport hauteur/largeur) de l'image originale.
|
||||
Voir un exemple d'utilisation plus bas.
|
||||
|
||||
|
||||
|
246
docs/RelationsEntreprises.md
Normal file
246
docs/RelationsEntreprises.md
Normal file
@ -0,0 +1,246 @@
|
||||
# Application "relations entreprises"
|
||||
|
||||
Cette application a pour but de permettre aux utilisateurs de retrouver et mémoriser toutes les relations entreprises dans un même endroit sous la forme d'une base interne à l'établissement.
|
||||
|
||||
Les utilisateurs interrogés insistent sur leur souhait d'avoir une interface simple et intuitive.
|
||||
|
||||
|
||||
## Principales fonctionnalités
|
||||
|
||||
L'application, intégrée à ScoDoc, fournira:
|
||||
|
||||
- Saisie et gestion des entreprises
|
||||
- Saisie et gestion des offres de stage et d'apprentissage
|
||||
- Envoi des offres aux responsables de formations
|
||||
- Historique à propos des entreprises
|
||||
- Historique des modifications des fiches entreprises
|
||||
- Journal de bord des étudiants pour suivre les candidatures
|
||||
|
||||
|
||||
## Les utilisateurs
|
||||
|
||||
- le pôle des relations extérieures (le responsable, l'assistant, les chargés de relations entreprises)
|
||||
- les secrétariats pédagogiques
|
||||
- les responsables de stage
|
||||
- les responsables de formations
|
||||
|
||||
Des actions et visibilités différentes selon le rôle de l'utilisateur (voir section "Rôles" plus loin).
|
||||
|
||||
|
||||
## Les entreprises
|
||||
|
||||
Les entreprises possèderont chacune une fiche avec toutes leurs informations.
|
||||
|
||||
Lorsqu'un utilisateur souhaite indiquer une relation avec une entreprise ou
|
||||
a été contacté par une entreprise, il pourra saisir les informations de
|
||||
l'entreprise dans la base si elle n'existe pas encore.
|
||||
Si l'entreprise existe mais que l'utilisateur veut ajouter ou corriger des infos ? Ou ajouter un "correspondant" ? Peut-être un lien vers la modification de cette entreprise.
|
||||
|
||||
|
||||
### Données sur l'entreprise:
|
||||
|
||||
- SIRET
|
||||
- Nom
|
||||
- Adresse, Code postal, Ville, Pays
|
||||
- Élements de contact (nom, prénom, numéro de téléphone, email)
|
||||
|
||||
Ces élements de contacts sont associés à une personne ou un service (par exemple "ressources humaine") au sein de l'entreprise. Il y en aura donc un nombre variable.
|
||||
|
||||
Une entreprise peut avoir plusieurs éléments de contact, il peut s'agir d'une personne physique, du service ressources humaines d'une entreprise ou d'un autre service selon la situation.
|
||||
|
||||
Les entreprises sont identifiés par leur SIRET (unique) pour éviter les duplications et doivent toujours posséder des éléments de contact sinon inexploitable par les utilisateurs.
|
||||
|
||||
Les entreprises possède un SIRET pour chaque établissement de l'entreprise ce qui le rend unique, je pense donc que le SIRET est un bon moyen d'identifier une entreprise, peut-être mettre le SIREN aussi?
|
||||
|
||||
TODO: distinguer SIRET et SIREN, pour les grandes entreprises multi-sites voir https://www.economie.gouv.fr/entreprises/numeros-siren-siret
|
||||
|
||||
(Les établissements avec le même SIREN sont présent sur la même fiche entreprise avec chacun leur adresse)
|
||||
|
||||
Un historique sur l'entreprise pour pouvoir savoir quel étudiant a déjà réalisé un stage ou un contrat d'alternance au sein de l'entreprise avec:
|
||||
- identifiant de l'étudiant INE ou ScoDoc id (`etudid`)
|
||||
- type de contrat
|
||||
- date début et fin
|
||||
- formation de l'étudiant (texte)
|
||||
- formation de l'étudiant: identifiant ScoDoc (`formsemestre_id`)
|
||||
|
||||
Un historique sur les modifications faites sur chaque fiche entreprise :
|
||||
- modification adresse
|
||||
- ajout/modification/suppression contact
|
||||
- ajout/modification/suppression offre
|
||||
|
||||
L'ajout d'entreprise envoie un mail d'alerte au pole des relations extérieures.
|
||||
|
||||
|
||||
## Les offres
|
||||
|
||||
Une entreprise peut proposer des offres.
|
||||
|
||||
Un utilisateur reçoit une offre d'une entreprise, il peut saisir l'offre dans la base qui sera ensuite affiché sur la fiche entreprise de celle ci. L'offre pourra ensuite être validé ou non par un responsable de formation s'il pense que les missions sont adéquates à la formation.
|
||||
|
||||
### Données sur les offres:
|
||||
|
||||
- Intitulé du poste
|
||||
- Présentation?
|
||||
- Type de l'offre
|
||||
- Missions
|
||||
- Durée
|
||||
|
||||
Chaque offre est reliée à une entreprise.
|
||||
|
||||
Les utilisateurs ont la possibilité d'envoyer les offres aux responsables de formations par la suite les responsables de formations diffusent l'offre au sein de leur formation.
|
||||
Les responsables de formations ne sont reliés à aucun objet. Les utilisateurs envoient l'offre aux responsables de formations s'ils pensent que l'offre correspond bien à la formation.
|
||||
|
||||
L'ajout d'une offre envoie un mail d'alerte au responsable du pole des relations extérieures.
|
||||
|
||||
|
||||
## Journal de bord
|
||||
|
||||
Journal de bord pour les étudiants afin de suivre leurs candidatures dans les offres envoyées préalablement par son responsable de formation.
|
||||
|
||||
Sur le journal de bord apparaîtra les offres que la responsable de formation a reçu et valider puis envoyer à ces étudiants. Les étudiants doit pouvoir saisir un commentaire s'il n'a candidaté a l'offre ou indiquer qu'il a candidater.
|
||||
|
||||
Les utilisateurs pourront avoir accès a ces journaux de bord pour constater l'avancée et l'implication des étudiants dans leurs candidatures.
|
||||
|
||||
Les étudiants accèdent au journal de bord en se connectant avec leur compte personnel et peuvent commenter chaque offre de stage/alternance.
|
||||
|
||||
Possibilités:
|
||||
- Oui, j'ai candidaté (quand)
|
||||
- Non, je n'ai pas candidaté (pourquoi)
|
||||
|
||||
|
||||
Permettre aux entreprises d'avoir accès au bordereau de stage afin qu'il puisse le remplir (s'il compte déjà prendre un stagiaire) ou de proposer une offre de stage.
|
||||
Un lien pour télécharger un bordereau de stage ajouté par les utilisateurs de l'application pour les entreprises.
|
||||
XXX accès des entreprises: avec quel compte (identifiant). Quand et par qui ce compte est-il créé ? Je ne sais pas encore.
|
||||
|
||||
## Rôles et actions associées
|
||||
|
||||
2 rôles avec des droits différents.
|
||||
|
||||
Utilisateur possédant un rôle avec visibilité totale et toutes les actions possibles sur la base:
|
||||
- le pôle des relations extérieures avec le responsable, son assistant et les chargés de relations entreprises;
|
||||
- administrateur informatique.
|
||||
- directeur de l'IUT?
|
||||
|
||||
Utilisateur possédant un rôle avec seulement une visibilité sur la base selon le département dont il appartient :
|
||||
- les reponsables de formations
|
||||
- les secrétariat pédagogiques
|
||||
- les chefs de département
|
||||
- le responsable administratif
|
||||
|
||||
|
||||
## Processus
|
||||
|
||||
Liste des principaux processus métiers identifiés: à préciser et compléter au cours du projet.
|
||||
|
||||
### Ajout d'une entreprise
|
||||
|
||||
- Acteur: tout personnel autorisé (le responsable et l' assistant du pôle des relations extérieures et les chargés de relations entreprises).
|
||||
- Quand: à tout moment.
|
||||
- Action: saisie des données sur une nouvelle entreprise, avec un point de contact
|
||||
- Déclenche: notification au chargés de relations entreprises (à toutes les personnes du pôle des relations extérieures).
|
||||
- Remarques: recherche d'entreprises ressemblantes pour éviter doublons.
|
||||
|
||||
### Modification d'une entreprise
|
||||
- Acteur: tout personnel autorisé (le responsable et l' assistant du pôle des relations extérieures et les chargés de relations entreprises).
|
||||
- Quand: à tout moment.
|
||||
- Action: modifie les données sur une entreprise.
|
||||
- Déclenche: ajout des modifications dans un historique visible.
|
||||
- Remarques: ...
|
||||
|
||||
### Consultation des entreprises
|
||||
- Acteur: tout personnel autorisé.
|
||||
- Quand: à tout moment.
|
||||
- Action: moteur de recherche, liste des entreprises.
|
||||
- Déclenche: rien.
|
||||
- Remarques: ...
|
||||
|
||||
### Consultation des offres
|
||||
|
||||
- Acteurs: tout personnel autorisé.
|
||||
- Quand: à tout moment.
|
||||
- Action: moteur de recherche, liste des offres de stages et d'alternance publiées.
|
||||
- Déclenche: rien.
|
||||
- Remarques: les offres devront impérativement avoir une date d'expiration pour éviter d'afficher ici des offres anciennes.
|
||||
|
||||
### Ajout d'une offre
|
||||
|
||||
- Acteurs: tout personnel autorisé (le responsable et l' assistant du pôle des relations extérieures et les chargés de relations entreprises).
|
||||
- Quand: à tout moment.
|
||||
- Action: saisie des données sur une nouvelle offre.
|
||||
- Déclenche: notification au chargés de relations entreprises (à toutes les personnes du pôle des relations extérieures).
|
||||
- Remarques: ...
|
||||
|
||||
### Validation d'une offre par un responsable de formation
|
||||
- Acteur: les responsables de formation
|
||||
- Quand: après la demande de validation d'une offre par le pôle des relations extérieures.
|
||||
- Action: valide l'ajout d'une offre.
|
||||
- Déclenche: notification au chargés de relations entreprises (à toutes les personnes du pôle des relations extérieures).
|
||||
- Remarques: si l'ajout d'une offre est non validé, elle peut être modifier par la suite
|
||||
|
||||
### Modification d'une offre
|
||||
- Acteurs: tout personnel autorisé (le responsable et l' assistant du pôle des relations extérieures et les chargés de relations entreprises).
|
||||
- Quand: à tout moment.
|
||||
- Action: modifie les données d'une offre.
|
||||
- Déclenche: ajout des modifications dans un historique visible.
|
||||
- Remarques: ...
|
||||
|
||||
### Suppression d'une offre
|
||||
- Acteurs: tout personnel autorisé (le responsable et l' assistant du pôle des relations extérieures et les chargés de relations entreprises).
|
||||
- Quand: à tout moment.
|
||||
- Action: suppression d'une offre expiré (peut-être dans d'autre cas à voir)
|
||||
- Déclenche: notification au chargés de relations entreprises (à toutes les personnes du pôle des relations extérieures).
|
||||
- Remarques: ...
|
||||
|
||||
### Envoie d'une offre à un responsable de formation
|
||||
- Acteurs: tout personnel autorisé (le responsable et l' assistant du pôle des relations extérieures et les chargés de relations entreprises).
|
||||
- Quand: à tout moment.
|
||||
- Action: envoie d'une offre a un responsable de formation.
|
||||
- Déclenche: notification au responsable de formation.
|
||||
- Remarques: ...
|
||||
|
||||
### Envoie d'une offre aux étudiants par le responsable de formation
|
||||
- Acteurs: le responsable de formation.
|
||||
- Quand: après avoir reçu une offre de la part du pôle des relations extérieures
|
||||
- Action: envoie d'une offre aux étudiants d'une formation
|
||||
- Déclenche: notification aux étudiants, ajout de l'offre dans le journal de bord des étudiants afin qu'il puisse candidater et commenter leur candidature
|
||||
- Remarques: le responsable peut envoyer l'offre à tous ces élèves ou cibler les élèves.
|
||||
|
||||
### Consultation journal de bord des étudiants
|
||||
- Acteurs: tout personnel autorisé.
|
||||
- Quand: à tout moment.
|
||||
- Action: accès aux journaux de bord par formation.
|
||||
- Déclenche: rien.
|
||||
- Remarques: ...
|
||||
|
||||
### ...
|
||||
|
||||
|
||||
## Échanges de données avec ScoDoc et autres composants du SI
|
||||
|
||||
Dans cette section, on préciser les besoins de l'appli "relations entreprises": points API avec ScoDoc et éventuellement d'autres composants du SI.
|
||||
|
||||
L'API de ScoDoc 9 étant en cours de rénovation, on précisera simplement, dans un premier temps, les besoins sans indiquer les points d'API précis. par exemple:
|
||||
- informations (dates, intitulés) sur une formation
|
||||
- informations sur les formations suivies par un étudiant identifié par son INE
|
||||
- récupérer l'id de l'utilisateur responsable d'une formation
|
||||
- ...
|
||||
|
||||
Réfléchir à l'utilisation (ou non) d'un accès à l'annuaire LDAP de l'établissement pour avoir les rôles. Une autre solution serait de se reposer sur ScoDoc pour avoir les id utilisateurs et les rôles.
|
||||
|
||||
|
||||
## Idées
|
||||
|
||||
Possibilité aux entreprises de saisir leurs offres avec validation par le pôle des relations extérieures.
|
||||
|
||||
Possibilité d'importer des données déjà existantes (Excel).
|
||||
|
||||
## Architecture de l'application
|
||||
|
||||
- Module ScoDoc (blueprint) offrant pages pour les personnels et API.
|
||||
|
||||
- Module étudiant: séparé, interfacé via API (à définir plus tard)
|
||||
|
||||
- Module entreprises: séparé, interfacé via API: à définir (plus tard ?)
|
||||
|
||||
## Questions
|
||||
|
@ -1,23 +1,43 @@
|
||||
|
||||
|
||||
# Mise en place de sauvegardes des bases de données ScoDoc 9
|
||||
Il est ***vivement recommandé*** de mettre en place une stratégie de sauvegarde permettant de rétablir le service en minimisant les pertes de données à la suite d'un accident majeur mais probable comme: crash de disque dur, bug, vol du serveur, incendie...
|
||||
Il est ***vivement recommandé*** de mettre en place une stratégie de sauvegarde
|
||||
permettant de rétablir le service en minimisant les pertes de données à la suite
|
||||
d'un accident majeur mais probable comme: crash de disque dur, bug, vol du
|
||||
serveur, incendie...
|
||||
|
||||
Nous recommandons d'agir à deux niveaux:
|
||||
|
||||
* sauvegarde des bases de données postgresql: dump des bases dans des fichiers. Le script donné ci-dessous peut se charger de gérer cela.
|
||||
* sauvegarde des bases de données postgresql: dump des bases dans des fichiers.
|
||||
Le script donné ci-dessous peut se charger de gérer cela.
|
||||
|
||||
* sauvegarde du système complet (et de ses disques durs): la forme dépend de l'environnement (machine virtuelle ou non...). Dans tous les cas, les données doivent être sauvegardées dans une salle (voire un bâtiment) différente de celle abritant le serveur ScoDoc (vols ou incendies). Typiquement, une sauvegarde quotidienne (nocturne) est suffisante.
|
||||
* sauvegarde du système complet (et de ses disques durs): la forme dépend de
|
||||
l'environnement (machine virtuelle ou non...). Dans tous les cas, les données
|
||||
doivent être sauvegardées dans une salle (voire un bâtiment) différente de
|
||||
celle abritant le serveur ScoDoc (vols ou incendies). Typiquement, une
|
||||
sauvegarde quotidienne (nocturne) est suffisante.
|
||||
|
||||
Notons que ScoDoc sauvegarde de nombreuses informations sous le répertoire `/opt/scodoc-data` (en particulier les photos, les documents archivés et divers réglages): *il est absolument nécessaire de sauvegarder aussi ce répertoire*, en plus des bases de données SQL.
|
||||
Notons que ScoDoc sauvegarde de nombreuses informations sous le répertoire
|
||||
`/opt/scodoc-data` (en particulier les photos, les documents archivés et divers
|
||||
réglages): *il est absolument nécessaire de sauvegarder aussi ce répertoire*, en
|
||||
plus des bases de données SQL.
|
||||
|
||||
|
||||
### Dump des bases de données
|
||||
Le script `backup_db9` (fourni dans le répertoire `/opt/scodoc/tools/backups`) peut être utilisé pour effectuer des sauvegardes automatisées des bases de données SQL. Les données sont extraites de la base et écrites sur le disque local du serveur, qui doit bien entendu être sauvegardé par d'autres moyens, comme indiqué ci-dessus.
|
||||
## Dump des bases de données
|
||||
Le script `backup_db9` (fourni dans le répertoire `/opt/scodoc/tools/backups`)
|
||||
peut être utilisé pour effectuer des sauvegardes automatisées des bases de
|
||||
données SQL. Les données sont extraites de la base et écrites sur le disque
|
||||
local du serveur, qui doit bien entendu être sauvegardé par d'autres moyens,
|
||||
comme indiqué ci-dessus.
|
||||
|
||||
Le script `backup_db9` permet de conserver des sauvegardes de chaque heure durant les 48 (par défaut) dernières heures, des sauvegardes quotidiennes des 40 derniers jours, hebdomadaires des 30 dernières semaines, et mensuelles des 200 derniers mois (tout ceci est paramétrable dans le script `/opt/scodoc/tools/backups/backup_rotation.sh`).
|
||||
Le script `backup_db9` permet de conserver des sauvegardes de chaque heure
|
||||
durant les 48 (par défaut) dernières heures, des sauvegardes quotidiennes des 40
|
||||
derniers jours, hebdomadaires des 30 dernières semaines, et mensuelles des 200
|
||||
derniers mois (tout ceci est paramétrable dans le script
|
||||
`/opt/scodoc/tools/backups/backup_rotation.sh`).
|
||||
|
||||
Par défaut, les fichiers de sauvegardes sont créés dans le répertoire de l'utilisateur `postgres` (actuellement `/var/lib/postgresql/`).
|
||||
Par défaut, les fichiers de sauvegardes sont créés dans le répertoire de
|
||||
l'utilisateur `postgres` (actuellement `/var/lib/postgresql/`).
|
||||
|
||||
|
||||
En tant que `root` sur le serveur, faire:
|
||||
@ -34,10 +54,14 @@ et ajouter:
|
||||
|
||||
|
||||
|
||||
### En cas de problème: restaurer la base à partir d'une sauvegarde
|
||||
## En cas de problème: restaurer la base à partir d'une sauvegarde
|
||||
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> Attention, certaines informations sont stockées dans des fichiers et non dans la base de données: configuration du logiciel, photos des étudiants. Ce paragraphe ne traite que de la restauration à de la base de données.
|
||||
|
||||
1. Choisir la sauvegarde à utiliser, en fonction de la date à partir de laquelle on a fait une erreur (eg suppression non intentionnelle d'un semestre...). Le fichier se trouve sous `/var/lib/postgresql/SCODOC-BACKUPS`où `XXX` est concerné. Utiliser par exemple `ls -lrt` pour visualiser les sauvegardes triées par date.
|
||||
1. Choisir la sauvegarde à utiliser, en fonction de la date à partir de
|
||||
laquelle on a fait une erreur (eg suppression non intentionnelle d'un
|
||||
semestre...). Le fichier se trouve sous
|
||||
`/var/lib/postgresql/SCODOC-BACKUPS`où `XXX` est concerné. Utiliser par
|
||||
exemple `ls -lrt` pour visualiser les sauvegardes triées par date.
|
||||
|
||||
1. Copier le fichier de sauvegarde choisi et le décomprimer; par exemple:
|
||||
|
||||
@ -54,22 +78,48 @@ et ajouter:
|
||||
systemctl stop scodoc9 # arret du serveur
|
||||
su postgres
|
||||
dropdb SCODOC # <<< votre base production
|
||||
pg_restore -C -d scodoc /tmp/SCODOC_pgdump # <<<
|
||||
pg_restore -C -d scodoc /tmp/XXX # (nom de la BDD en majuscule)
|
||||
exit # retour a l'utilisateur root
|
||||
systemctl start scodoc # relance ScoDoc
|
||||
systemctl start scodoc9 # relance ScoDoc
|
||||
```
|
||||
|
||||
Attention: s'il y a eu des mise à jour du logiciel entre temps, il peut arriver
|
||||
que la base sauvegardée nécessite une migration. Arrêtez le sservice scodoc9,
|
||||
que la base sauvegardée nécessite une migration. Arrêtez le service scodoc9,
|
||||
puis, en tant qu'utilisateur `scodoc`, lancer les commandes suivantes:
|
||||
|
||||
cd /opt/scodoc
|
||||
source venv/bin/activate
|
||||
flask db upgrade
|
||||
|
||||
puis relancer le service (`systemctl start scodoc` comme root).
|
||||
|
||||
puis relancer le service (`systemctl start scodoc9` comme root).
|
||||
|
||||
|
||||
## Déplacement de toute une installation
|
||||
Les scripts ci-dessus ne se chargent que de la base de données SQL.
|
||||
|
||||
Pour créer une sauvegarde complète d'une installation, vous pouvez utiliser le
|
||||
script
|
||||
|
||||
tools/save_scodoc9_data.sh /tmp/sauvegarde-scodoc.tgz
|
||||
|
||||
Ce script va générer une archive (`tar`, format `.tgz`) contenant non seulement
|
||||
la base de données SQL mais aussi tous les fichiers générés par votre ScoDoc:
|
||||
photos, configurations locales, archives, PV de jurys, logos, etc (tout ceci
|
||||
étant stocké sous `/opt/scodoc-data`).
|
||||
|
||||
Attention à l'espace disque: le répertoire destination (`/tmp`dans l'exemple
|
||||
ci-dessus) doit avoir de l'espace (sinon utilisez un autre répertoire dans
|
||||
lequel l'utilisateur `scodoc` puisse écrire, ou montez un autre disque. La
|
||||
commande `df -h`est votre amie).
|
||||
|
||||
Pour restaurer ce type de sauvegarde, sur une autre machine (ou plus tard sur la
|
||||
même), transférer le fichier généré (`/tmp/sauvegarde-scodoc.tgz`) dans
|
||||
l'exemple ci-dessus) et utiliser
|
||||
|
||||
tools/restore_scodoc9_data.sh /tmp/sauvegarde-scodoc.tgz
|
||||
|
||||
(Note: la sauvegarde s'effectue comme utilisateur `scodoc`, en revanche le
|
||||
rechargement doit se faire en tant que `root` car il faut évidemment arrêter et
|
||||
relancer le service).
|
||||
|
||||
|
||||
|
1251
docs/ScoDoc9API.md
1251
docs/ScoDoc9API.md
File diff suppressed because it is too large
Load Diff
@ -85,7 +85,7 @@ Les prochaines versions de ScoDoc (*sous réserve !*):
|
||||
- ScoDoc 9.0 : publiée le 19 sept. 2021, version complètement remaniée en
|
||||
Python 3/Flask.
|
||||
|
||||
- ScoDoc 9.1 : novembre 2021 gestion du bachelor (BUT)
|
||||
- ScoDoc 9.1 : décembre 2021 gestion du bachelor (BUT)
|
||||
- type de formation BUT
|
||||
- distinction SAE/ressources
|
||||
- poids (coefs) des évaluations, affichage, édition
|
||||
|
Loading…
Reference in New Issue
Block a user