Maarch Digital Flow permet de créer des relations entre les entités gérées dans l'application afin de permettre la navigation dans l'information et créer des structures plu larges à partir d'entités uniques et indépendantes.
Bien que cela ne soit pas systématique, le plus souvent ces relations doivent répondre à des contraintes en lien avec les règles du métier. On peut par exemple souhaiter qu'un dossier à traiter comporte des documents numériques tels que des justificatifs d'identité ou de domicile, ou encore des pièces constitutives.
Dans Maarch Digital Flow, la description de la structure des relations et les contraintes applicables sont décrites par des modèles de relation gérés par l'administrateur. Ces définitions sont ensuites utilisées dans les différentes sections d'administrations des entités.
La section Modèles de relations de l'administration permet de créer et gérer les modèles. L'administrateur habilité l'utilise pour lister les modèles existants, les gérer et en ajouter de nouveaux.
Champ | Type | Description |
---|---|---|
Identifiant | texte |
Le nom utilisé par le système pour identifier le modèle. Il ne peut être changé quand le modèle est en cours d'utilisation |
Libellé | texte |
Le nom affiché aux utilisateurs lorsqu'ils utilisent le modèle |
Description | texte |
Description du modèle |
Le modèle de relation est constitué d'une liste ordonnée de contraintes nommées. La base est donc un objet JSON qui comporte des propriétés (les noms de contraintes) contenant la définition de chaque contrainte :
- constraint_1:
propriétés de contrainte 1
- constraint_2 :
propriétés de contrainte 2
- constraint_3 :
propriétés de contrainte 3
Les propriétés des contraintes sont les suivantes :
Champ | Type | Description |
---|---|---|
position |
entier |
Position d'affichage du conteneur de relations dans l'écran de détail de l'objet utilisant le modèle |
description |
texte |
Intitulé présenté à l'utilisateur |
relationshipType |
identifiant |
Obligatoire Type de la relation, parmi les types déjà déclarés dans l'application |
targetType |
texte |
Obligatoire Type de l'objet cible de la relation, parmi les types gérés dans l'application tels que Dossier , Document ou Utilisateur |
targetSubtypes |
liste |
Liste des identifiants (uniques ou métier) sous-types d'objets acceptés, par exemple si le type cible de la relation est "documetnt numérique" alors cette liste contiendra les types de documents (factures, bulletins de salaire, etc.) qui peuvent être mis en relation |
minOccurs |
entier |
Nombre minimal de relations attendues. Si ignoré, aucun minimum n'est attendu et la contrainte est donc facultative |
maxOccurs |
entier |
Nombre maximal de relations possibles. Si ignoré, le nombre maximal n'est pas limité |
Ci-dessous un exemple de modèle de relations :
- relationshipType_souscription:
position: 1
maxOccurs: 1
minOccurs: 1
targetType: binary-content
description: Document d'origine
targetSubTypes:
- id: bulletin_adhesion
idType: identifier
relationshipType: /relationship-types/4962468c-bf4b-41e8-8754-3a61ee5e496a
- relationshipType_attestation:
position: 2
minOccurs: 1
targetType: binary-content
description: Attestation
targetSubTypes:
- id: attestation_secu
idType: identifier
- id: attestation_employeur
idType: identifier
- id: attestation_honneur
idType: identifier
relationshipType: /relationship-types/bfbde4e9-9c51-4096-9a99-30ce910c2be1
- relationshipType_autre_document:
position: 3
minOccurs: 0
targetType: binary-content
description: Autres documents
relationshipType: /relationship-types/529f9f19-8bbe-4af1-9854-2cdc84341545