...
- Le nom peut correspondre ou non à une nomenclature (détaillée après) permettant le pré-remplissage lors de sa saisie par l'utilisateur final. Dans tous les cas Esup-signature utilisera ce nom comme identifiant du champ.
- Cocher ou non "Obligatoire"
- Cocher ou non "Lecture seule"
- Dans la partie "Format" du champ, 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.
Pour ce faire le nom du champ doit être construit comme suit :
...
| Info |
|---|
Depuis la version 1.2, la nomenclature des champs à changée. Les comportements spécifiques sont à configurés dans l'onglet "Calcul" puis la partie "Script de calcul personnalisé". 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 |
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 completion 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(0,1); | les champs seront modifiables aux étapes 0 et 1 |
| Remarque |
|---|
Concernant les numéros d'étape, l'étape zéro (0) correspond à la saisie du formulaire (première saisie par l'utilisateur). L'étape 1 correspond à la première étape du workflow, ainsi de suite... |
Voici un exemple de l'édition d'un formulaire dans esup-signature :
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 accéssible 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 normale mais qui illustre la possibilité de cumuler pré-remplissage et auto-completion) et enfin, modifiable à l'étape 0
Dans l'exemple suivant le nom du champ est "prenom$ldap(givenname)#1", traduction : le champ est nommé "prenom" il sera pré-rempli en utilisant la classe de données externes "ldap" (voir LdapExtValue.java) avec le champ "givenName" et uniquement modifiable à l'étape 1 du circuit
...
.
Esup-signature est fourni avec les classes DefaulExtValue et LdapExtValue. La classe DefaultExtValue est utilisable en mettant "$defaultdefault" dans le nom du champservice. 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 se qui . Ceci répond à une grande partie des besoins. Cependant, tout comme cela peut être le cas pour les workflows, il ce 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)
...