| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente |
| fonctionnalites:geonature:developpements-prioritaires [2020/10/13 15:41] – [Courriels liés aux demandes de permissions] jpmilcent | fonctionnalites:geonature:developpements-prioritaires [2021/02/15 09:47] (Version actuelle) – [Tableau] jpmilcent |
|---|
| ==== Courriels liés aux demandes de permissions ==== | ==== Courriels liés aux demandes de permissions ==== |
| |
| === Demande de droit - Administrateur === | === Demande de permissions - Administrateur === |
| Lors de toute nouvelle demande, un email sera envoyé aux administrateur. Son contenu aura la forme suivante : <code> | Lors de toute nouvelle demande, un email sera envoyé aux administrateur. Son contenu aura la forme suivante : <code> |
| Bonjour, | Bonjour, |
| L'utilisateur <Prénom> <NOM> (<organisme>) vient d'effectuer une demande de permissions d'accès à GeoNature : <adresse-web> | L'utilisateur <Prénom> <NOM> (<organisme>) vient d'effectuer une demande de permissions d'accès à GeoNature : <adresse-web> |
| Voici les permissions demandées : | Voici les permissions demandées : |
| - Accès aux observations privés précises : oui | - Accès aux observations privées précises : oui |
| - Accès aux observations sensibles précises : <oui-ou-non> [champ paramétrable selon le SINP régional] | - Accès aux observations sensibles précises : <oui-ou-non> [champ paramétrable selon le SINP régional] |
| Accès limités par : | Accès limités par : |
| //Notes techniques// : les infos seront stockées dans une table ("temp_users" => à renommer, si possible) du schéma "//utilisateurs//" de la base de données. | //Notes techniques// : les infos seront stockées dans une table ("temp_users" => à renommer, si possible) du schéma "//utilisateurs//" de la base de données. |
| |
| ==== Gestion des demandes de permissions ==== | ===== Gestion des demandes de permissions ===== |
| La gestion des demandes de permissions aura lieu dans l'outil GeoNature et va demander une refonte de l'interface du sous-module "//Administration des permissions//" présent dans le module "//Admin//". | La gestion des demandes de permissions aura lieu dans l'outil GeoNature et va demander une refonte de l'interface du sous-module "//Administration des permissions//" présent dans le module "//Admin//". |
| Les administrateurs de GeoNature seront prévenus de la nouvelle demande par l'envoi d'un courriel. Ce dernier contiendra un lien pour accéder directement à l'interface permettant d'accepter/refuser la demande.\\ | Les administrateurs de GeoNature seront prévenus de la nouvelle demande par l'envoi d'un courriel. Ce dernier contiendra un lien pour accéder directement à l'interface permettant d'accepter/refuser la demande.\\ |
| L'acceptation/refus de la demande de permissions générera un courriel automatique à destination de l'utilisateur. | L'acceptation/refus de la demande de permissions générera un courriel automatique à destination de l'utilisateur. |
| |
| === Modifications de l'interface « Administration des permissions » === | ==== Modifications de l'interface « Administration des permissions » ==== |
| Cette interface de validation des demandes de permissions se trouvera dans //GeoNature//, module « //Admin// ». Un menu « //Gestion des permissions// » proposera 2 menus principaux : | Cette interface de validation des demandes de permissions se trouvera dans //GeoNature//, module « //Admin// ». Un menu « //Administration des permissions// » proposera 2 menus principaux : |
| * **Permissions** : gestion des permissions par utilisateur et groupe. | * **Permissions** : gestion des permissions par utilisateur et groupe. |
| * **Demandes** : gestion des demandes de permissions à l'initiative des utilisateurs. L’affichage de ce menu sera rendu paramétrable via le fichier de configuration de GeoNature. | * **Demandes** : gestion des demandes de permissions à l'initiative des utilisateurs. L’affichage de ce menu sera rendu paramétrable via le fichier de configuration de GeoNature. |
| * //permission// : le terme permission sera préféré à « droit » car il est moins générique. | * //permission// : le terme permission sera préféré à « droit » car il est moins générique. |
| |
| === Menu : Permissions === | ==== Menu : Permissions ==== |
| L'interface de gestion des permissions contiendra un tableau des utilisateurs et groupes intitulé « Permissions des utilisateurs et groupes » avec les champs : | L'interface de gestion des permissions contiendra un tableau des utilisateurs et groupes intitulé « Permissions des utilisateurs et groupes » avec les champs : |
| * //ID// : identifiant de l'utilisateur ou du groupe présent dans la table ''t_roles''. | * //ID// : identifiant de l'utilisateur ou du groupe présent dans la table ''t_roles''. |
| * //Actions// : contiendra un bouton avec un icône permettant d’accéder à liste des permissions affectées. | * //Actions// : contiendra un bouton avec un icône permettant d’accéder à liste des permissions affectées. |
| |
| Ce tableau pourra être paginé et filtré. | Ce tableau pourra être paginé et filtré. Par défaut, le tableau sera trié par //Type// avec les groupes en premier, puis le trie s'effectuera sur le champ //Nom//. Les lignes des groupes auront un fond coloré distinct de celui des utilisateurs. |
| |
| L'interface de consultation des permissions d'un utilisateur ou groupe contiendra une liste paginée de permissions classées par module. La présentation sera semblable à l'interface du module Métadonnées. Elle aura pour titre « <nom> -Permissions relatives aux modules ». Un bouton « Ajouter un droit » sera présent au dessus de la liste. Cette interface étant chargé dans une nouvelle page, un bouton « Retour » en haut à gauche permettra de revenir sur l'interface précédente. | L'interface de consultation des permissions d'un utilisateur ou groupe contiendra une liste paginée de permissions classées par module. La présentation sera semblable à l'interface du module Métadonnées. Elle aura pour titre « <nom> -Permissions relatives aux modules ». Un bouton « Ajouter une permission » sera présent au dessus de la liste. Cette interface étant chargé dans une nouvelle page, un bouton « Retour » en haut à gauche permettra de revenir sur l'interface précédente. |
| Dans la liste, un clic sur un nom de module permettra de dérouler la liste des permissions qui s'affichera avec les champs suivant : | Dans la liste, un clic sur un nom de module permettra de dérouler la liste des permissions qui s'affichera avec les champs suivant : |
| * //Droit// : nom du droit correspondant à l'association du verbe du //CRUVED// et de sa ressource. | * //Droit// : nom du droit correspondant à l'association du verbe du //CRUVED// et de sa ressource. |
| * //Date de fin// : date à laquelle le droit prend fin. Vide si toujours actif. | * //Date de fin// : date à laquelle le droit prend fin. Vide si toujours actif. |
| * //Action// : | * //Action// : |
| * un bouton icône de suppression permettra de supprimer le droit après avoir validé une fenêtre modale de confirmation. | * un bouton icône de suppression permettra de supprimer la permission après avoir validé une boite de dialogue de confirmation. |
| * un bouton icône de modification permettra d'accéder à l'interface de modification d'un droit. | * un bouton icône de modification permettra d'accéder à l'interface de modification d'une permission. |
| |
| L'interface de modification/ajout de permissions se basera sur la nouvelle table ''cor_module_action_object_filter''. L'interface contiendra un assistant fournissant progressivement l'accès à des champs en fonction des choix précédents et des options disponibles dans la table ''cor_module_action_object_filter''. Les champs seront : | L'interface de modification/ajout de permissions se basera sur la nouvelle table ''cor_module_action_object_filter''. L'interface contiendra un assistant fournissant progressivement l'accès à des champs en fonction des choix précédents et des options disponibles dans la table ''cor_module_action_object_filter''. Les champs seront : |
| * //Bouton "Enregistrer"// : permet d'ajouter le droit à la table ''cor_role_action_filter_module_object'' et de retourner à l'interface précédente ("Permissions relatives aux modules"). | * //Bouton "Enregistrer"// : permet d'ajouter le droit à la table ''cor_role_action_filter_module_object'' et de retourner à l'interface précédente ("Permissions relatives aux modules"). |
| |
| === Menu : Demandes === | ==== Menu : Demandes ==== |
| L'interface possédera un titre « Demande de permissions ». Au dessous, 2 onglets contiendront des tableaux paginés des demandes de permissions d'accès aux données géo-confidentielles : | L'interface possédera un titre « Demande de permissions d'accès ». Au dessous, 2 onglets contiendront des tableaux paginés des demandes de permissions d'accès aux données géo-confidentielles : |
| * //En attentes// : demandes en attente. | * //En attentes// : demandes en attente. |
| * //Traitées// : demandes acceptées ou refusées. | * //Traitées// : demandes acceptées ou refusées. |
| * //Raison// : ce champ contiendra le commentaire laissé par l'administrateur suite au traitement. | * //Raison// : ce champ contiendra le commentaire laissé par l'administrateur suite au traitement. |
| |
| L'interface de consultation détaillée de la demande, intitulée « Détail demande de permissions - <Prénom> <NOM> (<Organisme>) », affichera dans le formulaire de demande de permissions d'accès avec des champs de saisie désactivés les informations saisie par l'utilisateur. | L'interface de consultation détaillée de la demande, intitulée « Détail demande de permissions - <Prénom> <NOM> (<Organisme>) », affichera l'ensemble des informations saisie par l'utilisateur. Une fois traitée par un administrateur des informations complémentaires pourront y être mentionné (raison du refus). |
| | |
| Si la demande n'a pas encore été traité les boutons « Accepter » et « Refuser » seront présent au bas de l'interface. | |
| |
| Si la demande a été traitée, un seul bouton permettant d'inverser la décision sera présent. | Si la demande n'a pas encore été traitée une bouton "Définir le statut" sera affichée dans l'entête de l'interface de consultation détaillée. Il permettra d’accéder à un menu avec 2 choix « Accepter » et « Refuser ». Ces menus auront le même fonctionnement que les boutons icônes du tableau des demandes « En attentes ». |
| | Si la demande a été traitée, le bouton (nommé "Changer le statut") permettra d'inverser la décision ou de "Placer en attente" la demande. La mise en attente d'une demande comme le refus implique une suppression des permissions associés. |
| |
| Dans ces 2 derniers cas, les boutons auront le même fonctionnement que les boutons icônes du tableau des demandes « En attentes ». | Lors du changement de statut d'une demande un email sera automatiquement envoyé à l'utilisateur pour le prévenir du changement de statut de sa demande. |
| | |
| === Modifications envisagées dans la base de données GeoNature === | ==== Modifications envisagées dans la base de données GeoNature ==== |
| Les permissions permettant d’accéder aux données géo-confidentielles nécessitent des modifications dans la base de données. À priori, les modifications envisagées sont : | Les permissions permettant d’accéder aux données géo-confidentielles nécessitent des modifications dans la base de données. À priori, les modifications envisagées sont : |
| * Schéma ''gn_permissions'' : | * Schéma ''gn_permissions'' : |
| * Ajout d'une table '' t_requests ''permettant de stocker les demandes d'accès, les informations liées à la motivation de cette demande (description du projet, type d'étude, durée...) et leur acceptation/refus (date). | * Ajout d'une table '' t_requests ''permettant de stocker les demandes d'accès, les informations liées à la motivation de cette demande (description du projet, type d'étude, durée...) et leur acceptation/refus (date). |
| * Modification de la table ''cor_role_action_filter_module_object'' | * Modification de la table ''cor_role_action_filter_module_object'' |
| * Ajout d'un champ ''group'' permettant de cumuler des filtres pour un même droit (Ex. : Accès aux observations sensibles pour le taxon X et la commune Y). | * Ajout d'un champ ''gathering'' permettant de cumuler des filtres pour un même droit (Ex. : Accès aux observations sensibles pour le taxon X et la commune Y). |
| * Ajout d'un champ ''end_date'' permettant d'indiquer une date de fin au droit. Si NULL pas de fin prévu au droit. | * Ajout d'un champ ''end_date'' permettant d'indiquer une date de fin au droit. Si NULL pas de fin prévu au droit. |
| * Remplacement du champ ''id_filter'' par ''id_filter_type'' et ajout du champ complémentaire ''value_filter''. Le champ ''value_filter'' sera type ''varchar'' et pourra contenir un id, une chaîne ou autre en fonction du type de filtre. Nous créerons autant d’enregistrements que nécessaire pour éviter de devoir stocker plusieurs valeurs dans ce champs. Les valeurs possibles en fonction du type de filtre sont les suivantes : | * Remplacement du champ ''id_filter'' par ''id_filter_type'' et ajout du champ complémentaire ''value_filter''. Le champ ''value_filter'' sera type ''text'' et pourra contenir un id, une chaîne ou autre en fonction du type de filtre. Nous créerons autant d’enregistrements que nécessaire pour éviter de devoir stocker plusieurs valeurs dans ce champs. Les valeurs possibles en fonction du type de filtre sont les suivantes : |
| * SCOPE [nombre entier] : 0 (= aucune donnée), 1 (= mes donénes), 2 (= données de mon organisme) ou 3 (=toutes les données). | * SCOPE [nombre entier] : 0 (= aucune donnée), 1 (= mes données), 2 (= données de mon organisme) ou 3 (=toutes les données). |
| * SENSITIVITY [booléen] : "true" ou "false". | * <del>SENSITIVITY [booléen]</del> PRECISION [chaine de caractère] : "//fuzzy//" (=flou) ou "exact" (=précis). |
| * TAXONOMIC [nombre entier, chaine de caractère] : le nombre entier correspond au ''cd_nom'' de la table ''ref_taxonomy.taxref'' ; la chaine de caractère à un nom de taxon non présent dan la base. | * TAXONOMIC [nombre entier, chaine de caractère] : le nombre entier correspond au ''cd_nom'' de la table ''ref_taxonomy.taxref''. La chaine de caractère correspond à une liste de ''cd_nom'' séparés par des virgules. |
| * GEOGRAPHIC [nombre entier, chaine de caractère, géométrie] : le nombre entier correspond au ''id_area'' de la table ''ref_geo.l_area'' ; la chaine de caractère à un nom de zone géographique non présente dan la base ; la géométrie correspond à une zone dessiné depuis une carte ou l'import d'un fichier. | * GEOGRAPHIC [nombre entier, chaine de caractère, géométrie] : le nombre entier correspond au ''id_area'' de la table ''ref_geo.l_area'' ; la chaine de caractère à une de ''id_area'' séparés par des virgules ; la géométrie correspond à une zone dessiné depuis une carte ou l'import d'un fichier. |
| |
| * Pour chaque demande de permissions des nouvelles lignes seront à ajouter dans cette table. | * Pour chaque demande de permissions des nouvelles lignes seront à ajouter dans cette table. |
| * géométrie précise [G] (= aucun floutage) | * géométrie précise [G] (= aucun floutage) |
| * commune [C] | * commune [C] |
| * maille 10x10km [M] | * maille 10x10km [M] (Pour Silene, un floutage par maille 5x5km est demandé) |
| * département [D] | * département [D] |
| |
| Ces champs seront pré-calculés et un //trigger// les maintiendra à jour. Ils contiendront un id provenant la table ''ref_geo.l_areas''. Les informations (dont la géométrie) de la table ''ref_geo.l_areas'' seront ensuite utilisées pour l'affichage dans les différents types d'interface listés ci-dessus. Il sera peut-être nécessaire de rajouter un champ à la table ''ref_geo.l_areas'' qui contiendra la géométrie au format SRID 4326. | Ces champs seront pré-calculés et un //trigger// les maintiendra à jour. Ils contiendront un id provenant la table ''ref_geo.l_areas''. Les informations (dont la géométrie) de la table ''ref_geo.l_areas'' seront ensuite utilisées pour l'affichage dans les différents types d'interface listés ci-dessus. Il sera peut-être nécessaire de rajouter un champ à la table ''ref_geo.l_areas'' qui contiendra la géométrie au format SRID 4326. |
| |
| Tableau du type d'objet géographique utilisé en fonction des critères de géo-confidentialité : | Tableau du type d'objet géographique utilisé en fonction des critères de géo-confidentialité ([[Mise à jour des valeurs de sensibilité du 4 février 2021|https://github.com/PnX-SI/Nomenclature-api-module/issues/39#issuecomment-773492258]]): |
| ^ Type ^ Sensibilité (id_nomenclature_sensitivity) ^ Obs. Privée - Niveau de diffusion (id_nomenclature_diffusion_level) ^ | ^ Type ^ Sensibilité (id_nomenclature_sensitivity) ^ Obs. Privée - Niveau de diffusion (id_nomenclature_diffusion_level) ^ |
| | - | 0 | 5 | | | Précision max. | 0 ou NULL/vide | 5 ou NULL/vide | |
| | Commune | 1 | 1 ou 0 ou vide | | | Commune ou Znieff | 1 | 1 ou 0 | |
| | Maille 10x10km | 2 | 2 | | | Maille 10x10km\\ (5x5km pour Silene) | 2 | 2 | |
| | Département | 3 | 3 | | | Département | 3 | 3 | |
| | Non consultable | 4 | 4 | | | Non consultable - Aucune diffusion | 4 | 4 | |
| |
| Exemple issu du document "Diffusion des données par niveaux de restitution dans GINCO" : | Exemple issu du document "Diffusion des données par niveaux de restitution dans GINCO" : |
| * l’aplatissement consiste à distribuer les permissions par module en fonction de l'héritage pour : | * l’aplatissement consiste à distribuer les permissions par module en fonction de l'héritage pour : |
| * les groupes | * les groupes |
| * la hiérarchie d'application | * la hiérarchie applicative : module GEONATURE > module spécifique (Ex. : SYNTHESE) > objets du module (Ex. : PRIVATE_OBSERVATION,SENSITIVE_OBSERVATION). |
| - L'utilisateur accède au module Synthèse. | - L'utilisateur accède au module Synthèse. |
| * Nous sélectionnons les permissions liées au module Synthèse | * Nous sélectionnons les permissions liées au module Synthèse |
jpmilcent