Update roles/permissions + autres détails
This commit is contained in:
parent
a57dd34bf9
commit
1154040ceb
|
|
@ -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.
|
||||
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/)).
|
||||
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/)).
|
||||
|
||||
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).
|
||||
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.
|
||||
<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`
|
||||
|
||||
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):
|
||||
```
|
||||
#!python
|
||||
# -*- mode: python -*-
|
||||
# -*- coding: utf-8 -*-
|
||||
Voici un module minimal commenté (le fichier `sco_bulletins_example.py` est
|
||||
fournit avec ScoDoc):
|
||||
|
||||
```py
|
||||
"""Génération d'un bulletin de note style "Exemple"
|
||||
(commentaire libre ici)
|
||||
"""
|
||||
|
|
@ -47,7 +54,7 @@ class [BulletinGeneratorExample](BulletinGeneratorExample.md)(sco_bulletins_stan
|
|||
# .bul_part_below(self, format=*) : infos sous la table
|
||||
# .bul_signatures_pdf(self) : signatures
|
||||
|
||||
def bul_table(self, format=*):
|
||||
def bul_table(self, fmt=*):
|
||||
"""Défini la partie centrale de notre bulletin PDF.
|
||||
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):
|
||||
sco_bulletins_generator.register_bulletin_class(BulletinGeneratorExample)
|
||||
# Déclarer votre classe à ScoDoc
|
||||
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:
|
||||
```
|
||||
#!python
|
||||
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:
|
||||
|
||||
```py
|
||||
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`:
|
||||
```
|
||||
#!python
|
||||
|
||||
```py
|
||||
def gen_part_below(self, format=*):
|
||||
"""Génère les informations placées sous la table de notes
|
||||
(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
|
||||
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.
|
||||
### 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).
|
||||
|
||||
## 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). .
|
||||
Exemple: `infos['SCOLAR_FONT_SIZE']` est un entier, `infos['UnivName']` est le
|
||||
nom de l'université.
|
||||
|
||||
|
||||
### 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
|
||||
### Informations sur l'étudiant
|
||||
|
||||
#### 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:**
|
||||
|
||||
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 | evalcomplete | | True
|
||||
| evaluation_id | id interne | 'EVAL15226'
|
||||
bool | evalattente | | False
|
||||
bool | evalcomplete | | True
|
||||
| evaluation_id | id interne | 15226
|
||||
list | gr_incomplets | | []
|
||||
list | gr_moyennes | | []
|
||||
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 | moy | note moyenne promo | '11.00'
|
||||
| nb_abs | nb étudiants absents | 0
|
||||
|
|
|
|||
|
|
@ -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... | | |
|
||||
-----------------------------|--------------|--------|---------|
|
||||
**`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.
|
||||
|
||||
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
|
||||
* Il pourra créer des utilisateurs uniquement dans le département GEII
|
||||
* il pourra ajouter ou retirer les rôles EnsGEII, SecrGEII, AdminGEII à tout utilisateur de scodoc
|
||||
* il pourra ajouter ou retirer les rôles EnsCJ, SecrCJ, AdminCJ à tout utilisateur de scodoc
|
||||
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.
|
||||
|
||||
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).
|
||||
|
||||
!!! 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)
|
||||
|
|
|
|||
|
|
@ -1,14 +1,12 @@
|
|||
# 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
|
||||
relations entreprises):
|
||||
|
||||
- Administrateur
|
||||
- Secrétariat
|
||||
- Enseignant
|
||||
- Observateur
|
||||
|
||||
* Administrateur
|
||||
* Secrétariat
|
||||
* Enseignant
|
||||
* Observateur
|
||||
|
||||
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
|
||||
|
|
@ -16,16 +14,15 @@ définition des programmes, ...).
|
|||
|
||||
## Exemple
|
||||
|
||||
L'utilisateur 'Dupont' est responsable ScoDoc pour son département *RT* mais
|
||||
intervient également en enseignement au département *GEII*.
|
||||
On pourra lui attribuer les rôles `AdminRT` et `EnsGEII`, ce qui lui permettra :
|
||||
L'utilisateur *Dupont* est responsable ScoDoc pour son département *RT* mais
|
||||
intervient également en enseignement au département *GEII*. On pourra lui
|
||||
attribuer les rôles `Admin_RT` et `Ens_GEII`, ce qui lui permettra :
|
||||
|
||||
- de gérer les utilisateurs du (seul) département RT :
|
||||
Privilèges associés : `Gérer les utlisateurs (Sco Users Manage)`, `Changer les
|
||||
formations (Sco Change Formation)`, ...
|
||||
- d'accéder aux vues enseignant pour le département GEII :
|
||||
Privilèges associés : `Voir les parties pour les enseignants (Sco View Ens)`,
|
||||
`Saisir des absences (Sco Change Absences)`, ...
|
||||
* de gérer les utilisateurs du (seul) département RT :
|
||||
Privilèges associés : `Gérer les utilisateurs`, `Changer les formations`, ...
|
||||
* d'accéder aux vues enseignant pour le département GEII :
|
||||
Privilèges associés : `Voir les parties pour les enseignants`,
|
||||
`Saisir des absences`, ...
|
||||
|
||||
Pour une description plus fine des permissions, voir
|
||||
[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").
|
||||
|
||||
* `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
|
||||
|
||||
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:
|
||||
|
||||
* 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 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"
|
||||
|
||||
|
|
|
|||
|
|
@ -5,12 +5,12 @@ Quelques indications pour développer avec ScoDoc, à adapter à vos goûts et o
|
|||
Commencez par lire
|
||||
[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
|
||||
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
|
||||
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`).
|
||||
|
||||
### Noms des machines
|
||||
|
||||
Modifier le `/etc/hosts` (ou équivalent) de l'hôte, et y ajouter l'IP de votre
|
||||
VM, par exemple (adapter l'IP !):
|
||||
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ décorateurs:
|
|||
```
|
||||
@bp.route("/un_exemple")
|
||||
@scodoc
|
||||
@permission_required(Permission.ScoChangeFormation)
|
||||
@permission_required(Permission.EditFormation)
|
||||
def un_exemple():
|
||||
# Récupérer le ou les arguments: exemple avec formation_id
|
||||
formation_id = int(request.args["formation_id"])
|
||||
|
|
|
|||
|
|
@ -130,6 +130,18 @@ Pour régénérer le fichier indiquant la liste des paquets:
|
|||
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.
|
||||
|
||||
## Roadmap
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
Cependant si, par l'API, on veut effectuer des opérations de modification ou
|
||||
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
|
||||
`permission`de chaque entrée vous donnera la permission requise pour chaque
|
||||
opération.
|
||||
|
|
@ -1082,7 +1082,7 @@ d'un autre).
|
|||
#### **roles**
|
||||
|
||||
* **Méthode:** GET
|
||||
* **Permission: `ScoUsersView`**
|
||||
* **Permission: `UsersView`**
|
||||
* **Routes:** `/roles`
|
||||
* **Exemple d'utilisation:** `/roles`
|
||||
* **Résultat:** Liste de tous les rôles.
|
||||
|
|
@ -1091,7 +1091,7 @@ d'un autre).
|
|||
#### **role**
|
||||
|
||||
* **Méthode:** GET
|
||||
* **Permission: `ScoUsersView`**
|
||||
* **Permission: `UsersView`**
|
||||
* **Routes:** `/role/<str:role_name>`
|
||||
* **Exemple d'utilisation:** `/role/Ens`
|
||||
* **Résultat:** Liste le rôle indiqué. 404 si inexistant.
|
||||
|
|
@ -1125,7 +1125,7 @@ d'un autre).
|
|||
* **Routes:** `/role/create/<str:role_name>`
|
||||
* **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.
|
||||
* **Exemple de résultat:** [role-create.json](samples/sample_role-create.json.md)
|
||||
|
|
@ -1157,7 +1157,7 @@ d'un autre).
|
|||
#### **user**
|
||||
|
||||
* **Méthode:** GET
|
||||
* **Permission: `ScoUsersView`**
|
||||
* **Permission: `UsersView`**
|
||||
* **Paramètres:** `user_id`
|
||||
* **Route:** `/user/<int:user_id>`
|
||||
* **Exemple d'utilisation:** `/api/user/1`
|
||||
|
|
@ -1167,7 +1167,7 @@ d'un autre).
|
|||
#### **`user-create`**
|
||||
|
||||
* **Méthode: POST**
|
||||
* **Permission: `ScoUsersAdmin`**
|
||||
* **Permission: `UsersAdmin`**
|
||||
* **Data:**
|
||||
|
||||
```json
|
||||
|
|
@ -1189,7 +1189,7 @@ d'un autre).
|
|||
#### **`users-query`**
|
||||
|
||||
* **Méthode:** GET
|
||||
* **Permission: `ScoUsersView`**
|
||||
* **Permission: `UsersView`**
|
||||
* **Routes:**
|
||||
|
||||
* `/users/query?departement=dept_acronym&active=1&starts_with=<str:nom>`
|
||||
|
|
@ -1202,7 +1202,7 @@ d'un autre).
|
|||
#### **`user-edit`**
|
||||
|
||||
* **Méthode: POST**
|
||||
* **Permission: `ScoUsersAdmin`**
|
||||
* **Permission: `UsersAdmin`**
|
||||
* **Data:**
|
||||
|
||||
```json
|
||||
|
|
@ -1221,7 +1221,7 @@ d'un autre).
|
|||
#### **`user-password`**
|
||||
|
||||
* **Méthode: POST**
|
||||
* **Permission: `ScoUsersAdmin`**
|
||||
* **Permission: `UsersAdmin`**
|
||||
* **Data:** `{ "password": str }`
|
||||
* **Routes:** `/user/<int:uid>/password`
|
||||
* **Exemple d'utilisation:** `/user/3/password`
|
||||
|
|
@ -1254,7 +1254,7 @@ d'un autre).
|
|||
#### **`user-role-remove`**
|
||||
|
||||
* **Méthode: POST**
|
||||
* **Permission: `ScoUsersAdmin`**
|
||||
* **Permission: `UsersAdmin`**
|
||||
* **Routes:** `/user/<int:uid>/role/<str:role_name>/remove[/departement/<string:dept_acronym>]`
|
||||
* **Résultat:** Retire le rôle à l'utilisateur.
|
||||
* **Exemple de résultat:** [user-role-remove.json](samples/sample_user-role-remove.json.md)
|
||||
|
|
@ -1262,7 +1262,7 @@ d'un autre).
|
|||
#### **`permissions`**
|
||||
|
||||
* **Méthode:** GET
|
||||
* **Permission: `ScoUsersView`**
|
||||
* **Permission: `UsersView`**
|
||||
* **Routes:** `/permissions`
|
||||
* **Résultat:** Liste des noms des permissions. Ces permissions ne sont pas
|
||||
modifiables, mais de nouvelles peuvent apparaitre lors des mises à jour du
|
||||
|
|
|
|||
|
|
@ -107,10 +107,17 @@ et si besoin le stopper avec :
|
|||
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
|
||||
peut servir: [Debian 12 et proxmox](https://www.abyssproject.net/2023/07/retex-sur-mes-upgrades-vers-debian-12-et-proxmox-ve-8)
|
||||
Si votre installation utilise des containers LXC/proxmox: on nous a signalé un
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
### role-add_permission
|
||||
|
||||
#### POST /role/customRole/add_permission/ScoUsersView
|
||||
#### POST /role/customRole/add_permission/UsersView
|
||||
```json
|
||||
{
|
||||
"id": 13,
|
||||
"permissions": [
|
||||
"ScoUsersView",
|
||||
"UsersView",
|
||||
"ScoView"
|
||||
],
|
||||
"role_name": "customRole"
|
||||
|
|
|
|||
|
|
@ -3,13 +3,13 @@
|
|||
#### POST /role/create/customRole
|
||||
> `Content-Type: application/json`
|
||||
>
|
||||
> `{"permissions": ["ScoView", "ScoUsersView"]}`
|
||||
> `{"permissions": ["ScoView", "UsersView"]}`
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 13,
|
||||
"permissions": [
|
||||
"ScoUsersView",
|
||||
"UsersView",
|
||||
"ScoView"
|
||||
],
|
||||
"role_name": "customRole"
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
### role-remove_permission
|
||||
|
||||
#### POST /role/customRole/remove_permission/ScoUsersView
|
||||
#### POST /role/customRole/remove_permission/UsersView
|
||||
```json
|
||||
{
|
||||
"id": 13,
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
{
|
||||
"id": 1,
|
||||
"permissions": [
|
||||
"ScoObservateur"
|
||||
"Observateur"
|
||||
],
|
||||
"role_name": "Observateur"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
{
|
||||
"id": 1,
|
||||
"permissions": [
|
||||
"ScoObservateur"
|
||||
"Observateur"
|
||||
],
|
||||
"role_name": "Observateur"
|
||||
},
|
||||
|
|
@ -17,9 +17,9 @@
|
|||
"ScoEtudAddAnnotations",
|
||||
"ScoAbsAddBillet",
|
||||
"ScoAbsChange",
|
||||
"ScoUsersView",
|
||||
"ScoObservateur",
|
||||
"ScoEnsView",
|
||||
"UsersView",
|
||||
"Observateur",
|
||||
"EnsView",
|
||||
"ScoView"
|
||||
],
|
||||
"role_name": "Ens"
|
||||
|
|
|
|||
Loading…
Reference in New Issue