`_. Exemple :
::
[MAIL_CONFIG]
MAIL_SERVER = 'mail.espaces-naturels.fr'
MAIL_PORT = 465
MAIL_USE_TLS = false
MAIL_USE_SSL = true
MAIL_USERNAME = 'mon_email@email.io'
MAIL_PASSWORD = 'monpassword'
MAIL_DEFAULT_SENDER = 'mon_email@email.io'
MAIL_ASCII_ATTACHMENTS = false
Pour activer cette fonctionnalité (qui est par défaut désactivée), modifier le fichier de configuration de la manière suivante :
NB : tous les paramètres décrits ci-dessous doivent être dans la rubrique ``[ACCOUNT_MANAGEMENT]``
::
[ACCOUNT_MANAGEMENT]
ENABLE_SIGN_UP = true
Deux modes sont alors disponibles. Soit l'utilisateur est automatiquement accepté et un compte lui est créé après une confirmation de son email, soit un mail est envoyé à un administrateur pour confirmer la demande. Le compte ne sera crée qu'après validation par l'administrateur. Le paramètre ``AUTO_ACCOUNT_CREATION`` contrôle ce comportement (par défaut le compte créé sans validation par un administrateur: true). Dans le mode "création de compte validé par administrateur", il est indispensable de renseigner un email où seront envoyés les emails de validation (paramètre ``VALIDATOR_EMAIL``)
::
# automatique
[ACCOUNT_MANAGEMENT]
ENABLE_SIGN_UP = true
AUTO_ACCOUNT_CREATION = true
# validé par admin
[ACCOUNT_MANAGEMENT]
ENABLE_SIGN_UP = true
AUTO_ACCOUNT_CREATION = false
VALIDATOR_EMAIL = 'email@validateur.io'
L'utilisateur qui demande la création de compte est automatiquement mis dans un "groupe" UsersHub (par défaut, il s'agit du groupe "En poste"). Ce groupe est paramétrable depuis la table ``utilisateurs.cor_role_app_profil``. (La ligne où ``is_default_group_for_app = true`` sera utilisée comme groupe par défaut pour GeoNature). Il n'est pas en paramètre de GeoNature pusqu'il serait falsifiable via l'API. ⚠️ **Attention**, si vous effectuez une migration depuis une version de GeoNature < 2.2.0, aucun groupe par défaut n'est défini, vous devez définir à la main le groupe par défaut pour l'application GeoNature dans la table ``utilisateurs.cor_role_app_profil``.
Dans le mode "création de compte validé par administrateur", lorsque l'inscription est validée par un administrateur, un email est envoyé à l'utilisateur pour lui indiquer la confirmation de son inscription.
Il est possible de personnaliser le texte de la partie finale de cet email située juste avant la signature à l'aide du paramètre ``ADDON_USER_EMAIL`` (toujours à ajouter à la rubrique ``[ACCOUNT_MANAGEMENT]``).
Vous pouvez utiliser des balises HTML compatibles avec les emails pour ce texte.
::
[ACCOUNT_MANAGEMENT]
ADDON_USER_EMAIL = """
Toute l'équipe de GeoNature vous remercie pour votre inscription.
"""
Il est également possible de créer automatiquement un jeu de données et un cadre d'acquisition "personnel" à l'utilisateur afin qu'il puisse saisir des données dès sa création de compte via le paramètre ``AUTO_DATASET_CREATION``. Par la suite l'administrateur pourra rattacher l'utilisateur à des JDD et CA via son organisme.
::
[ACCOUNT_MANAGEMENT]
AUTO_ACCOUNT_CREATION = true
ENABLE_SIGN_UP = true
AUTO_DATASET_CREATION = true
Customisation du formulaire
```````````````````````````
Le formulaire de création de compte est par défaut assez minimaliste (nom, prénom, email, mot de passe, organisme, remarque).
*NB* l'organisme est demandé à l'utilisateur à titre "informatif", c'est à l'administrateur de rattacher individuellement l'utilisateur à son organisme, et éventuellement de le créer, s'il n'existe pas.
Il est possible d'ajouter des champs au formulaire grâce à un générateur controlé par la configuration. Plusieurs type de champs peuvent être ajoutés (text, textarea, number, select, checkbox mais aussi taxonomy, nomenclature etc...).
L'exemple ci-dessous permet de créer un champs de type "checkbox" obligatoire, avec un lien vers un document (une charte par exemple) et un champ de type "select", non obligatoire. (voir le fichier ``config/geonature_config.toml.example`` pour un exemple plus exhaustif).
::
[ACCOUNT_MANAGEMENT]
[[ACCOUNT_MANAGEMENT.ACCOUNT_FORM]]
type_widget = "checkbox"
attribut_label = """
J'ai lu et j'accepte la charte
"""
attribut_name = "validate_charte"
values = [true]
required = true
[[ACCOUNT_MANAGEMENT.ACCOUNT_FORM]]
type_widget = "select"
attribut_label = "Exemple select"
attribut_name = "select_test"
values = ["value1", "value2"]
required = false
Espace utilisateur
""""""""""""""""""
Un espace "utilisateur" est accessible lorsque l'on est connecté, permettant de modifier ses informations personnelles, y compris son mot de passe.
Cet espace est activable grâce au paramètre ``ENABLE_USER_MANAGEMENT``. Par défaut, il est désactivé.
::
[ACCOUNT_MANAGEMENT]
AUTO_ACCOUNT_CREATION = true
ENABLE_SIGN_UP = true
ENABLE_USER_MANAGEMENT = true
Accès public
""""""""""""
Cette section de la documentation concerne l'implémentation d'un utilisateur générique et public accédant à votre instance GeoNature sans authentification.
Cela ajoute sur la page d'authentification de GeoNature, un bouton "Accès public" donnant accès à GeoNature sans authentification.
Etapes :
1/ UsersHub :
- Aller dans la section `Utilisateurs`
- Créer un utilisateur
- Définir un identifiant et un mot de passe (par exemple utilisateur 'public' et mot de passe 'public')
- S’assurer qu’il ne soit dans aucun groupe
- Aller ensuite dans la section `Applications`
- Pour GeoNature, cliquer sur le premier icône 'Voir les membres'
- Cliquer sur ajouter un rôle
- Choisir l'utilisateur juste créé
- Attribuer le rôle 1, 'Lecteur'
2/ Configuration GeoNature :
- Dans le fichier de configuration de GeoNature (``config/geonature_config.toml``), spécifier le nom d'utilisateur pour l'accès public via le paramètre ``PUBLIC_ACCESS_USERNAME`` :
.. code-block:: ini
PUBLIC_ACCESS_USERNAME = 'public'
:ref:`Exécuter les actions post-modification de la configuration `.
A ce moment-là, cet utilisateur n’a aucune permission dans GeoNature.
Il s'agit maintenant de gérer ses permissions dans GeoNature.
3/ GeoNature
- Se connecter à GeoNature avec un utilisateur administrateur
- Aller dans le module Admin
- Cliquer sur 'Backoffice', puis "Permissions" / "Par utilisateurs"
- Choisissez l'utilisateur sélectionné
- Ajouter des permissions pour chacun des modules de l'instance auquel vous souhaitez que l'utilisateur public accède
Accès public automatique
````````````````````````
Un lien GeoNature peut déclencher automatiquement une connexion avec l’utilisateur public en lui rajoutant les paramètres ``access=public``.
Exemple : ``_
.. include:: sensitivity.rst
Module OCCTAX
-------------
Installer le module
"""""""""""""""""""
Le module est fourni par défaut avec l'installation de GeoNature.
Si vous l'avez supprimé, lancez les commandes suivantes depuis le répertoire ``backend`` de GeoNature
.. code-block:: console
source venv/bin/activate
geonature install_gn_module /home//geonature/contrib/occtax occtax
Configuration du module
"""""""""""""""""""""""
Le paramétrage du module OCCTAX se fait en créant le fichier ``config/occtax_config.toml``, en s’inspirant du fichier d'exemple ``contrib/occtax/occtax_config.toml.example``.
Reportez vous à la section `Configuration d'un gn_module`_ pour effectuer les opérations supplémentaires nécessaires pour la prise en compte des modifications.
Afficher/masquer des champs du formulaire
`````````````````````````````````````````
La quasi-totalité des champs du standard Occurrences de taxons sont présents dans la base de données, et peuvent donc être saisis à partir du formulaire.
Pour plus de souplesse et afin de répondre aux besoins de chacun, l'ensemble des champs sont masquables (sauf les champs essentiels : observateur, taxon ...)
En modifiant les variables des champs ci-dessous, vous pouvez donc personnaliser le formulaire :
::
[form_fields]
date_min = true
date_max = true
hour_min = true
hour_max = true
altitude_min = true
altitude_max = true
obs_technique = true
group_type = true
comment_releve = true
obs_method = true
bio_condition = true
bio_status = true
naturalness = true
exist_proof = true
observation_status = true
diffusion_level = false
blurring = false
determiner = true
determination_method = true
sample_number_proof = true
digital_proof = true
non_digital_proof = true
source_status = false
comment_occ = true
life_stage = true
sex = true
obj_count = true
type_count = true
count_min = true
count_max = true
validation_status = false
Si le champ est masqué, une valeur par défaut est inscrite en base (voir plus loin pour définir ces valeurs).
Modifier le champ Observateurs
``````````````````````````````
Par défaut le champ ``Observateurs`` est une liste déroulante qui pointe vers une liste du schéma ``utilisateurs``.
Il est possible de passer ce champ en texte libre en mettant à ``true`` la variable ``observers_txt``.
Le paramètre ``id_observers_list`` permet de changer la liste d'observateurs proposée dans le formulaire. Vous pouvez modifier le numéro de liste du module ou modifier le contenu de la liste dans UsersHub (``utilisateurs.t_listes`` et ``utilisateurs.cor_role_liste``)
Par défaut, l'ensemble des observateurs de la liste 9 (observateurs faune/flore) sont affichés.
Personnaliser la liste des taxons et habitats saisissables dans le module
`````````````````````````````````````````````````````````````
Le module est fourni avec une liste restreinte de taxons (8 seulement). C'est à l'administrateur de changer ou de remplir cette liste.
Le paramètre ``id_taxon_list = 100`` correspond à un ID de liste de la table ``taxonomie.bib_listes`` (L'ID 100 correspond à la liste "Saisie Occtax"). Vous pouvez changer ce paramètre avec l'ID de liste que vous souhaitez, ou bien garder cet ID et changer le contenu de cette liste.
Voici les requêtes SQL pour remplir la liste 100 avec tous les taxons de Taxref à partir du rang ``genre`` :
Il faut d'abord remplir la table ``taxonomie.bib_noms`` (table des taxons de sa structure), puis remplir la liste 100, avec l'ensemble des taxons de ``bib_noms`` :
.. code-block:: sql
DELETE FROM taxonomie.cor_nom_liste;
DELETE FROM taxonomie.bib_noms;
INSERT INTO taxonomie.bib_noms(cd_nom,cd_ref,nom_francais)
SELECT cd_nom, cd_ref, nom_vern
FROM taxonomie.taxref
WHERE id_rang NOT IN ('Dumm','SPRG','KD','SSRG','IFRG','PH','SBPH','IFPH','DV','SBDV','SPCL','CLAD','CL',
'SBCL','IFCL','LEG','SPOR','COH','OR','SBOR','IFOR','SPFM','FM','SBFM','TR','SSTR');
INSERT INTO taxonomie.cor_nom_liste (id_liste,id_nom)
SELECT 100,n.id_nom FROM taxonomie.bib_noms n;
Il est également possible d'éditer des listes à partir de l'application TaxHub.
Il est de même possible de restreindre la liste d'habitats proposés dans le module :
::
ID_LIST_HABITAT = 2
Avec ``ID_LIST_HABITAT`` faisant référence aux listes définies dans ``ref_habitats.bib_list_habitat``. La liste est peuplée d'habitats grâce à la table ``ref_habitats.cor_list_habitat``. Par exemple :
.. code-block:: sql
-- Création d'une liste restreinte d'habitats pour OccTax
-- (typologie EUNIS de niveau 2)
INSERT INTO ref_habitats.cor_list_habitat clh(
cd_hab,
id_list
)
SELECT
hr.cd_hab,
2
FROM ref_habitats.habref hr
WHERE (hr.cd_typo,hr.niveau) = (7 , 2)
;
Gérer les valeurs par défaut des nomenclatures
``````````````````````````````````````````````
Le formulaire de saisie pré-remplit des valeurs par défaut pour simplifier la saisie. Ce sont également ces valeurs qui sont prises en compte pour remplir dans la BDD les champs du formulaire qui sont masqués.
La table ``pr_occtax.defaults_nomenclatures_value`` définit les valeurs par défaut pour chaque nomenclature.
La table contient les deux colonnes suivantes :
- l'``id_type`` de nomenclature (voir table ``ref_nomenclature.bib_nomenclatures_types``)
- l'``id_nomenclature`` (voir table ``ref_nomenclature.t_nomenclatures``)
Pour chaque type de nomenclature, on associe l'ID de la nomenclature que l'on souhaite voir apparaitre par défaut.
Le mécanisme peut être poussé plus loin en associant une nomenclature par défaut par organisme, règne et group2_inpn.
La valeur 0 pour ses champs revient à mettre la valeur par défaut pour tous les organismes, tous les règnes et tous les group2_inpn.
Une interface de gestion des nomenclatures est prévue d'être développée pour simplifier cette configuration.
TODO : valeur par défaut de la validation
Personnaliser l'interface Map-list
``````````````````````````````````
La liste des champs affichés par défaut dans le tableau peut être modifiée avec le paramètre ``default_maplist_columns``.
Par défaut :
::
default_maplist_columns = [
{ prop = "taxons", name = "Taxon" },
{ prop = "date_min", name = "Date début" },
{ prop = "observateurs", name = "Observateurs" },
{ prop = "dataset_name", name = "Jeu de données" }
]
Voir la vue ``occtax.v_releve_list`` pour voir les champs disponibles.
Ajouter une contrainte d'échelle de saisie sur la carte
```````````````````````````````````````````````````````
Il est possible de contraindre la saisie de la géométrie d'un relevé sur la carte par un seuil d'échelle minimum avec le paramètre ``releve_map_zoom_level``.
Par défaut :
::
# Zoom level on the map from which you can add point/line/polygon
releve_map_zoom_level = 6
Il suffit de modifier la valeur qui correspond au niveau de zoom sur la carte.
Par exemple, pour contraindre la saisie à l'affichage de la carte IGN au 1/25000e :
::
releve_map_zoom_level = 15
Supprimer le remplissage automatique de la date
``````````````````````````````
Pour éviter les erreurs de saisie lorsque des données sont rentrées longtemps après le retour du terrain, il est possible de supprimer l'ajout automatique de la date du jour au relevé :
::
DATE_FORM_WITH_TODAY = false
Gestion des exports
"""""""""""""""""""
Les exports du module sont basés sur une vue (par défaut ``pr_occtax.export_occtax_sinp``)
Il est possible de définir une autre vue pour avoir des exports personnalisés.
Pour cela, créer votre vue, et modifier les paramètres suivants :
::
# Name of the view based export
export_view_name = 'v_export_occtax'
# Name of the geometry columns of the view
export_geom_columns_name = 'geom_4326'
# Name of the primary key column of the view
export_id_column_name = 'permId'
La vue doit cependant contenir les champs suivants pour que les filtres de recherche fonctionnent :
::
date_min,
date_max,
id_releve_occtax,
id_dataset,
id_occurrence_occtax,
id_digitiser,
geom_4326,
dataset_name
Attribuer des permissions
"""""""""""""""""""""""""
La gestion des permissions (CRUVED) se fait module par module, depuis le module "Admin".
Dupliquer le module Occtax
""""""""""""""""""""""""""
Il est possible de "dupliquer" le module Occtax pour créer des nouveaux modules, basé sur le moteur d'Occtax, en y ajoutant des champs additionnels propre au module.
Le schéma de base de données ainsi que les routes du backend utilisées restent les mêmes (celles d'Occtax). En base de données un nouveau champs ``id_module`` permet de différencier les données venant des differents modules. Concernant l'API, les routes sont appelées avec le préfixe du module code :
- route Occtax : ``/occtax/releves``
- route du module dupliqué : `occtax//releves`
Pour créer un nouveau module "Occtax dupliqué", ajoutez une ligne dans la table ``gn_commons.t_modules``.
La ligne doit contenir les informations suivantes :
- le ``module_code`` doit être unique,
- les champs ``active_frontend=true``, ``active_backend=false``, ``ng_module=occtax`` et le champs ``module_path`` pour l'URL derrière lequel le module sera servi (``/florestation`` par exemple)
Exemple :
::
INSERT INTO gn_commons.t_modules (module_code, module_label, module_picto, module_desc, module_path,active_frontend, active_backend, ng_module) VALUES
('FLORE_STATION','Flore station v2','fa-leaf','Module de saisie Flore station (sous module Occtax)','flore_station',true,false,'occtax');
Ajoutez ensuite une "source" dans la synthese (``gn_synthese.t_sources``) pour ce nouveau module.
Dans l'exemple ci-dessous, remplacez ```` par le contenu de la colonne ``module_path`` ainsi que ```` par l'id du module que vous venez de créer.
::
INSERT INTO gn_synthese.t_sources (name_source,desc_source,entity_source_pk_field,url_source,,id_module) VALUES
('Flore station (sous-module Occtax)','Données issues du protocole Flore station','pr_occtax.cor_counting_occtax.id_counting_occtax','#//info/id_counting', );
Bien que le module soit une copie d'Occtax, il est tout de même nécessaire de définir les permissions disponibles pour ce module (ce sont les mêmes qu'Occtax). Jouez le scrit SQL suivant en remplacant :MODULE_CODE par le code du module que vous venez de créer.
::
INSERT INTO
gn_permissions.t_permissions_available (
id_module,
id_object,
id_action,
label,
scope_filter
)
SELECT
m.id_module,
o.id_object,
a.id_action,
v.label,
v.scope_filter
FROM
(
VALUES
(':MODULE_CODE', 'ALL', 'C', True, 'Créer des relevés')
,(':MODULE_CODE', 'ALL', 'R', True, 'Voir les relevés')
,(':MODULE_CODE', 'ALL', 'U', True, 'Modifier les relevés')
,(':MODULE_CODE', 'ALL', 'E', True, 'Exporter les relevés')
,(':MODULE_CODE', 'ALL', 'D', True, 'Supprimer des relevés')
) AS v (module_code, object_code, action_code, scope_filter, label)
JOIN
gn_commons.t_modules m ON m.module_code = v.module_code
JOIN
gn_permissions.t_objects o ON o.code_object = v.object_code
JOIN
gn_permissions.bib_actions a ON a.code_action = v.action_code;
Associer des jeux de données et des champs additionnels
```````````````````````````````````````````````````````
Dans le module Métadonnées (formulaire des jeux de données), associez les jeux de données que vous souhaitez rendre saisissables au nouveau module dupliqué.
Ajouter le nouveau module dans la liste des modules implémentés
```````````````````````````````````````````````````````````````
Dans le fichier de configuration de GeoNature (geonature_config.toml) ajoutez une section `ADDITIONAL_FIELDS` qui contient tableau `IMPLEMENTED_MODULES` listant les modules qui implémentent les champs additionnels (Occtax doit y figurer en plus du nouveau module)
::
[ADDITIONAL_FIELDS]
IMPLEMENTED_MODULES = ["OCCTAX", "FLORE_STATION"]
Vous pouvez ensuite créer des nouveaux champs additionnels et les associer à ce module. De la même manière que dans Occtax, on peut les associer aux trois niveaux du formulaire (relevé, occurrence, dénombrement).
Module Admin
-------------
Administration des champs additionnels
""""""""""""""""""""""""""""""""""""""
Certains protocoles nécessitent la saisie de champs qui vont au-delà des standards du SINP sur lesquels GeoNature s'appuie. Les champs additionnels permettent ainsi d'étendre les formulaires en ajoutant des informations spécifiques pour des jeux de données (JDD) ou pour l'ensemble d'un module.
Les champs additionnels ne sont pas créés comme des colonnes à part entière, mais leurs valeurs sont stockées dans un champs ``additional_data`` au format JSON.
Actuellement seul le module Occtax implémente la gestion de ces champs additionnels.
Le backoffice de GeoNature offre une interface de création et de gestion de ces champs additionnels.
Un champ additionnel est définit par:
- son nom (nom dans la base de données)
- son label (nom tel qu'il sera affiché sur l'interface)
- son type de widget : vous devez définir si le champs est une liste déroulante, une checkbox, une nomenclature, un entier, un champ texte, etc...
- le (ou les) module(s) auquel il est rattaché
- le (ou les) objet(s) auquel il est rattaché. Il s'agit du placement et de la table de rattachement du champs dans le module. Par exemple Occtax est composé de 3 "objets/table". Les objets "relevé", "occurrence" et "dénombrement".
- le (ou les) JDD auquel il est rattaché. Si aucun JDD n'est renseigné le champ sera proposé dans tout le module pour tous les JDD. S'il est rattaché à un JDD, le champs sera chargé dynamiquement à la selection du JDD dans le formulaire
- une série d'autres options pour paramétrer le comportement du champs (obligatoire, ordre, description, exportable etc...)
Les champs additionnels sont stockés dans la table ``gn_commons.t_additional_fields``.
Exemples de configuration :
Pour les champs de type "select", "multiselect", "checkbox" et "radio", le champs "valeur" doit être rempli par un JSON représentant une liste de dictionnaire "label" (représentant la valeur affiché), et "valeur" (représentant la valeur écrite en base de données).
Exemples :
- `[{"label": "Trois", "value": 3}, {"label": "Quatre", "value": 4}]`
- `[{"label": "1", "value": "Étude générale"}, {"label": "Gestion de site", "value": "2"}, {"label": "Partenariat", "value": "3"}]`
- Un champs type "multiselect":
.. image :: _static/label_value_multiselect.png
- Un champs type "html". C'est un champs de type "présentation", aucune valeur ne sera enregistré en base de données pour ce champs :
.. image :: _static/html1.png
- Un champs de type "datalist". Ce champs permet de générer une liste de valeurs à partir d'une API (non porté sur Occtax-mobile). Dans le champ "attributs additionnels", renseignez les éléments suivants :
::
``{"api": "url_vers_la_ressource", "keyValue": "champ à stocker en base", "keyLabel": "champ à afficher en interface"}
Configuration avancée des champs
````````````````````````````````
Le champs "Attribut additionnels" permet d'ajouter des éléments de configuration sur les formulaires sour forme de JSON:
- Ajouter une icone "?" et un tooltip au survol du formulaire : `{"description" : "mon toolitp"}`
- Ajouter un sous-titre descriptif : `{"help" : "mon sous titre"}`
- Ajouter des valeurs min/max pour un input `number` : `{"min": 1, "max": 10}`
Module OCCHAB
-------------
Installer le module
"""""""""""""""""""
Le module OCCHAB fait parti du coeur de GeoNature. Son installation est au choix de l'administrateur.
Pour l'installer, lancer les commande suivante:
.. code-block:: console
cd backend
source venv/bin/activate
geonature install_gn_module /home/`whoami`/geonature/contrib/gn_module_occhab occtax
Base de données
"""""""""""""""
Le module s'appuie sur deux schémas :
- ``ref_habitats`` correspond au référentiel habitat du MNHN,
- ``pr_occhab`` correspond au schéma qui contient les données d'occurrence d'habitat, basé sur standard du MNHN.
Configuration
"""""""""""""
Le paramétrage du module OCCHAB se fait en créant le fichier ``config/occhab_config.toml``, en s’inspirant du fichier d'exemple ``contrib/gn_module_occhab/occhab_config.toml.example``.
Reportez vous à la section `Configuration d'un gn_module`_ pour effectuer les opérations supplémentaires nécessaires pour la prise en compte des modifications.
Formulaire
``````````
- La liste des habitats fournie pour la saisie est basée sur une liste définie dans la base de données (table ``ref_habitat.cor_list_habitat`` et ``ref_habitat.bib_list_habitat``). Il est possible de modifier cette liste directement dnns la base de données, d'en créer une autre et de changer la liste utiliser par le module. Modifier alors ce paramètre :
``ID_LIST_HABITAT = 1``
- Le formulaire permet de saisir des observateurs basés sur le référentiel utilisateurs (``false``) ou de les saisir en texte libre (``true``).
``OBSERVER_AS_TXT = false``
- L'ensemble des champs du formulaire son masquables. Pour en masquer certains, passer à ``false`` les variables suivantes :
::
[formConfig]
date_min = true
date_max = true
depth_min = true
depth_max = true
altitude_min = true
altitude_max = true
exposure = true
area = true
comment = true
area_surface_calculation = true
geographic_object = true
determination_type = true
determiner = true
collection_technique = true
technical_precision = true
recovery_percentage = true
abundance = true
community_interest = true
Voir le fichier ``occhab_config.example`` qui liste l'ensemble des paramètres de configuration du module.
Module SYNTHESE
---------------
Le module Synthèse est un module du coeur de GeoNature, fourni par défaut lors de l'installation.
Configuration
""""""""""""""
L'ensemble des paramètres de configuration du module se trouve dans le fichier général de configuration de GeoNature ``config/geonature_config.toml`` puisqu'il s'agit d'un module du coeur.
**1.** Modifier les filtres géographiques disponibles par défaut dans l'interface de recherche.
Editer la variable ``AREA_FILTERS`` en y ajoutant le label et le code du type d'entité géographique que vous souhaitez rajouter. Voir table ``ref_geo.bib_areas_types``. Dans l'exemple on ajoute le type ZNIEFF1 (``code_type = "ZNIEFF1"``). Attention, dans ce cas les entités géographiques correspondantes au type `ZNIEFF1`, doivent également être présentes dans la table ``ref_geo.l_areas``.
Attention : Si des données sont déjà présentes dans la synthèse et que l'on ajoute de nouvelles entités géographiques à ``ref_geo.l_areas``, il faut également recalculer les valeurs de la table ``gn_synthese.cor_area_synthese`` qui assure la correspondance entre les données de la synthèse et les entités géographiques.
::
[SYNTHESE]
# Liste des entités géographiques sur lesquels les filtres
# géographiques de la synthese s'appuient (type_code = code du type de l'entité géo, table ref_geo.bib_areas_types)
AREA_FILTERS = [
{ label = "Communes", type_code = "COM" },
{ label = "ZNIEFF1", type_code = "ZNIEFF1" },
]
Il est aussi possible de passer plusieurs ``type_code`` regroupés dans un même filtre géographique (exemple : ``{ label = "Zonages réglementaires", type_code = ["ZC", "ZPS", "SIC"] }``).
**2.** Configurer les champs des exports
Dans tous les exports, l'ordre et le nom des colonnes sont basés sur la vue servant l'export. Il est possible de les modifier en éditant le SQL des vues en respectant bien les consignes ci-dessous.
**Export des observations**
Les exports (CSV, GeoJson, Shapefile) sont basés sur la vue ``gn_synthese.v_synthese_for_export``.
Il est possible de ne pas intégrer certains champs présents dans cette vue d'export. Pour cela modifier le paramètre ``EXPORT_COLUMNS``.
Enlevez la ligne de la colonne que vous souhaitez désactiver. Les noms de colonne de plus de 10 caractères seront tronqués dans le fichier shapefile.
::
[SYNTHESE]
EXPORT_COLUMNS = [
"date_debut",
"date_fin",
"heure_debut",
"heure_fin",
"cd_nom",
"cd_ref",
"nom_valide",
"nom_vernaculaire",
"nom_cite",
"regne",
"group1_inpn",
"group2_inpn",
"classe",
"ordre",
"famille",
"rang_taxo",
"nombre_min",
"nombre_max",
"alti_min",
"alti_max",
"prof_min",
"prof_max",
"observateurs",
"determinateur",
"communes",
"x_centroid_4326",
"y_centroid_4326",
"geometrie_wkt_4326",
"nom_lieu",
"comment_releve",
"comment_occurrence",
"validateur",
"niveau_validation",
"date_validation",
"comment_validation",
"preuve_numerique_url",
"preuve_non_numerique",
"jdd_nom",
"jdd_uuid",
"jdd_id",
"ca_nom",
"ca_uuid",
"ca_id",
"cd_habref",
"cd_habitat",
"nom_habitat",
"precision_geographique",
"nature_objet_geo",
"type_regroupement",
"methode_regroupement",
"technique_observation",
"biologique_statut",
"etat_biologique",
"biogeographique_statut",
"naturalite",
"preuve_existante",
"niveau_precision_diffusion",
"stade_vie",
"sexe",
"objet_denombrement",
"type_denombrement",
"niveau_sensibilite",
"statut_observation",
"floutage_dee",
"statut_source",
"type_info_geo",
"methode_determination",
"comportement",
"reference_biblio",
"id_synthese",
"id_origine",
"uuid_perm_sinp",
"uuid_perm_grp_sinp",
"date_creation",
"date_modification"
]
:Note:
L'entête ``[SYNTHESE]`` au dessus ``EXPORT_COLUMNS`` indique simplement que cette variable appartient au bloc de configuration de la synthese. Ne pas rajouter l'entête à chaque paramètre de la synthese mais une seule fois au dessus de toutes les variables de configuration du module.
Il est également possible de personnaliser ses exports en éditant le SQL de la vue ``gn_synthese.v_synthese_for_export`` (niveau SQL et administration GeoNature avancé).
Attention, certains champs sont cependant obligatoires pour assurer la réalisation des fichiers d'export (csv, geojson et shapefile) et des filtres CRUVED.
La vue doit OBLIGATOIREMENT contenir les champs :
- geojson_4326
- geojson_local
- id_synthese,
- jdd_id (l'ID du jeu de données)
- id_digitiser
- observateurs
Ces champs doivent impérativement être présents dans la vue, mais ne seront pas nécessairement dans le fichier d'export si ils ne figurent pas dans la variable ``EXPORT_COLUMNS``. De manière générale, préférez rajouter des champs plutôt que d'en enlever !
Le nom de ces champs peut cependant être modifié. Dans ce cas, modifiez le fichier ``geonature_config.toml``, section ``SYNTHESE`` parmis les variables suivantes (``EXPORT_ID_SYNTHESE_COL, EXPORT_ID_DATASET_COL, EXPORT_ID_DIGITISER_COL, EXPORT_OBSERVERS_COL, EXPORT_GEOJSON_4326_COL, EXPORT_GEOJSON_LOCAL_COL``).
NB : Lorsqu'on effectue une recherche dans la synthèse, on interroge la vue ``gn_synthese.v_synthese_for_web_app``. L'interface web passe ensuite une liste d'``id_synthese`` à la vue ``gn_synthese.v_synthese_for_export`` correspondant à la recherche précedemment effectuée (ce qui permet à cette seconde vue d'être totalement modifiable).
La vue ``gn_synthese.v_synthese_for_web_app`` est taillée pour l'interface web, il ne faut donc PAS la modifier.
**Export des métadonnées**
En plus des observations brutes, il est possible d'effectuer un export des métadonnées associées aux observations. L'export est au format CSV et est construit à partir de la table ``gn_synthese.v_metadata_for_export``. Vous pouvez modifier le SQL de création de cette vue pour customiser votre export (niveau SQL avancé).
Deux champs sont cependant obligatoire dans la vue :
- ``jdd_id`` (qui correspond à l'id du JDD de la table ``gn_meta.t_datasets``). Le nom de ce champs est modifiable. Si vous le modifiez, éditez la variable ``EXPORT_METADATA_ID_DATASET_COL``.
- ``acteurs``: Le nom de ce champs est modifiable. Si vous le modifiez, éditez la variable ``EXPORT_METADATA_ACTOR_COL``
**Export des statuts taxonomiques (réglementations)**
Cet export n'est pas basé sur une vue, il n'est donc pas possible de l'adapter.
**3.** Configurer les seuils du nombre de données pour la recherche et les exports
Par défaut et pour des questions de performance (du navigateur et du serveur) on limite à 50000 le nombre de résultat affiché sur la carte et le nombre d'observations dans les exports.
Ces seuils sont modifiables respectivement par les variables ``NB_MAX_OBS_MAP`` et ``NB_MAX_OBS_EXPORT`` :
Le mode cluster activé par défaut peut être désactivé via le paramètre ``ENABLE_LEAFLET_CLUSTER``. Dans ce cas, il est conseillé de repasser le paramètre `NB_MAX_OBS_MAP` à 10000.
::
[SYNTHESE]
# Nombre d'observation maximum à afficher sur la carte après une recherche
NB_MAX_OBS_MAP = 10000
# Nombre max d'observation dans les exports
NB_MAX_OBS_EXPORT = 40000
**4.** Désactiver des filtres génériques
L'interface de recherche de la synthèse permet de filtrer sur l'ensemble des nomenclatures de la table ``gn_synthese``, il est cependant possible de désactiver les filtres de certains champs.
Modifiez la variable ``EXCLUDED_COLUMNS``
::
[SYNTHESE]
EXCLUDED_COLUMNS = ['non_digital_proof'] # pour enlever le filtre 'preuve non numérique'
**5.** Configurer les filtres des statuts de protection et des listes rouges
Il existe deux paramètres qui permettent de configurer les statuts de protection et les listes rouges à afficher dans la fenêtre avancée du module Synthese.
Il s'agit de :
* ``RED_LISTS_FILTERS`` : pour configurer les listes rouges. Les listes déroulantes configurées affichent les codes et intitulés des valeurs des listes (*CR - En danger critique*, *DD - Données insuffisantes*, ...).
* ``STATUS_FILTERS`` : pour configurer les statuts de protection. Les listes déroulantes configurées affichent l'intitulé suivi du code des types de textes (*Protection départementale - PD*, *Protection nationale - PN*).
Ces paramètres se présentent sous la forme d'une liste de dictionnaires. Il est possible d'ajouter de nouveaux filtres en ajoutant de nouveaux dictionnaires à la liste.
Voici un exemple :
::
[SYNTHESE]
RED_LISTS_FILTERS = [
{ "id" = "worldwide", "show" = true, "display_name" = "Liste rouge mondiale", "status_type" = "LRM" },
{ "id" = "european", "show" = true, "display_name" = "Liste rouge européenne", "status_type" = "LRE" },
{ "id" = "national", "show" = true, "display_name" = "Liste rouge nationale", "status_type" = "LRN" },
{ "id" = "regional", "show" = true, "display_name" = "Liste rouge régionale", "status_type" = "LRR" },
]
STATUS_FILTERS = [
{ "id" = "protections", "show" = true, "display_name" = "Taxons protégés", "status_types" = ["PN", "PR", "PD"] },
{ "id" = "regulations", "show" = true, "display_name" = "Taxons réglementés", "status_types" = ["REGLII", "REGL", "REGLSO"] },
{ "id" = "invasive", "show" = true, "display_name" = "Espèces envahissantes", "status_types" = ["REGLLUTTE"] },
{ "id" = "znief", "show" = true, "display_name" = "Espèces déterminantes ZNIEFF", "status_types" = ["ZDET"] },
]
Pour chaque dictionnaire, voici le détail des champs (ils sont tous obligatoires) :
* ``id`` : correspond à un mot clé (sans caractères spéciaux ou accentués) qui doit être unique dans la liste.
* ``show`` : permet de rapidement afficher (= ``true``) ou cacher (= ``false``) un filtre sur l'interface sans avoir à supprimer la ligne.
* ``display_name`` : indique le texte de l'intitulé de la liste déroulante qui sera affiché sur l'interface.
* ``status_type`` : pour les statuts de protection cela correspond à une liste des codes de types de statuts de protections à afficher dans la liste déroulante. Les codes existant sont consultables dans le champ ``cd_type_statut`` de la table ``taxonomie.bdc_statut_type``. Pour les listes rouges, il faut seulement indiquer le code de la liste.
Au niveau de la base de données, il est possible de limiter les recherches uniquement aux textes correspondant à la zone géographique des observations de votre installation.
Pour cela, il suffit de mettre une valeur ``false`` dans le champ ``enable`` de la table ``taxonomie.bdc_statut_text`` pour tous les textes que vous ne souhaitez pas prendre en compte. Si vous avez une grande quantité d'observations, cette étape est fortement recommandée !
Exemple de requête de mise à jour de la table ``taxonomie.bdc_statut_text`` pour désactiver les textes des DOM-TOM : :
::
UPDATE taxonomie.bdc_statut_text SET enable = false
WHERE cd_sig IN ('TER971', 'TER972', 'TER973', 'TER971', 'TER974' )
;
Une commande dans TaxHub permet de désactiver automatiquement les textes en dehors d'une liste de départements (en passant leur ``area_code``) :
::
cd ~/taxhub
source venv/bin/activate
flask taxref enable-bdc-statut-text -d -d --clean
**6.** Définir des filtres par défaut
Il s'agit du paramètre ``DEFAULT_FILTERS``.
C'est un dictionnaire qui liste la valeur des champs par défaut.
Il faut fournir le code des nomenclature par défaut (liste de chaîne de caractère).
(On prend les champs en ``id_nomenclature_...`` et on remplace ``id_nomenclature_`` par ``cd_nomenclature_``)
Exemple de filtres par défaut :
::
[SYNTHESE]
...
[SYNTHESE.DEFAULT_FILTERS]
# Tous les statuts de validation sauf invalide '4'
# Il faut bien les renseigner en tant que chaîne de caractère (et non en tant que nombre)
cd_nomenclature_valid_status = ['0', '1', '2', '3', '5', '6']
# Seulement les données de présence
cd_nomenclature_observation_status = ['Pr']
D'autres élements sont paramètrables dans le module Synthese. La liste complète est disponible dans le fichier ``config/default_config.toml.example`` rubrique ``SYNTHESE``.
Module VALIDATION
-----------------
Le module VALIDATION, integré depuis la version 2.1.0 dans le coeur de GeoNature permet de valider des occurrences de taxon en s'appuyant sur les données présentes dans la SYNTHESE. Le module s'appuie sur le `standard Validation `_ du SINP et sur ses `nomenclatures officiels `_.
Afin de valider une occurrence, celle-ci doit impérativement avoir un UUID. En effet, la validation est stockée en BDD dans la table transversale ``gn_commons.t_validations`` (`voir doc `_ ) qui impose la présence de cet UUID.
La table ``gn_commons.t_validations`` contient l'ensemble de l'historique de validation des occurrences. Pour une même occurrence (identifiée par un UUID unique) on peut donc retrouver plusieurs lignes dans la table correspondant au différents statuts de validation attribués à cet occurrence dans le temps.
La vue ``gn_commons.v_latest_validation`` permet de récupérer le dernier statut de validation d'une occurrence.
NB : une donnée non présente dans la SYNTHESE, ne remontera pas dans l'interface du module VALIDATION. Cependant rien n'empêche un administrateur avancé d'utiliser la table de validation et son mécanisme pour des données qui ne seraient pas en SYNTHESE (du moment que les données disposent d'un UUID).
Au niveau de l'interface, le formulaire de recherche est commun avec le module SYNTHESE. Les paramètres de configuration du formulaire sont donc également partagés et administrables depuis le fichier ``geonature_config.toml``, rubrique SYNTHESE.
Configuration
"""""""""""""
Le paramétrage du module VALIDATION se fait en créant le fichier ``config/validation_config.toml``, en s’inspirant du fichier d'exemple ``contrib/gn_module_validation/validation_config.toml.example``
Reportez vous à la section `Configuration d'un gn_module`_ pour effectuer les opérations supplémentaires nécessaires pour la prise en compte des modifications.
Liste des champs visibles
`````````````````````````
Gestion de l'affichage des colonnes de la liste via le paramètre ``COLUMN_LIST`` :
::
[[COLUMN_LIST]]
column_label = "nomenclature_life_stage.label_default" # Champs de la synthèse, éventuellement en suivant des relationships
column_name = "Stade de vie" # Titre de la colonne
min_width = 100 # Taille minimale de la colonne
max_width = 100 # Taille maximale de la colonne
E-mail
``````
Il est possible de personnaliser le message du mail envoyé aux observateurs.
Pour ce faire il faut modifier les paramètres ``MAIL_BODY`` et ``MAIL_SUBJECT``
Pour afficher dans le mail des données relatives à l'observation ou au taxon il faut respecter la syntaxe suivante:
``${ d.NOM_PROPRIETE }``
Liste des propriétés disponibles :
- communes : liste des communes
- medias : Titre, auteur et lien vers le média associée
- data_link : lien vers l'observation dans son module de saisie
- tous les champs de la synthèse (acquisition_framework, altitude_max, altitude_min, bio_status, blurring, cd_hab, cd_nom, comment_context, comment_description, date_min, depth_max, depth_min, determiner, diffusion_level, digital_proof, entity_source_pk_value, exist_proof, grp_method, grp_typ, last_action, life_stage, meta_create_date, meta_update_date, meta_v_taxref, meta_validation_date, nat_obj_geo, naturalness, nom_cite, non_digital_proof, obj_count, obs_technique, observation_status, observers, occ_behaviour, occ_stat_biogeo, place_name, precision, sample_number_proof, sensitivity, sex, source, type_count, unique_id_sinp, unique_id_sinp_grp, valid_status, validation_comment)
- tous les champs du taxon (cd_nom, cd_ref, cd_sup, cd_taxsup, regne, ordre, classe, famille, group1_inpn, group2_inpn, id_rang, nom_complet, nom_habitat, nom_rang, nom_statut, nom_valide, nom_vern)
Validation automatique
""""""""""""""""""""""
Depuis la version 2.14, il est possible d'activer la validation automatique d'observations.
Activation
``````````
L'activation de la validation automatique s'effectue en ajoutant la ligne suivante dans le fichier de configuration du module de validation ``config/validation_config.toml``:
::
AUTO_VALIDATION_ENABLED = true
Condition de validation automatique
```````````````````````````````````
Une observation sera validée automatiquement si elle rencontre les conditions suivantes:
* Son statut de validation est ``En attente de validation``
* Si le score calculé à partir du profil de taxons est de 3. Se référer à la section `Profils de taxons`_ pour plus d'informations.
Si ces conditions sont remplies, alors le statut de validation de l'observation est mis à ``Probable``.
**Notes** Si le comportement de validation automatique ne vous correspond pas, il est possible de définir soi-même ce dernier dans la base de données sous forme d'une fonction. Reportez-vous à la section `Modification de la fonction de validation automatique`_ pour plus d'informations.
Modification de la périodicité de la validation automatique
```````````````````````````````````````````````````````````
Le processus de validation automatique est executé à une fréquence définie, par défaut toutes les heures. Si toutefois, vous souhaitez diminuer ou augmenter la durée entre chaque validation automatique, définissez cette dernière dans le fichier de configuration (``config/validation_config.toml``) dans la variable ``AUTO_VALIDATION_CRONTAB``.
::
AUTO_VALIDATION_CRONTAB ="*/1 * * * *"
Ce paramètre est composé de cinq valeurs, chacune séparée par un espace: minute, heure, jour du mois, mois de l'année, journée de la semaine. Dans l'exemple ci-dessus, il est indiqué que le processus d'auto-validation sera répété toutes les minutes. Pour plus d'informations, vous pouvez consulter la documentation de Celery à ce sujet : https://docs.celeryq.dev/en/stable/userguide/periodic-tasks.html#crontab-schedules.
**Note** Si vous ne voulez pas définir un des paramètres de périodicité, utilisez un astérisque (``*``).
Modification de la fonction de validation automatique
`````````````````````````````````````````````````````
Dans GeoNature, la validation automatique est effectuée par une fonction en ``PL/pgSQL`` déclarée dans le schéma ``gn_profiles``. Si toutefois, le fonctionnement de celle-ci ne correspond à vos besoins, indiquer le nom de la nouvelle fonction dans la variable ``AUTO_VALIDATION_SQL_FUNCTION``. Attention, cette fonction doit aussi être stockée dans le schema ``gn_profiles``. Pour vous aidez, n'hésitez pas à regarder la définition de la fonction par défaut nommée ``fct_auto_validation``.