Relations et tags
Modéliser des liens identifiés et des classifications utiles.
Relation ou classification
Une relation relie des objets identifiés : une soumission appartient à un client, un résultat provient d’un travail ou un document sert de source. Un tag classe un objet selon un vocabulaire. Les deux peuvent être affichés ensemble, mais ils ne remplissent pas la même fonction.
La revue d’une classification précise si le Tag concerne le contenu entier ou un passage sélectionné. Ajouter ou retirer un Tag ne réécrit ni le contenu ni ses valeurs. La carte conserve le nom retourné par Surface; si un aperçu ne comporte pas ce nom, elle le signale et laisse ses références exactes consultables dans les détails.
| Élément | Valeurs attendues | Exemple |
|---|---|---|
| Type de relation | Définition déclarée | Soumission du client |
| Source et cible | Identités d’objets compatibles | S-1042 → Atelier Nord |
| Direction | Entrante ou sortante selon le contexte | Soumissions visibles depuis Client |
| Cardinalité | Minimum et maximum déclarés | Un client par soumission |
| Tags | Termes du vocabulaire autorisé | Prioritaire, Entretien |
Définir la politique
Le Model déclare les types de relations, leurs objets compatibles et les effets des opérations. Les contrôles s’appliquent à la création et aux changements de liens. Une vue inverse n’a pas besoin de dupliquer la relation : elle interroge les liens existants dans l’autre direction.
Dans la configuration des champs liés, examinez les conséquences avant de confirmer. Si la réponse reste à vérifier, reprenez la même demande sans changer sa sélection. Si l’enregistrement est confirmé mais que l’affichage échoue, actualisez la lecture sans confirmer à nouveau. Les coordonnées techniques restent consultables dans des détails séparés des noms déclarés.
Exemple
La soumission S-1042 référence Atelier Nord. Les deux objets portent le tag Entretien. Retirer le tag ne supprime pas l’association au client. Ouvrir la fiche client affiche la soumission selon les droits et la Query déclarée.
Les intégrations configurent ces correspondances entre apps; le graphe permet d’explorer leurs relations visuellement.
Exemples appliqués : Un client, plusieurs soumissions
La contrainte porte sur les liens; le groupe de présentation affiche quatre résultats et l’accès à la liste complète.
Configuration
Fragment à placer dans relationPolicies[]. Propriétés et valeurs admises.
{
"contract": "SurfaceRelationPolicy@1",
"key": "quote-client",
"linkTypePath": "application/client",
"source": {
"definitionPaths": [
"workspace/quotes/surface/quote"
],
"fields": []
},
"target": {
"definitionPaths": [
"workspace/clients/surface/client"
],
"fields": []
},
"maximumOutgoing": 1,
"maximumIncoming": null,
"acyclic": false,
"deletion": "forbid",
"maximumTraversalNodes": 1000
}Variante et raccordement
Fragment à placer dans presentation.recordProfiles[].detail.relatedGroups[]. Propriétés et valeurs admises.
{
"key": "quotes",
"label": "Soumissions",
"queryBindingKey": "client-quotes",
"maximumVisible": 4,
"openAllLabel": "Voir toutes les soumissions",
"rowIcon": null
}Exemple de disposition UI
La disposition illustrative ci-dessous situe cette configuration dans l’app Clients/Soumissions. Chaque fragment s’insère à l’emplacement indiqué; ses références aux Fields, Queries et Actions correspondent aux déclarations du Model.
- Client sélectionné
- Recherche
- Soumissions
- Voir toutes les soumissions