Classes de composants

    Une classe de composants définit les caractéristiques communes d’un même ensemble logique de composants. Ces ensembles sont caractérisés par des tags (ou métadonnées), une sécurité, des règles métiers ou techniques qui leur sont propres.

    Cette partie définit la notion de classe de composants utilisée pour caractériser les composants (documents, dossiers, tâches…) manipulés au sein de l’application. Ainsi tout composant référence une classe de composants via son identifiant.


    Une classe de composants permet de définir une typologie de composant :

    • les tags pouvant être associés à un composant
    • la sécurité par défaut à appliquer via la définition d’un identifiant d’ACL à appliquer
    • les catégories de tags afin de regrouper visuellement les tags au sein de blocs fonctionnels
    • des libellés internationalisés afin de fournir une application multilingue
    • le caractère technique

    En fonction de la catégorie de la classe de composants, des spécificités peuvent être ajoutées.

    Il est possible de caractériser un tag référencé sur une classe de composants par les paramètres suivants :

    • Obligatoire : indique si une valeur est obligatoire pour la validation
    • Technique : indique si l’utilisateur a accès à ce tag
    • Lecture seule : indique si l’utilisateur peut modifier ou non la valeur du tag
    • Multivalué : indique si le tag peut avoir plusieurs valeurs ou non
    • Valeur par défaut : la valeur par défaut lorsque le tag n’est pas rempli (des variables peuvent être utilisées pour les dates comme ${dayDate})
    • Un masque de validation (expression régulière) : si défini, surcharge celui défini au niveau de la classe de tags
    • Ordre d’affichage
    • Une description permettant d’afficher une infobulle


    Une classe de tâches permet de définir le modèle de tâche à créer. Ses spécificités sont :

    • une icône (exemple: fa fa-envelope)
    • un identifiant de workflow
    • les réponses possibles
    • les pièces jointes attendues

Pièces jointes

Lors du traitement d’une tâche, il peut être nécessaire que l’utilisateur ajoute un ou plusieurs composants.

Ces composants sont appelés des pièces jointes d’une tâche et sont définis de manière globale par classe de tâches.

Chaque pièce jointe attendue possède les attributs suivants :

  • un identifiant
  • un nom internationalisé
  • la définition d’une classe de composants (identifiant et catégorie)
  • une liste de tag : définit précisément les métadonnées des pièces jointes

Ces pièces jointes peuvent être également être caractérisées par les paramètres suivants :

  • requise : définit si la pièce jointe doit nécessairement être ajoutée pour valider les modifications apportées à la tâche, requise plus tard ou bien facultative
  • technique : définit si la pièce jointe doit être affichée ou non aux utilisateurs
  • multivaluée : définit si la pièce jointe peut être composée de plusieurs composants
  • lecture seule : définit si les utilisateurs peuvent modifier la pièce jointe (l’aspect lecture seule d’une pièce jointe dépend également des permissions définies au niveau de la tâche)

Pour décrire une pièce jointe, il est possible de définir :

  • une description qui sera affichée au survol (avec la souris) de la pièce jointe
  • un résumé affiché sous le nom du composant ajouté comme pièce jointe

Résumé

Le résumé peut être configuré, par langue du scope, pour afficher les tags du composant attaché (exemple: ${Priority} Créé par ${owner})

Par défaut, le résumé affiche la date de création du composant.

Pour aller encore plus loin, il est possible d’utiliser la JSAPI pour définir votre propre résumé. Une partie y est dédiée ici.

Réponses

Les réponses permettent d’orienter les tâches dans une direction proposée par un workflow. Chaque réponse possède les attributs suivants :

  • un identifiant
  • un nom internationalisé
  • un message de confirmation internationalisé

Réponses avec motif

Il est possible de définir une réponse avec motif de la façon suivante :

<ns4:answers xsi:type="ns4:ReasonedAnswerDefinition" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<id>Initiate</id>
	<ns4:displayNames language="EN">
		<ns3:value>Send</ns3:value>
	</ns4:displayNames>
	<ns4:displayNames language="FR">
		<ns3:value>Envoyer</ns3:value>
	</ns4:displayNames>
	<ns4:reasons tagName="Matricule" order="0" mandatory="true">
		<ns4:descriptions language="EN">
			<ns3:value>MXXXX - Enter the id of new adherent</ns3:value>
		</ns4:descriptions>
		<ns4:descriptions language="FR">
			<ns3:value>MXXXX - Identifiant du nouvel adhérent</ns3:value>
		</ns4:descriptions>
		<ns4:pattern>^M[0-9]*$</ns4:pattern>
	</ns4:reasons>
	<ns4:reasons tagName="Comments" order="0" mandatory="true" />
</ns4:answers>

Pour ajouter un motif avec un pattern, il faut définir les propriétés suivantes :

  • descriptions, la description internationalisée du tag lorsque l’utilisateur n’a pas encore saisi de valeur dans le champ
  • pattern, la règle à appliquer

Par exemple, la règle ^M[0-9]*$ permet d’accepter uniquement les valeurs commençant par M et se terminant par des chiffres.


Contrairement aux dossiers virtuels qui sont composés de recherches permettant de trouver dynamiquement les composants, les dossiers ont un modèle physique par le biais d’un lien parent-enfant avec les composants qu’ils contiennent.


Une classe de dossiers permet de définir le modèle de dossier à créer. Sa spécificité est la notion d’enfant.


Enfants

La classe de dossiers permet de définir quelles sont les classes d’enfants qu’elle est autorisée à contenir. Il est possible d’en définir autant que possible. Si le besoin est de contenir toutes les classes d’un type de composant, par exemple, tous les documents, il est possible d’ajouter un enfant avec l’identifiant * de la façon suivante :

<ns2:children category="DOCUMENT">
		<id>*</id>
</ns2:children>


Contrairement aux dossiers qui ont un lien parent-enfant avec les composants qu’ils contiennent, les dossiers virtuels sont composés de recherches permettant de trouver dynamiquement les composants.


Une classe de dossiers virtuels permet de définir le modèle de dossier virtuel à créer. Sa spécifité est la notion de recherche.


Les dossiers virtuels d’une même classe partagent une même liste de recherche, qui leur permet d’avoir la même forme de présentation des composants.

La particularité des recherches des dossiers réside dans la possibilité d’agréger les résultats en fonction d’un critère et la variabilisation des recherches.

Agrégation

Si la recherche définie dans le dossier contient une agrégation, les composants remontés par la recherche seront regroupés sous forme de Bucket. Il est également possible d’imbriquer des agrégations pour avoir des buckets basés sur plusieurs critères.

Variabilisation des recherches

Dans les recherches d’une classe de dossiers virtuels, les critères définis peuvent être des valeurs fixes ou bien sous forme de variable. Le fonctionnement est identique aux tags conditionnels pour la résolution de variable.

Grâce à ce mécanisme, il est possible de définir un même dossier virtuel de Banette personnelle en utilisant un critère assignee = ${user.id}. Les variables de types tags se basent sur les tags portés par le dossier virtuel.