Introduction
Esup-signature propose une interface d’administration qui permet le suivi des demandes en cours, le paramétrage des circuits de signatures ou des formulaires, ainsi que divers outils qui seront détaillés après.
La configuration générale de l'application se fait via le fichier de configuration application.yml avant la compilation du projet voir : Configuration
Enfin pour des besoins très précis il est possible d’écrire directement des classes spécifiques pour gérer les sources de données, le pré-remplissage des formulaires ou encore pour décrire des circuits de signatures.
Pour avoir accès à l'espace "Admin" l'utilisateur doit disposer du rôle ROLE_ADMIN tel que défini dans la propriété group-mapping-role-admin: du fichier de configuration voir : Configuration securité
Liste des demandes
La vue demande est la première vue accessible lorsque que l'on clique sur "Admin" dans la barre de navigation (ou sur la couronne)
Elle permet à l'administrateur de consulter toutes les demandes. Les demandes peuvent être filtrées en fonction de leur statut
Pour autant, l'administrateur ne peut pas consulter les documents, il peut simplement vérifier la liste des événements et si besoin supprimer les demandes.
Les circuits
Voir la page dédiée aux circuits : Gestion des circuits
Les formulaires
L'autre fonction principale d'Esup-signature est la possibilité de mettre rapidement en ligne des formulaires. Cette fonction s'appuie sur les PDF Forms (formulaires présent dans les fichiers PDF). Esup-signature est capable d'analyser les formulaires PDF, d'en effectuer le rendu (via PDF.js) et de stocker les données saisies dans sa base de données.
La mise en place du formulaire basé sur un PDF se fait en 3 étapes : création du circuit des signatures, création du PDF puis import dans Esup-signature
Création d'un PDF Form
Pour éditer un fichier PDF et créer un formulaire, il faut se doter d'un outils dédié. L'université de Rouen utilise Adobe Acrobat PRO. Sous linux il existe Master PDF Editor (payant)
L'opération consiste à placer les champs de formulaire puis à les configurer de la bonne façon.
Les champs doivent être configurés comme suit:
- Le nom. Esup-signature utilisera ce nom comme identifiant du champ.
- Cocher ou non "Obligatoire"
- Cocher ou non "Lecture seule"
- Esup-signature gère les champs texte, cases à cocher, liste déroulantes
- Dans la partie "Format" des champs texte, sont gérés par esup-signature les type : Nombre, Date et Heure
- Toutes les autres options n'auront aucun effet sur le comportement d'Esup-signature
Une nomenclature de nommage des champs peut être utilisée pour signifier à Esup-signature d'opéré un traitement spécifique à un champ. On peut, via un nommage correcte, préciser si le champ doit être pré-rempli par Esup-signature et à quelles étapes le champ est modifiable.
Depuis la version 1.2, la nomenclature des champs a changée. De plus, il n'est plus nécessaire de configurer ces comportements directement dans le fichier PDF. Il est maintenant possible de (re)définir la configuration après import du modèle PDF dans esup-signature
Les comportements spécifiques sont à configurés dans l'onglet "Calcul" puis la partie "Script de calcul personnalisé" au niveau des propriétés des champs d'Acrobat Pro.
La syntaxe à utiliser au niveau des scripts de calcul des champs est la suivante :
| Fonction | Syntaxe | Traduction |
|---|---|---|
| Pré-remplissage d'un champ | prefill.ldap(person, sn); | esup-signature va pré-remplir le champ avec la valeur de l'attribut "sn" de l'objet "person" provenant de la source de données "ldap" et correspondant à l'utilisateur courant |
| Auto complétion d'un champ | search.ldap(person, displayName); | lors de la saisie le champ va proposé les valeurs du "displayName" correspondant a la piste des "person" trouvés dans "ldap" |
| Activation du champ en fonction de l'étape | step.update(1); | les champs seront modifiables aux étapes 0 et 1 |
Il n'y a plus d'étape 0. L'étape 1 correspond à la première étape du workflow. Si l'on veut que le créateur saisisse en premier le formulaire, il faut créer une étape 1 avec "visa" et "créateur de la demande" comme participant.
Voici un exemple de l'édition des champs d'un formulaire dans l'interface administrateur d'esup-signature ("Admin" → "Formulaire" → "Modifier les champs" :
On voit ici les propriétés du champ modifiables via l'interface. Si la syntaxe mise en place dans le modèle PDF Form est correcte, les champs seront pré-configurés. Sinon il est possible de reprendre la configuration sur cet affichage accessible dans le menu "Admin" → "Formulaire" → "Liste des champs".
Sur cette copie d'écran on voit que le champ "prenom" est configuré comme suit : Obligatoire, pré-rempli du "givenName" de l"utilisateur courant, avec une auto-completion qui retour le givenName (exemple pas vraiment utile en temps normal mais qui illustre la possibilité de cumuler pré-remplissage et auto-completion) et enfin, modifiable à l'étape 0.
Esup-signature est fourni avec les classes DefaulExtValue et LdapExtValue. La classe DefaultExtValue est utilisable en mettant "default" dans le nom du service. Elle propose les données (calculées) suivante :
- numéro du jour (day)
- numéro du mois (month)
- numéro du l'année (year)
- date du jour (date)
- heure (time)
- date et heure (dateTime)
- nom prénom de l'utilisateur courant (currentUser)
- un numéro d'ordre (id). Le numéro d'ordre sera incrémenté lors de la dernière étape du circuit configuré pour ce formulaire
Comme c'est le cas pour les classes workflow, vous pouvez créer vos propre classes de données externes en implémentant le type "ExtValue" en reprenant DefaultExtValue.java par exemple.
Classe de pré-remplissage
Pour pré-remplir ou auto-compléter un formulaire, Esup-signature se base une une classe de "pré-remplissage" du type "PreFill". D'origine Esup-signature est fourni avec la classe DefaultPreFill qui prend en charge les données externes de type Default et Ldap. Ceci répond à une grande partie des besoins. Cependant, tout comme cela peut être le cas pour les workflows, il se peut qu'il soit nécessaire de calculer certaines données à pré-remplir spécifiquement pour un formulaire (donnée calculée en fonction de l'utilisateur courant par exemple). Dans ce cas il y a là encore la possibilité d'implémenter votre propre classe de type PreFill (voir DefaultPreFill.java pour l'exemple)
Import du formulaire
Lorsque le formulaire PDF est terminé, il faut l'importer dans Esup-signature. Pour cela il faut aller sur "Admin" puis "Formulaire" puis cliquer sur le bouton bleu "+" et enfin sur l'icone PDF.
Vous devez saisir un nom (technique) et un titre (beau titre), sélectionner votre modèle PDF Form, saisir un rôle pour definir qui peut accéder à ce formulaire, choisir le type de pré-remplissage, un circuit qui aura été créer au préalable et éventuellement un dossier de destination.
Lorsque vous validez le formulaire, Esup-signature analyse le PDF Form et constitue la structure du formulaire. Sur cet exemple, on voit qu'il a bien pris en compte la nomenclature des champs. Il est possible de modifier les informations saisies lors de la création en cliquant sur le bouton jaune "crayon"
Votre formulaire sera disponible sur la page d'accueil des personnes autorisées à y accéder. Voici un exemple du rendu dans Esup-signature :
L'utilisateur peut corriger et compléter le formulaire puis l'enregistrer. Après un premier enregistrement, il aura la possibilité d'envoyer définitivement ça demande en cliquant sur le bouton bleu "lecture" et en saisissant (si besoin) les noms des destinataires
Les messages d'information
Esup-signature propose un système permettant transmettre des messages d'information à tous les utilisateurs. Pour cela, il faut se rendre sur "Admin", "Messages" puis cliquer sur le bouton bleu "+"
Vous pouvez alors saisir un message ainsi qu'une date de fin de diffusion. Tous les utilisateurs verront ce message et auront la possibilité de le désactiver une fois consulté.
Gestion des rôles
Dans esup-signature, il y a deux façons d'obtenir des rôles:
- à l'aide de filtre LDAP si votre environnement le permet voir :Sources et configuration
- en possédant un groupe dans vos attributs de session dont le prefix correspond à celui configuré dans group-to-role-filter-pattern, voir : Sources et configuration
- à l'aide group-mapping-spel qui permet de définir les règles d'attribution de groupes, voir : Sources et configuration
Pour accéder à l'application il faut impérativement avoir le rôle : ROLE_USER. Pour la partie administration, il faut ROLE_ADMIN
Les rôles obtenus seront copiés dans le profil de l'utilisateur. Un utilisateur peut obtenir des rôles du type : staff, student, test, ordre_de_mission, marches, etc.... ceci grâce à des groupes correspondant au pattern group-to-role-filter-pattern (le texte qui suit le préfixe est converti en rôle ex : ROLE_ORDRE_DE_MISSION) ou à l'aide de mapping-groups-roles
Les rôle autres (que user et admin) peuvent être utilisés lorsque vous configurez un formulaire ou un circuit pour y restreindre les accès.
Pour une explication détaillée du fonctionnement de la sécurité, voir : Configuration de la sécurité
Switch user
Le switch user permet à l'administrateur de prendre la place d'un autre utilisateur. Cela peut être utile pour reproduire ou constater un problème spécifique à un utilisateur. Toutefois, pour des raisons de confidentialité, cette option n'est pas active par défaut. Pour débloquer cette fonctionnalité il faut modifier le fichier application.yml et mettre la valeur enable-su à true