Commentaire sur la fiche : Comment réserver l’usage d’un champ à certaines personnes dans le formulaire d’une fiche
Si la réponse à cette question ne vous parait pas claire ou si elle vous semble obsolète, n’hésitez pas à nous en faire part.
Et nous sommes preneurs également de toute correction de faute d’orthographe ou de grammaire...
Rappel du texte de la fiche :
Il existe deux méthodes pour atteindre cet objectif : une méthode radicale et une méthode plus « douce ».
La méthode radicale : interdire au niveau des rôles
Cette méthode n’est disponible que pour l’insertion d’une autre collection (corpus, thésaurus, album, addenda) car elle consiste à interdire tout accès à la collection en question via les rôles. Les personnes qui n’auront pas les droits suffisants ne verront en aucune manière le contenu de cette collection, elles ne risquent donc pas d’accéder à l’information via des voies imprévues. Par exemple, si un export tabulaire personnalisé propose une colonne avec les données de la collection interdite, les personnes non autorisées verront la colonne vide.
Pour cela, il faut aller dans le menu et choisir
. On interdit alors l’accès à la collection pour le rôle par défaut en cochant la collection en question et en choisissant l’option
. Il reste ensuite à réouvrir l’accès à cette collection dans d’autres rôles. Seules alors les personnes possédant ces rôles accéderont à la collection.
L’interdiction au niveau du rôle par défaut est conseillée car c’est le rôle attribué automatiquement à la création d’une personne. Pour limiter les risques d’accès non prévus, il vaut mieux limiter les droits initialement puis les ouvrir progressivement par attribution de rôles supplémentaires.
La méthode douce : limiter au niveau des composants
Cette méthode repose également sur les rôles mais en les utilisant dans les attributs du composant en question. Les deux attributs disponibles sont role:read et role:write qui permettent d’indiquer les rôles autorisant respectivement la lecture et l’écriture. On indique les noms techniques des rôles en utilisant les valeurs particulières _default pour le rôle par défaut et _admin pour l’administration globale.
Dans l’exemple suivant, seules les personnes avec le rôle averti (et bien sûr celles avec les droits d’administration globale) ont accès en lecture et seules les personnes avec les droits d’administration globale ont accès à l’écriture.
role:read=averti
role:write=_adminComme la configuration est au niveau du composant, il faut bien sûr l’indiquer pour chaque composant, que ce soit dans ce corpus ou dans un autre. Et même une personne qui n’a pas les droits de lecture peut avoir accès à l’information si on lui propose un export tabulaire personnalisé contenant les données issues de ce composant.
Il faut donc voir plus cette méthode comme une méthode « de confort » qui permet de simplifier le formulaire pour les personnes qui ont moins de droit et pour qui l’information en question n’est pas indispensable.