Classes de composants

    Une classe de composant définie 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 leurs sont propres.

    Cette partie définie la notion de classe de composant 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 composant via son identifiant.


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

    • les tags pouvants être associé à 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 internationnalisés afin de fournir une application multi-langue
    • le caractère technique

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

    Lorsqu’un tag est référencé sur une classe de composant, il est possible ensuite de le caractériser avec les paramètres suivants :

    • Obligatoire : indique si une valeur est obligatoire pour la valdiation
    • Technique : indique si l’utilisateur a accès à ce tag
    • Lecture seule : indique 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 tag
    • Ordre d’affichage
    • Une description permettant d’afficher une infobulle

    ComponentClass —→ TagReference —→ TagClass


    Une classe de tâche 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âche.

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

    • un identifiant
    • un nom internationalisé
    • la définition d’une classe de composant (identifiant et catégorie)
    • une liste de tag : définit précisemment 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ées 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})

    S’il n’est pas défini le résumé affiche la date de création du composant.

    Pour aller encore plus loin et définir votre propre résumé, il est possible d’utiliser la JSAPI pour définir ce 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é 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 et la définir 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 internationisé 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 dossier permet de définir le modèle de dossier à créer, sa spécificité est la notion d’enfant.


    Enfants

    La classe de dossier permet de définir quels 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 cette façon :

    <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 dossier virtuel 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’aggréger les résultats en fonction d’un critère et la variabilisation des recherches.

    Aggrégation

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

    Variabilisation des recherches

    Dans les recherches d’une classe de dossier virtuel, 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.