diff --git a/docs/ApiGenerationBulletinsPdf.md b/docs/ApiGenerationBulletinsPdf.md index 4990d5e6..ef29c1a2 100644 --- a/docs/ApiGenerationBulletinsPdf.md +++ b/docs/ApiGenerationBulletinsPdf.md @@ -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). -/!\ Attention (août 2011): nouvelle version, changement d'API: les informations ci-dessous s'appliquent à partir de la subversion 1047. + 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. -/!\ 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. + 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 | | + 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 diff --git a/docs/ConfigPermissions.md b/docs/ConfigPermissions.md index 94ef8e89..ff7502b9 100644 --- a/docs/ConfigPermissions.md +++ b/docs/ConfigPermissions.md @@ -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) diff --git a/docs/ConfigPermissionsDept.md b/docs/ConfigPermissionsDept.md index cbf8fcc9..1d92c257 100644 --- a/docs/ConfigPermissionsDept.md +++ b/docs/ConfigPermissionsDept.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" diff --git a/docs/ConseilServeurDev.md b/docs/ConseilServeurDev.md index 144493fd..14b771d6 100644 --- a/docs/ConseilServeurDev.md +++ b/docs/ConseilServeurDev.md @@ -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 !): diff --git a/docs/DevInternals.md b/docs/DevInternals.md index c98260c1..4ef9b39a 100644 --- a/docs/DevInternals.md +++ b/docs/DevInternals.md @@ -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"]) diff --git a/docs/GuideDeveloppeurs.md b/docs/GuideDeveloppeurs.md index f2613776..c95c4245 100644 --- a/docs/GuideDeveloppeurs.md +++ b/docs/GuideDeveloppeurs.md @@ -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 diff --git a/docs/ScoDoc9API.md b/docs/ScoDoc9API.md index 2264246a..cef1e27c 100644 --- a/docs/ScoDoc9API.md +++ b/docs/ScoDoc9API.md @@ -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/` * **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/` * **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/` * **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=` @@ -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//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//role//remove[/departement/]` * **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 diff --git a/docs/UpgradeToDeb12Sco96.md b/docs/UpgradeToDeb12Sco96.md index cae2ca2f..1981911b 100644 --- a/docs/UpgradeToDeb12Sco96.md +++ b/docs/UpgradeToDeb12Sco96.md @@ -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 diff --git a/docs/samples/sample_role-add_permission.json.md b/docs/samples/sample_role-add_permission.json.md index 56c5dba3..54425d14 100644 --- a/docs/samples/sample_role-add_permission.json.md +++ b/docs/samples/sample_role-add_permission.json.md @@ -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" diff --git a/docs/samples/sample_role-create.json.md b/docs/samples/sample_role-create.json.md index de0d54f6..b45b358e 100644 --- a/docs/samples/sample_role-create.json.md +++ b/docs/samples/sample_role-create.json.md @@ -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" diff --git a/docs/samples/sample_role-remove_permission.json.md b/docs/samples/sample_role-remove_permission.json.md index c3cfcfaf..70d744f3 100644 --- a/docs/samples/sample_role-remove_permission.json.md +++ b/docs/samples/sample_role-remove_permission.json.md @@ -1,6 +1,6 @@ ### role-remove_permission -#### POST /role/customRole/remove_permission/ScoUsersView +#### POST /role/customRole/remove_permission/UsersView ```json { "id": 13, diff --git a/docs/samples/sample_role.json.md b/docs/samples/sample_role.json.md index 12e2408b..9c08afd8 100644 --- a/docs/samples/sample_role.json.md +++ b/docs/samples/sample_role.json.md @@ -5,7 +5,7 @@ { "id": 1, "permissions": [ - "ScoObservateur" + "Observateur" ], "role_name": "Observateur" } diff --git a/docs/samples/sample_roles.json.md b/docs/samples/sample_roles.json.md index 491c3a5b..52a73953 100644 --- a/docs/samples/sample_roles.json.md +++ b/docs/samples/sample_roles.json.md @@ -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"