1 files changed, 83 insertions, 1 deletions
diff --git a/docs/fr/source/annexe-2-permission-action.rst b/docs/fr/source/annexe-2-permission-action.rst
index 7576121eb..8140e5cd7 100644
--- a/docs/fr/source/annexe-2-permission-action.rst
+++ b/docs/fr/source/annexe-2-permission-action.rst
@@ -7,11 +7,93 @@ Annexe 2 - Détails des permissions
 ==================================
 
 :Auteur: Étienne Loks
-:Date: 2023-10-26
+:Date: 2025-02-28
 :Copyright: CC-BY 3.0
 
 ----------------------------------
 
+Profil administrateur
+=====================
+
+Un profil spécial « administrateur » (identifiant textuel `administrator`) a par défaut toutes les permissions sur l'interface Ishtar (et pas nécessairement sur les pages d'administration).
+
+Un certain nombre d'action ne sont disponibles que pour les utilisateurs disposant de ce profil administrateur :
+
+- visualisation de la fiche compte utilisateur ;
+- gestion des comptes utilisateurs ;
+- fusion des personnes ;
+- fusion des organisations ;
+- fusion des contenants ;
+- rattachement des éléments aux utilisateurs (permissions).
+
+
+Requêtes pour permissions
+=========================
+
+Les requêtes pour permission doivent être paramétrées pour définir finement les droits des différents comptes utilisateurs.
+
+Une requête pour permission est définie via un nom (pour pouvoir les distinguer), d'un identifiant textuel, d'un modèle auquel associer cette requête, d'une requête (champ optionnel) et des champs booléens (oui/non), « actif » (pour activer, désactiver la requête), « Inclure les éléments rattachés à l'utilisateur », « Inclure les éléments liés aux droits amonts » et « Limiter la requête aux zones rattachées ». Cette requête pour permissions est définie dans l'interface d'administration d'Ishtar (« https://mon-instance-ishtar/admin/ishtar_common/permissionrequest/ »).
+
+.. image:: _static/permissions-admin.png
+
+Le détail de ces champs est fait dans les sections ci-dessous.
+
+Cette requête pour permission est ensuite rattachée aux « types de profils » pour qu'ils soient effectifs. Les types de profils sont aussi définis depuis l'interface d'administration d'Ishtar (« https://mon-instance-ishtar/admin/ishtar_common/profiletype/ »). Ces requêtes pour permission ne sont nécessaires que pour les permissions limitées (« élémént rattaché »). Une alerte est affichée en haut de la page d'édition des types de profils lorsqu'une permission rattachée d'un type de profil ne dispose pas d'une requête pour permissions correspondante.
+
+Requête
+-------
+
+Une requête dynamique peut être faite pour obtenir les éléments à rattacher. Cette requête reprend la syntaxe du champ de recherche Ishtar.
+
+**Exemple** : requête pour les opérations : « `type="Projet Collectif de Recherche"` ».
+
+Un champ spécial peut être utilisé afin de reprendre la personne correspondant à l'utilisateur dans la requête : `{USER}`.
+
+**Exemple** : requête pour les opérations dont l'utilisateur est responsable d'opération : « `scientifique="{USER}"` ».
+
+
+Inclure les éléments rattachés à l'utilisateur
+----------------------------------------------
+
+Si cette option est cochée, des permissions sont octroyées pour les éléments qui sont directement rattachés à l'utilisateur.
+Les éléments sont rattachés via une action disponible depuis l'interface de recherche (action disponible pour le profil administrateur).
+
+.. image:: _static/permissions-rattachement.png
+
+.. note:: Le contenu des paniers de mobilier partagés sont automatiquement ajoutés aux éléments rattachés.
+
+
+Inclure les éléments liés aux droits amonts
+-------------------------------------------
+
+« Inclure les éléments liés aux permissions amonts » permet de définir des permissions de manière discrête assez simplement.
+
+*Par exemple : pour une permission octroyée sur une unité d'enregistrement particulière, si l'utilisateur dispose, par exemple, d'une permission voir le mobilier rattaché avec la requête « Mobilier – Inclure les éléments liés aux permissions amonts ». Alors cet utilisateur pourra visualiser tout le mobilier correspondant à cette unité d'enregistrement.*
+
+Ces permissions sont octroyées en cascade. Ainsi si une permission est donnée sur une opération particulière et qu'un utilisateur a des permissions amonts octroyées sur les unités d'enregistrement et le mobilier, cet utilisateur aura une permission sur le mobilier de l'opération en question.
+
+Si une permission amont est paramétrée avec un élément amont directement rattaché à cet utilisateur, les permissions sont octroyées sur cet élément amont sans que des permissions amont soient forcément définies.
+
+**Exemple** : une permission « voir unité d'enregistrement rattachée » sans permission « voir opération » mais avec une opération directement rattachée.
+
+Pour définir ces règles, il faut avoir en tête la logique de ces éléments amonts. Elle est décrite par le graphe ci-dessous (les éléments amonts sont, logiquement, en haut du graphe). Le graphe peut paraître difficile à appréhender, mais il suffit de remonter les flèches depuis l'élément rattaché qui nous intéresse.
+
+**Exemple** : le mobilier a comme élément rattaché Lieu de conservation et Unité d'enregistrement.
+
+.. image:: _static/permissions-amont.png
+
+
+.. note:: Pour des raisons de lisibilité, les documents, actes administratifs et éléments géographiques n'ont pas été représentés. Ceux-ci ont comme élément amonts les éléments auxquels ils sont liés.
+
+
+Limiter la requête aux zones rattachées
+---------------------------------------
+
+Si cette option est cochée, les éléments sont filtrés par rapport à la zone rattachée au profil de l'utilisateur.
+
+**Exemple** : si des permissions sont octroyées sur les opérations avec une limite sur les zones rattachées, un utilisateur rattaché à un département spécifique n'aura accès qu'aux opérations de ce département.
+
+
 Imports
 =======