iziram/DocAssiduites
1
0
Fork 0
forked from ScoDoc/DocScoDoc
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update roles/permissions + autres détails

Browse Source
This commit is contained in:
Emmanuel Viennet 2023-09-30 10:06:15 +02:00
parent a57dd34bf9
commit 1154040ceb
13 changed files with 230 additions and 226 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

158
docs/ApiGenerationBulletinsPdf.md
View File

@ -1,28 +1,35 @@
# Générer des bulletins en Python # Générer des bulletins en Python
Il est possible de coder de nouveaux styles de bulletins de notes (web et/ou PDF), pour répondre précisément aux besoins de votre établissement.
Ce n'est pas très difficile, mais il faudra coder en langage Python avec pour le PDF la bibliothèque ReportLab (qui est bien documentée, [voir le guide](http://www.reportlab.com/software/opensource/rl-toolkit/guide/)). Il est possible de coder de nouveaux styles de bulletins de notes (web et/ou
PDF), pour répondre précisément aux besoins de votre établissement.
ScoDoc demande la création d'un bulletin pour un étudiant donné dans semestre donné (`formsemestre_id`). Ce n'est pas très difficile, mais il faudra coder en langage Python avec pour le
Le bulletin doit être rendu sous forme d'une liste d'objets PLATYPUS (voir le chapitre 5 du "User Guide" de ReportLab cité plus haut). PDF la bibliothèque ReportLab (qui est bien documentée, [voir le
guide](http://www.reportlab.com/software/opensource/rl-toolkit/guide/)).
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> Attention (août 2011): nouvelle version, changement d'API: les informations ci-dessous s'appliquent à partir de la subversion 1047. ScoDoc demande la création d'un bulletin pour un étudiant donné dans semestre
donné (`formsemestre_id`). Le bulletin doit être rendu sous forme d'une liste
d'objets PLATYPUS (voir le chapitre 5 du "User Guide" de ReportLab cité plus
haut).
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
alt="/!\" /> Attention (août 2011): nouvelle version, changement d'API: les
informations ci-dessous s'appliquent à partir de la subversion 1047.
## Organisation ## Organisation
A minima, il vous faut créer un module python (fichier .py) qui se définira une classe chargée de générer vos bulletins.
A minima, il vous faut créer un module python (fichier .py) qui se définira une
classe chargée de générer vos bulletins.
Ce fichier doit être placé dans le répertoire `/opt/scodoc/instance/Products/ScoDoc` Ce fichier doit être placé dans le répertoire `/opt/scodoc/instance/Products/ScoDoc`
Il faut aussi l'importer dans `sco_bulletins_generator.py` (voir tout à la fin de ce fichier). Il faut aussi l'importer dans `sco_bulletins_generator.py` (voir tout à la fin
de ce fichier).
Voici un module minimal commenté (le fichier `sco_bulletins_example.py` est fournit avec ScoDoc): Voici un module minimal commenté (le fichier `sco_bulletins_example.py` est
``` fournit avec ScoDoc):
#!python
# -*- mode: python -*-
# -*- coding: utf-8 -*-
```py
"""Génération d'un bulletin de note style "Exemple" """Génération d'un bulletin de note style "Exemple"
(commentaire libre ici) (commentaire libre ici)
""" """
@ -47,7 +54,7 @@ class [BulletinGeneratorExample](BulletinGeneratorExample.md)(sco_bulletins_stan
# .bul_part_below(self, format=*) : infos sous la table # .bul_part_below(self, format=*) : infos sous la table
# .bul_signatures_pdf(self) : signatures # .bul_signatures_pdf(self) : signatures
def bul_table(self, format=*): def bul_table(self, fmt=*):
"""Défini la partie centrale de notre bulletin PDF. """Défini la partie centrale de notre bulletin PDF.
Doit renvoyer une liste d'objets PLATYPUS Doit renvoyer une liste d'objets PLATYPUS
""" """
@ -58,23 +65,27 @@ class [BulletinGeneratorExample](BulletinGeneratorExample.md)(sco_bulletins_stan
) )
] ]
# Déclarer votre classe à [ScoDoc](ScoDoc.md): # Déclarer votre classe à ScoDoc
sco_bulletins_generator.register_bulletin_class(BulletinGeneratorExample) sco_bulletins_generator.register_bulletin_class(BulletinGeneratorExample)
``` ```
Si l'on voulait générer aussi du HTML (pour la version web), il suffirait de le déclarer dans la liste `supported_formats` et que la méthode `bul_table()` renvoie une chaîne HTML si le paramètre format vaut `'html'`. Si l'on voulait générer aussi du HTML (pour la version web), il suffirait de le
déclarer dans la liste `supported_formats` et que la méthode `bul_table()`
renvoie une chaîne HTML si le paramètre `fmt` vaut `'html'`.
Pour modifier l'en-tête du bulletin PDF (partie au dessus de la table), il faut surcharger la méthode `bul_title_pdf` qui elle aussi renvoie une liste d'objets PLATYPUS: Pour modifier l'en-tête du bulletin PDF (partie au dessus de la table), il faut
``` surcharger la méthode `bul_title_pdf` qui elle aussi renvoie une liste d'objets
#!python PLATYPUS:
```py
def bul_title_pdf(self): def bul_title_pdf(self):
... ...
``` ```
De même, les informations placées sous la table principale sont renvoyées par la méthode `gen_part_below`: De même, les informations placées sous la table principale sont renvoyées par la méthode `gen_part_below`:
```
#!python ```py
def gen_part_below(self, format=*): def gen_part_below(self, format=*):
"""Génère les informations placées sous la table de notes """Génère les informations placées sous la table de notes
(absences, appréciations, décisions de jury...) (absences, appréciations, décisions de jury...)
@ -85,76 +96,47 @@ De même, les informations placées sous la table principale sont renvoyées par
... ...
``` ```
et les signatures (seulement sur le PDF) par `bul_signatures_pdf`. Toutes ces méthodes renvoient des listes d'objets PLATYPUS quelconques. et les signatures (seulement sur le PDF) par `bul_signatures_pdf`. Toutes ces
méthodes renvoient des listes d'objets PLATYPUS quelconques.
Vous pouvez partir d'un format de bulletin existant et proche de ce que voulez obtenir et définir une sous-classe modifiant (surchargeant) seulement les méthodes qui génèrent les éléments que vous voulez modifier. Vous pouvez partir d'un format de bulletin existant et proche de ce que voulez
obtenir et définir une sous-classe modifiant (surchargeant) seulement les
méthodes qui génèrent les éléments que vous voulez modifier.
<img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;" alt="/!\" /> Attention: ne pas modifier après coup le nom des classes de générateurs (ici `BulletinGeneratorExample`), car il va être stocké en base de données par ScoDoc. <img src="/img/alert.png" style="vertical-align: bottom; margin:0 0 0 0;"
alt="/!\" /> Attention: ne pas modifier après coup le nom des classes de
générateurs (ici `BulletinGeneratorExample`), car il va être stocké en base de
données par ScoDoc.
## Accès aux informations
La plupart des informations nécessaires sont accessibles via des attributs de
votre instance de générateur que ScoDoc aura positionné avant d'appeler vos
méthodes. Notamment:
* `self.formsemestre`: l'objet `FormSemestre`
* `self.infos`: un (grand) dictionnaire python avec la plupart des informations
préparée pour le bulletin à générer (voir plus loin);
* `self.version`: indique la version de bulletin demandée par l'utilisateur
("long" ou "short", vous pouvez en faire ce que bon vous semble);
## Le dictionnaire d'informations
L'attribut `infos` est un dictionnaire qui contient de très nombreuses
informations. il doit être utilisé en **lecture seule** (il est possible que des
informations soient partagées entre threads différents, aussi les modifier peut
avoir des effets indésirables). .
## Accès aux informations ### Paramètres (préférences)
La plupart des informations nécessaires sont accessibles via des attributs de votre instance de générateur que ScoDoc aura positionné avant d'appeler vos méthodes. Notamment:
* `self.infos`: un (grand) dictionnaire python avec la plupart des informations préparée pour le bulletin à générer (voir plus loin);
* `self.version`: indique la version de bulletin demandée par l'utilisateur ("long" ou "short", vous pouvez en faire ce que bon vous semble);
* `self.context`: contexte ScoDoc, permettant l'accès à l'API complète.
Tous les paramètres du semestre sont accessibles via leur nom. Voir la liste sur
la page [NomsPreferences](NomsPreferences.md).
## Le dictionnaire d'informations Exemple: `infos['SCOLAR_FONT_SIZE']` est un entier, `infos['UnivName']` est le
L'attribut `infos` est un dictionnaire qui contient de très nombreuses informations. il doit être utilisé en **lecture seule** (il est possible que des informations soient partagées entre threads différents, aussi les modifier peut avoir des effets indésirables). . nom de l'université.
### Informations sur l'étudiant
### Paramètres (préférences)
Tous les paramètres du semestre sont accessibles via leur nom. Voir la liste sur la page [NomsPreferences](NomsPreferences.md).
Exemple: `infos['SCOLAR_FONT_SIZE']` est un entier, `infos['UnivName']` est le nom de l'université.
### Informations sur le semestre
Un semestre est représenté par un dictionnaire avec les attributs
suivants:
Type | Nom | Description | Exemple de valeur
----| --- | ---- | ---
int |semestre_id| Indice dans le parcours | 1
string |titre| | 'DUT GEII'
string |titre_num| | 'DUT GEII, semestre 1'
string |titreannee| | 'DUT GEII, semestre 1 FI 2011'
string |titremois| | 'DUT GEII, semestre 1 FI (Mars 2011 - Jul 2011)'
string |annee_debut| | '2011'
string |annee_fin| | '2011'
| anneescolaire| | '2010 - 2011'
string |date_debut| | '09/03/2011'
| date_debut_iso| | '2011-03-09'
| date_fin| | '31/07/2011'
| date_fin_iso| | '2011-07-31'
| dateord| | '2011-03-09'
| mois_debut| | 'Mars 2011'
int |mois_debut_ord| | 3
| mois_fin| | 'Jul 2011'
int |mois_fin_ord| | 7
string |modalite| | 'FI'
string |etape_apo| Code étape Apogée | 'V1TR2'
string |etape_apo2| Code étape Apogée (si 2 codes) | *
string |etat| verrouillé ('0') ou non ('1') | '1'
| formation_id| id interne de la formation | 'FORM14570'
| formsemestre_id| id interne du semestre | 'SEM15176'
string |gestion_compensation| | '0'
string |gestion_semestrielle| | '0'
string |responsable_id| | 'viennet'
int {0,1} |ens_can_edit_eval| | 0
int {0,1}|resp_can_change_ens| | 0
int {0,1} |resp_can_edit| | 0
string |bul_bgcolor| | *
string |bul_hide_xml| | '0'
Pour le semestre à traiter, ces attributs sont directement dans `infos`.
On trouve aussi dans `infos['etud']` tous les semestres par lesquels
est passé l'étudiant.
### Informations sur l'étudiant
#### Identité #### Identité
@ -377,17 +359,17 @@ Le module (tel que décrit dans le programme de la formation) est représenté p
**Etat d'une évaluation:** **Etat d'une évaluation:**
Le champ `etat` d'une évaluation ets un dict donnant des informations sur les résultats de la promo (et des groupes) dans cette évaluation: Le champ `etat` d'une évaluation est un dict donnant des informations sur les résultats de la promo (et des groupes) dans cette évaluation:
Type | Nom | Description | Exemple de valeur Type | Nom | Description | Exemple de valeur
----| --- | ---- | --- ----| --- | ---- | ---
bool | evalattente | | False bool | evalattente | | False
bool | evalcomplete | | True bool | evalcomplete | | True
| evaluation_id | id interne | 'EVAL15226' | evaluation_id | id interne | 15226
list | gr_incomplets | | [] list | gr_incomplets | | []
list | gr_moyennes | | [] list | gr_moyennes | | []
list | groups | liste des groupes | {} list | groups | liste des groupes | {}
datetime | last_modif | | <mx.DateTime.DateTime object> datetime | last_modif | | datetime
string | median | note médianne promo | '11.00' string | median | note médianne promo | '11.00'
string | moy | note moyenne promo | '11.00' string | moy | note moyenne promo | '11.00'
| nb_abs | nb étudiants absents | 0 | nb_abs | nb étudiants absents | 0

143
docs/ConfigPermissions.md
View File

@ -1,96 +1,83 @@
# Rôles définis dans l'installation standard # Rôles et permissions définis dans l'installation standard
🚧 *cette page est ancienne et à revoir*. La page [ConfigPermissionsDept](ConfigPermissionsDept.md) introduit les notions
de rôles et de permissions.
Voir aussi sur les rôles et leur utilisation la page [ConfigPermissionsDept](ConfigPermissionsDept.md) Ci-dessous la liste des permissions, qui est utile notamment pour les
utilisateurs de l'API.
Les informations ci-dessous ne sont utiles que pour les développeurs ou pour des usages avancés de ScoDoc. ## Liste des permissions
## Principales permissions et fonctions associées * **AbsAddBillet** : Saisir des billets d'absences
* **AbsChange** : Saisir des absences
* **AbsJustifView** : Visualisation des fichiers justificatifs
* **EditAllEvals** : Modifier toutes les évaluations
* **EditAllNotes** : Modifier toutes les notes
* **EditApogee** : Gérer les exports Apogée
* **EditFormSemestre** : Mettre en place une formation (créer un semestre)
* **EditFormation** : Changer les formations
* **EditFormationTags** : Tagguer les formations
* **EditPreferences** : Modifier les préférences
* **EnsView** : Voir les parties pour les enseignants
* **EtudAddAnnotations** : Éditer les annotations
* **EtudChangeAdr** : Changer les adresses d'étudiants
* **EtudChangeGroups** : Modifier les groupes
* **EtudInscrit** : Inscrire des étudiants
* **Observateur** : Observer (accès lecture restreint aux bulletins)
* **RelationsEntrepEdit** : Modifier les entreprises
* **RelationsEntrepExport** : Exporter les données de l'application relations entreprises
* **RelationsEntrepSend** : Envoyer des offres
* **RelationsEntrepValidate** : Valide les entreprises
* **RelationsEntrepView** : Voir l'application relations entreprises
* **RelationsEntrepViewCorrs** : Voir les correspondants
* **ScoSuperAdmin** : Super Administrateur
* **ScoView** : Voir
* **UsersAdmin** : Gérer les utilisateurs (de son département)
* **UsersChangeCASId** : Paramétrer l'id CAS
* **UsersView** : Voir les utilisateurs (de tous les départements)
### Liste des permissions Zope ## Rôles
Les permissions utilisées par ScoDoc ont des noms qui commencent par "Sco", de façon à les grouper dans l'interface de Zope (ZMI), qui est peu pratique. Les rôles peuvent êtres associés à un nombre quelconque de permissions.
Pour changer ces permissions (plus précisément pour associer les permissions à des rôles), aller dans l'onglet "Security" du dossier "Dept" (celui qui *contient* l'instance de ScoDoc, habituellement nommée "Scolarite"). ScoDoc définit un certain nombre de rôles *standards* (`Ens`, `Secr`, ...) mais
l'administrateur peut facilement définir de nouveaux rôles et leur associer un
ensemble de permissions.
Voici les permissions utilisées: ## Gestion des utilisateurs
* **Sco View** : voir les pages de ScoDoc (à réserver aux enseignants et administratifs)
* **Sco View Ens** : voir les parties réservées aux enseignants (à l'exclusion des secrétariats)
* **Sco Modifier toutes notes** : modifier toutes les notes (dans tous les semestres)
* **Sco Modifier toutes les evaluations** : créer/modifier/supprimer des évaluations dans tous les semestres (mais pas saisir des notes)
* **Sco Change Formation** : créer/modifier/supprimer des formations (programmes pédagogiques)
* **Sco Implement Formation** : mettre en place des semestres (sessions) de formation
* **Sco Change Absences** : saisir des absences
* **Sco Change Etud Address** : changer les adresses des étudiants
* **Sco Change Etud Groups** : changer les groupes des étudiants
* **Sco Inscrire Etud** : inscrire des étudiants
* **Sco Etud Add Annotations** : ajouter des annotations sur les étudiants
* **Sco View Entreprises** : accéder au fichier d'entreprises
* **Sco Change Entreprises** : modifier le fichier d'entreprises
* **Sco Users Admin** : voir et modifier les utilisateurs ScoDoc
* **Sco Users View** : voir les utilisateurs ScoDoc
* **Sco Change Preferences** : modifier les préférences du département
* **Sco Super Admin** : réservé à l'administrateur (création de départements)
Pour la liste à jour des permissions et leur nom complet, et les associations initiales rôles/permissions, voir le fichier `sco_permissions.py` dans les sources.
### Rôles associés à chaque permission dans chaque département
Les rôles listés ici sont ceux définis dans chaque département (`Admin` réfère donc à l'`AdminXXX` du département `XXX`, à ne pas confondre avec l'utilisateur `admin`).
Permission |  Rôles... | | &nbsp; |
-----------------------------|--------------|--------|---------|
**`ScoView`** | `Ens` | `Secr` | `Admin` |
**`ScoEnsView`** | `Ens` | | `Admin` |
**`ScoUsersView`** | `Ens` | `Secr` | `Admin` |
**`ScoEtudAddAnnotations`** | `Ens` | `Secr` | `Admin` |
**`ScoAbsChange`** | `Ens` | `Secr` | `Admin` |
**`ScoEntrepriseView`** | `Ens` | `Secr` | `Admin` |
**`ScoEntrepriseChange`** | | `Secr` | `Admin` |
**`ScoEtudChangeAdr`** | | `Secr` | `Admin` |
**`ScoChangeFormation`** | | | `Admin` |
**`ScoEditAllNotes`** | | | `Admin` |
**`ScoEditAllEvals`** | | | `Admin` |
**`ScoImplement`** | | | `Admin` |
**`ScoEtudChangeGroups`** | | | `Admin` |
**`ScoEtudInscrit`** | | | `Admin` |
**`ScoUsersAdmin`** | | | `Admin` |
**`ScoChangePreferences`** | | | `Admin` |
## Gestion des utilisateurs
Les utilisateurs sont associés à un département principal et à des rôles. Les utilisateurs sont associés à un département principal et à des rôles.
Le fait d'être, ou non, associé à un département est important: Le fait d'être, ou non, associé à un département est important:
* pour tous les utilisateurs: hormis le SuperAdmin, seuls les administrateurs du département d'appartenance sont habilités à modifier les caractéristiques principales (nom, prenom, email, mot de passe) de cet utilsateur
* pour les responsables (rôle `AdminXXX`. En effet, si le responsable est associé à un département, *il ne pourra créer des utilisateurs que dans ce département*
(c'est en général ce qu'on veut pour un chef de département, qui "recrute" des enseignant uniquement dans son département).
Pour la gestion des rôles, l'administrateur d'un département peut ajouter ou supprimer les rôles *de ce département* à n'importe quel utilisateur, y compris à ceux qui ne sont pas du même département * pour tous les utilisateurs: hormis le SuperAdmin, seuls les administrateurs du
département d'appartenance sont habilités à modifier les caractéristiques
principales (nom, prenom, email, mot de passe) de cet utilisateur.
* pour les responsables (rôle `Admin_XXX`). En effet, si le responsable est
associé à un département, *il ne pourra créer des utilisateurs que dans ce
département* (c'est en général ce qu'on veut pour un chef de département, qui
"recrute" des enseignant uniquement dans son département).
Exemple: si PAUL est du département GEII et a les rôles AdminGEII et AdminCJ Pour la gestion des rôles, l'administrateur d'un département peut ajouter ou
* Il pourra créer des utilisateurs uniquement dans le département GEII supprimer les rôles *de ce département* à n'importe quel utilisateur, y compris
* il pourra ajouter ou retirer les rôles EnsGEII, SecrGEII, AdminGEII à tout utilisateur de scodoc à ceux qui ne sont pas du même département.
* il pourra ajouter ou retirer les rôles EnsCJ, SecrCJ, AdminCJ à tout utilisateur de scodoc
Exemple: si Paul est du département GEII et a les rôles `Admin_GEII` et `Admin_CJ`
* Il pourra *créer* des utilisateurs *uniquement dans son département d'origine*, GEII;
* Il pourra ajouter ou retirer les rôles `Ens_GEII`, `Secr_GEII`, `Admin_GEII` à tout
utilisateur de ScoDoc;
* Il pourra ajouter ou retirer les rôles `Ens_CJ`, `Secr_CJ`, `Admin_CJ` à tout
utilisateur de ScoDoc.
Plus d'informations techniques sur la page [AdminUsers](AdminUsers.md). Plus d'informations techniques sur la page [AdminUsers](AdminUsers.md).
!!! note "Voir aussi"
- [Introduction aux rôles et permissions](ConfigPermissionsDept.md)
- [Gestion des utilisateurs](AdminUsers.md)
- [Config. des rôles et permissions en ligne de commande](GuideConfig.md#creation-dun-nouveau-role)
- [Guide administrateur ScoDoc](GuideAdminSys.md)
- [FAQ](FAQ.md)
- [Contacts](Contact.md)

73
docs/ConfigPermissionsDept.md
View File

@ -1,14 +1,12 @@
# Rôles et permissions dans ScoDoc # Rôles et permissions dans ScoDoc
ScoDoc défini par défaut quatre rôles principaux (d'autres sont prévus,
notamment pour le module relations entreprises):
ScoDoc défini par défaut quatre rôles principaux (d'autres sont prévus, notamment pour le module * Administrateur
relations entreprises): * Secrétariat
* Enseignant
- Administrateur * Observateur
- Secrétariat
- Enseignant
- Observateur
Par ailleurs, le contexte d'utilisation donne certains privilèges (par exemple Par ailleurs, le contexte d'utilisation donne certains privilèges (par exemple
la faculté de saisir des notes, de justifier des absences, de modifier la la faculté de saisir des notes, de justifier des absences, de modifier la
@ -16,16 +14,15 @@ définition des programmes, ...).
## Exemple ## Exemple
L'utilisateur 'Dupont' est responsable ScoDoc pour son département *RT* mais L'utilisateur *Dupont* est responsable ScoDoc pour son département *RT* mais
intervient également en enseignement au département *GEII*. intervient également en enseignement au département *GEII*. On pourra lui
On pourra lui attribuer les rôles `AdminRT` et `EnsGEII`, ce qui lui permettra : attribuer les rôles `Admin_RT` et `Ens_GEII`, ce qui lui permettra :
- de gérer les utilisateurs du (seul) département RT : * de gérer les utilisateurs du (seul) département RT :
Privilèges associés : `Gérer les utlisateurs (Sco Users Manage)`, `Changer les Privilèges associés : `Gérer les utilisateurs`, `Changer les formations`, ...
formations (Sco Change Formation)`, ... * d'accéder aux vues enseignant pour le département GEII :
- d'accéder aux vues enseignant pour le département GEII : Privilèges associés : `Voir les parties pour les enseignants`,
Privilèges associés : `Voir les parties pour les enseignants (Sco View Ens)`, `Saisir des absences`, ...
`Saisir des absences (Sco Change Absences)`, ...
Pour une description plus fine des permissions, voir Pour une description plus fine des permissions, voir
[ConfigPermissions](ConfigPermissions.md). [ConfigPermissions](ConfigPermissions.md).
@ -34,34 +31,52 @@ Pour une description plus fine des permissions, voir
`XXX` désigne typiquement le nom du département ("RT" ou "GEA"). `XXX` désigne typiquement le nom du département ("RT" ou "GEA").
* `AdminXXX`: toutes opérations ScoDoc (chef de département, et éventuellement un ou deux collaborateurs de confiance); * `Admin_XXX`: toutes opérations ScoDoc (chef de département, et éventuellement
un ou deux collaborateurs de confiance);
* `EnsXXX`: enseignant du département; * `Ens_XXX`: enseignant du département;
* `SecrXXX`: secrétaire du département. * `Secr_XXX`: secrétaire du département.
L'installation standard défini aussi un utilisateur "*admin*", qui a le rôle "Manager", ce qui lui confère normalement tous les droits sur toutes les parties du site. L'usage de cet utilisateur particulier devrait être réduit à la création de nouveaux départements, et son mot de passe ne devrait pas être divulgué aux utilisateurs de ScoDoc. L'installation standard défini aussi un utilisateur "*admin*", qui a le rôle
"Manager", ce qui lui confère normalement tous les droits sur toutes les parties
du site. L'usage de cet utilisateur particulier devrait être réduit à la
création de nouveaux départements, et son mot de passe ne devrait pas être
divulgué aux utilisateurs de ScoDoc.
Les utilisateurs sont associés à des rôles et à un (et un seul) département principal. Les utilisateurs sont associés à des rôles et à un (et un seul) département
principal.
Un utilisateur peut avoir un nombre quelconque de rôles dans différents départements. Un utilisateur peut avoir un nombre quelconque de rôles dans différents
départements.
Le département de rattachement est utile pour indiquer qui (quel administrateur) a le droit de modifier l'utilisateur (lui changer son mot de passe, etc), mais n'influe pas sur les permissions accordées à l'utilisateur (sauf pour les administrateurs). Le département de rattachement est utile pour indiquer qui (quel administrateur)
a le droit de modifier l'utilisateur (lui changer son mot de passe, etc), mais
n'influe pas sur les permissions accordées à l'utilisateur (sauf pour les
administrateurs).
Le fait d'être, ou non, associé à un département est important pour les responsables (rôle `AdminXXX`. En effet, si le responsable est associé à un département, il ne pourra créer des utilisateurs que dans ce département (c'est en général ce qu'on veut pour un chef de département, qui "recrute" des enseignant uniquement dans son département). Le fait d'être, ou non, associé à un département est important pour les
responsables (rôle `Admin_XXX`. En effet, si le responsable est associé à un
département, il ne pourra créer des utilisateurs que dans ce département (c'est
en général ce qu'on veut pour un chef de département, qui "recrute" des
enseignant uniquement dans son département).
## Permissions dépendantes du contexte ## Permissions dépendantes du contexte
Outre les rôles associés à chaque utilisateur, le calcul des autorisations dépend du contexte de l'opération. Par exemple, un responsable de semestre a des droits particulier sur ce semestre, ou encore un responsable de module sur la saisie des notes dans ce module. Outre les rôles associés à chaque utilisateur, le calcul des autorisations
dépend du contexte de l'opération. Par exemple, un responsable de semestre a des
droits particulier sur ce semestre, ou encore un responsable de module sur la
saisie des notes dans ce module.
### Qui peut saisir des notes ? ### Qui peut saisir des notes ?
Peuvent saisir des notes dans une évaluation située dans un module: Peuvent saisir des notes dans une évaluation située dans un module:
* le ou les administrateurs (rôle `AdminXXX`, où `XXX` est le département); * le ou les administrateurs (rôle `Admin_XXX`, où `XXX` est le département);
* le responsable du semestre (directeur des études); * le responsable du semestre (directeur des études);
* le responsable du module; * le responsable du module;
* les enseignants "associés" au module (en général des collègues désignés par le responsable de module ou le directeur des études). * les enseignants "associés" au module (en général des collègues désignés par le
responsable de module ou le directeur des études).
!!! note "Voir aussi" !!! note "Voir aussi"

5
docs/ConseilServeurDev.md
View File

@ -5,12 +5,12 @@ Quelques indications pour développer avec ScoDoc, à adapter à vos goûts et o
Commencez par lire Commencez par lire
[Installation du code pour les développeurs](https://scodoc.org/git/ScoDoc/ScoDoc#pour-les-d%C3%A9veloppeurs) [Installation du code pour les développeurs](https://scodoc.org/git/ScoDoc/ScoDoc#pour-les-d%C3%A9veloppeurs)
# Machine virtuelle ## Machine virtuelle
Il est confortable de développer dans une VM (un container Docker ferait Il est confortable de développer dans une VM (un container Docker ferait
aussi bien l'affaire). aussi bien l'affaire).
## Conseils pour la machine virtuelle ### Conseils pour la machine virtuelle
[VirtualBox](https://www.virtualbox.org/) est facile à installer sur Linux ou [VirtualBox](https://www.virtualbox.org/) est facile à installer sur Linux ou
Windows. Créer une VM avec Debian 10, et suivre la [procédure habituelle Windows. Créer une VM avec Debian 10, et suivre la [procédure habituelle
@ -73,6 +73,7 @@ avec connexion permanente, vous pouvez dans Debian activer cette interface
constamment (modifier `/etc/network/interfaces`). constamment (modifier `/etc/network/interfaces`).
### Noms des machines ### Noms des machines
Modifier le `/etc/hosts` (ou équivalent) de l'hôte, et y ajouter l'IP de votre Modifier le `/etc/hosts` (ou équivalent) de l'hôte, et y ajouter l'IP de votre
VM, par exemple (adapter l'IP !): VM, par exemple (adapter l'IP !):

2
docs/DevInternals.md
View File

@ -55,7 +55,7 @@ décorateurs:
``` ```
@bp.route("/un_exemple") @bp.route("/un_exemple")
@scodoc @scodoc
@permission_required(Permission.ScoChangeFormation) @permission_required(Permission.EditFormation)
def un_exemple(): def un_exemple():
# Récupérer le ou les arguments: exemple avec formation_id # Récupérer le ou les arguments: exemple avec formation_id
formation_id = int(request.args["formation_id"]) formation_id = int(request.args["formation_id"])

12
docs/GuideDeveloppeurs.md
View File

@ -130,6 +130,18 @@ Pour régénérer le fichier indiquant la liste des paquets:
pip freeze > requirements-3.11.txt pip freeze > requirements-3.11.txt
``` ```
Enfin, pour mettre à jour les paquets pip, il faut dégeler les versions (unpin)
puis upgrader et re-générer le fichier, comme suit:
```bash
cp requirements-3.11.txt requirements.text
sed -i 's/[~=]=/>=/' requirements.txt
pip install -U -r requirements.txt
pip freeze > requirements-new.txt
# et si tout va bien
mv requirements-new.txt requirements-3.11.txt
```
Note: la mise à jour par `apt` recrée le virtualenv à chaque fois. Note: la mise à jour par `apt` recrée le virtualenv à chaque fois.
## Roadmap ## Roadmap

22
docs/ScoDoc9API.md
View File

@ -41,7 +41,7 @@ Les droits à accorder dépendent des fonctionnalités nécessaires. la permissi
`ScoView` est généralement suffisante car elle permet toutes les consultations. `ScoView` est généralement suffisante car elle permet toutes les consultations.
Cependant si, par l'API, on veut effectuer des opérations de modification ou Cependant si, par l'API, on veut effectuer des opérations de modification ou
encore consulter les comptes utilisateurs, d'autres droits (`ScoChangeGroups`, encore consulter les comptes utilisateurs, d'autres droits (`ScoChangeGroups`,
`ScoUsersView`, `ScoSuperAdmin`, ...) peuvent être requis. La consultation du `UsersView`, `ScoSuperAdmin`, ...) peuvent être requis. La consultation du
[tableau récapitulatif](#tableau-recapitulatif-des-entrees-de-lapi) ou la ligne [tableau récapitulatif](#tableau-recapitulatif-des-entrees-de-lapi) ou la ligne
`permission`de chaque entrée vous donnera la permission requise pour chaque `permission`de chaque entrée vous donnera la permission requise pour chaque
opération. opération.
@ -1082,7 +1082,7 @@ d'un autre).
#### **roles** #### **roles**
* **Méthode:** GET * **Méthode:** GET
* **Permission: `ScoUsersView`** * **Permission: `UsersView`**
* **Routes:** `/roles` * **Routes:** `/roles`
* **Exemple d'utilisation:** `/roles` * **Exemple d'utilisation:** `/roles`
* **Résultat:** Liste de tous les rôles. * **Résultat:** Liste de tous les rôles.
@ -1091,7 +1091,7 @@ d'un autre).
#### **role** #### **role**
* **Méthode:** GET * **Méthode:** GET
* **Permission: `ScoUsersView`** * **Permission: `UsersView`**
* **Routes:** `/role/<str:role_name>` * **Routes:** `/role/<str:role_name>`
* **Exemple d'utilisation:** `/role/Ens` * **Exemple d'utilisation:** `/role/Ens`
* **Résultat:** Liste le rôle indiqué. 404 si inexistant. * **Résultat:** Liste le rôle indiqué. 404 si inexistant.
@ -1125,7 +1125,7 @@ d'un autre).
* **Routes:** `/role/create/<str:role_name>` * **Routes:** `/role/create/<str:role_name>`
* **Exemple d'utilisation:** `/role/create/LaveurDecarreaux` * **Exemple d'utilisation:** `/role/create/LaveurDecarreaux`
> `{ "permissions" : [ 'ScoView', 'ScoUsersView' ] }` > `{ "permissions" : [ 'ScoView', 'UsersView' ] }`
* **Résultat:** Crée un nouveau rôle, avec les permissions indiquées. * **Résultat:** Crée un nouveau rôle, avec les permissions indiquées.
* **Exemple de résultat:** [role-create.json](samples/sample_role-create.json.md) * **Exemple de résultat:** [role-create.json](samples/sample_role-create.json.md)
@ -1157,7 +1157,7 @@ d'un autre).
#### **user** #### **user**
* **Méthode:** GET * **Méthode:** GET
* **Permission: `ScoUsersView`** * **Permission: `UsersView`**
* **Paramètres:** `user_id` * **Paramètres:** `user_id`
* **Route:** `/user/<int:user_id>` * **Route:** `/user/<int:user_id>`
* **Exemple d'utilisation:** `/api/user/1` * **Exemple d'utilisation:** `/api/user/1`
@ -1167,7 +1167,7 @@ d'un autre).
#### **`user-create`** #### **`user-create`**
* **Méthode: POST** * **Méthode: POST**
* **Permission: `ScoUsersAdmin`** * **Permission: `UsersAdmin`**
* **Data:** * **Data:**
```json ```json
@ -1189,7 +1189,7 @@ d'un autre).
#### **`users-query`** #### **`users-query`**
* **Méthode:** GET * **Méthode:** GET
* **Permission: `ScoUsersView`** * **Permission: `UsersView`**
* **Routes:** * **Routes:**
* `/users/query?departement=dept_acronym&active=1&starts_with=<str:nom>` * `/users/query?departement=dept_acronym&active=1&starts_with=<str:nom>`
@ -1202,7 +1202,7 @@ d'un autre).
#### **`user-edit`** #### **`user-edit`**
* **Méthode: POST** * **Méthode: POST**
* **Permission: `ScoUsersAdmin`** * **Permission: `UsersAdmin`**
* **Data:** * **Data:**
```json ```json
@ -1221,7 +1221,7 @@ d'un autre).
#### **`user-password`** #### **`user-password`**
* **Méthode: POST** * **Méthode: POST**
* **Permission: `ScoUsersAdmin`** * **Permission: `UsersAdmin`**
* **Data:** `{ "password": str }` * **Data:** `{ "password": str }`
* **Routes:** `/user/<int:uid>/password` * **Routes:** `/user/<int:uid>/password`
* **Exemple d'utilisation:** `/user/3/password` * **Exemple d'utilisation:** `/user/3/password`
@ -1254,7 +1254,7 @@ d'un autre).
#### **`user-role-remove`** #### **`user-role-remove`**
* **Méthode: POST** * **Méthode: POST**
* **Permission: `ScoUsersAdmin`** * **Permission: `UsersAdmin`**
* **Routes:** `/user/<int:uid>/role/<str:role_name>/remove[/departement/<string:dept_acronym>]` * **Routes:** `/user/<int:uid>/role/<str:role_name>/remove[/departement/<string:dept_acronym>]`
* **Résultat:** Retire le rôle à l'utilisateur. * **Résultat:** Retire le rôle à l'utilisateur.
* **Exemple de résultat:** [user-role-remove.json](samples/sample_user-role-remove.json.md) * **Exemple de résultat:** [user-role-remove.json](samples/sample_user-role-remove.json.md)
@ -1262,7 +1262,7 @@ d'un autre).
#### **`permissions`** #### **`permissions`**
* **Méthode:** GET * **Méthode:** GET
* **Permission: `ScoUsersView`** * **Permission: `UsersView`**
* **Routes:** `/permissions` * **Routes:** `/permissions`
* **Résultat:** Liste des noms des permissions. Ces permissions ne sont pas * **Résultat:** Liste des noms des permissions. Ces permissions ne sont pas
modifiables, mais de nouvelles peuvent apparaitre lors des mises à jour du modifiables, mais de nouvelles peuvent apparaitre lors des mises à jour du

13
docs/UpgradeToDeb12Sco96.md
View File

@ -107,10 +107,17 @@ et si besoin le stopper avec :
systemctl stop scodoc9 systemctl stop scodoc9
``` ```
## En cas de problème avec proxmox ## Problème avec proxmox
Pour l'instant on ne nous a pas signalé de problèmes, mais au cas où ce lien Si votre installation utilise des containers LXC/proxmox: on nous a signalé un
peut servir: [Debian 12 et proxmox](https://www.abyssproject.net/2023/07/retex-sur-mes-upgrades-vers-debian-12-et-proxmox-ve-8) problème de compatibilité proxmox / Debian 12, qui bloque le service REDIS
(voire empêche le démarrage du container). Il semblerait que proxmox 7 ne soit
pas compatible avec Debian 12. Faites des essais avant de migrer ScoDoc.
Au cas où ce lien peut servir: [Debian 12 et
proxmox](https://www.abyssproject.net/2023/07/retex-sur-mes-upgrades-vers-debian-12-et-proxmox-ve-8)
Merci de vos retours si vous avez des informations sur ce problème.
## Upgrade Postgresql ## Upgrade Postgresql

4
docs/samples/sample_role-add_permission.json.md
View File

@ -1,11 +1,11 @@
### role-add_permission ### role-add_permission
#### POST /role/customRole/add_permission/ScoUsersView #### POST /role/customRole/add_permission/UsersView
```json ```json
{ {
"id": 13, "id": 13,
"permissions": [ "permissions": [
"ScoUsersView", "UsersView",
"ScoView" "ScoView"
], ],
"role_name": "customRole" "role_name": "customRole"

4
docs/samples/sample_role-create.json.md
View File

@ -3,13 +3,13 @@
#### POST /role/create/customRole #### POST /role/create/customRole
> `Content-Type: application/json` > `Content-Type: application/json`
> >
> `{"permissions": ["ScoView", "ScoUsersView"]}` > `{"permissions": ["ScoView", "UsersView"]}`
```json ```json
{ {
"id": 13, "id": 13,
"permissions": [ "permissions": [
"ScoUsersView", "UsersView",
"ScoView" "ScoView"
], ],
"role_name": "customRole" "role_name": "customRole"

2
docs/samples/sample_role-remove_permission.json.md
View File

@ -1,6 +1,6 @@
### role-remove_permission ### role-remove_permission
#### POST /role/customRole/remove_permission/ScoUsersView #### POST /role/customRole/remove_permission/UsersView
```json ```json
{ {
"id": 13, "id": 13,

2
docs/samples/sample_role.json.md
View File

@ -5,7 +5,7 @@
{ {
"id": 1, "id": 1,
"permissions": [ "permissions": [
"ScoObservateur" "Observateur"
], ],
"role_name": "Observateur" "role_name": "Observateur"
} }

8
docs/samples/sample_roles.json.md
View File

@ -6,7 +6,7 @@
{ {
"id": 1, "id": 1,
"permissions": [ "permissions": [
"ScoObservateur" "Observateur"
], ],
"role_name": "Observateur" "role_name": "Observateur"
}, },
@ -17,9 +17,9 @@
"ScoEtudAddAnnotations", "ScoEtudAddAnnotations",
"ScoAbsAddBillet", "ScoAbsAddBillet",
"ScoAbsChange", "ScoAbsChange",
"ScoUsersView", "UsersView",
"ScoObservateur", "Observateur",
"ScoEnsView", "EnsView",
"ScoView" "ScoView"
], ],
"role_name": "Ens" "role_name": "Ens"