Aller au contenu principal

Gestion des utilisateurs

Qui peut envoyer, approuver, générer, configurer. Le modèle tient en une phrase : un rôle, plus des options.

Le modèle

Les 4 rôles — un seul par personne

RôlePermission setVocation
AdministrateurTES_AdminConfigure l'org : connexions, jobs, boutons, migration, utilisateurs
ExpéditeurTES_UserEnvoie pour signature et suit ses demandes
ApprobateurTES_ApproverApprouve ou rejette — n'envoie pas
LecteurTES_ReadOnlyConsultation seule

Les 4 options — zéro ou plusieurs, en plus du rôle

OptionPermission setDébloque
Envoi en masseTES_BulkSendUserL'onglet Bulk send
Génération documentaireTES_GenUserTrueSign Gen
Gestion des modèlesTES_TemplateManagerL'éditeur de modèles
Délégué d'approbationTES_ApprovalDelegateDécider à la place d'un approbateur absent

La matrice

Ce que chaque combinaison permet réellement — mesuré à l'exécution, pas déduit de la configuration :

ConfigurationEnvoyerEnvoi en masseGénérerGérer les modèlesConfigurer l'org
(aucun permission set)
Administrateur
Expéditeur
Approbateur
Lecteur
Expéditeur + Génération
Expéditeur + Envoi en masse
Expéditeur + Modèles
Expéditeur + les 4 options
Approbateur + Génération + Modèles

Trois lectures qui comptent

L'administrateur n'a besoin d'aucune option. TES_Admin porte à lui seul l'envoi, la génération, l'envoi en masse et les modèles. Un administrateur bloqué sur sa propre configuration serait un incident, pas une sécurité.

Un approbateur ne peut pas envoyer, même avec les quatre options. C'est la séparation des devoirs : approuver et émettre sont deux actes distincts, et les cumuler viderait le circuit d'approbation de son sens.

Expéditeur + les 4 options ≠ Administrateur. C'est précisément ce qui justifie le rôle d'administrateur : tout faire, sauf configurer l'org.

Les règles que le serveur applique

Elles ne sont pas seulement affichées dans l'écran : elles sont vérifiées côté serveur, y compris si quelqu'un contourne l'interface.

RègleComportement
Un seul rôleAssigner un deuxième rôle est refusé
Une option exige un rôleAssigner une option à quelqu'un sans rôle est refusé
Pas d'option orphelineRetirer le dernier rôle est refusé tant qu'il reste des options
Changement de rôle atomiqueLe changement se fait en une seule opération et conserve les options
Retrait completVider le rôle retire les options avec lui
Pourquoi le changement de rôle est atomique

Changer un rôle en plusieurs étapes (retirer, puis assigner) laisse une fenêtre où un échec en cours de route abandonne l'utilisateur sans aucun accès, sans que rien ne le signale. L'opération est donc indivisible.

Où cela se règle

TrueSign Setup → Administration → User Management : rôle et options par utilisateur, avec recherche, et suivi de l'usage (nombre d'envois, dernier envoi).

Qui peut faire quoi, écran par écran

Écran ou actionExige
Envoyer une demande (formulaire, Quick Send, envoi automatique après génération)Rôle Expéditeur ou Administrateur
Onglet Bulk sendOption Envoi en masse + droit d'envoi
Setup → Document GenerationOption Génération
Éditeur de modèles de signatureOption Gestion des modèles
TrueSign Setup (configuration)Administrateur
Setup → User ManagementAdministrateur
La question qu'on nous pose le plus souvent

« Un utilisateur sans droit d'envoi peut-il quand même expédier une enveloppe ? » — Non, sur aucun des trois chemins : ni le formulaire, ni le Quick Send, ni l'envoi automatique déclenché après une génération. Ce dernier s'exécute pourtant en arrière-plan, et il est vérifié qu'aucune demande n'est créée, pas seulement qu'une erreur est levée.

Cas particulier : l'utilisateur invité du Site

TES_Guest n'est pas un rôle utilisateur. Il s'affecte à l'utilisateur invité de votre Site public pour que les signataires externes accèdent aux pages de signature — jamais à une personne de votre org. Voir Installation.