Cycles de vie

Un état porte un sens métier

Le cycle de vie décrit les états d’un objet et les transitions admises. Pour une soumission, Brouillon, À approuver, Acceptée et Refusée représentent des situations différentes. Un libellé ou une couleur ne définit pas à lui seul les opérations possibles.

Élément	Valeurs attendues	Description
États	Clés stables et libellés	Situations métier reconnues
État initial	Un état déclaré	Situation à la création
Transition	Origine, destination et Action	Changement explicite
Conditions	Règles et droits	Exigences avant changement
Effets	Opérations déclarées	Conséquences de la transition

Exemple

Une soumission naît Brouillon. Demander une approbation la fait passer à À approuver lorsque le client et le contenu sont valides. Accepter exige le rôle autorisé et enregistre la décision. Modifier directement le Field d’état dans une vue ne doit pas contourner cette transition.

Concevoir la reprise

Ouvrez la source archivée concernée, puis Restaurer cette source de fusion. Cette commande ouvre une revue ; elle ne restaure rien avant votre confirmation et la vérification de vos accès.

La restauration technique est distincte d’une transition métier. Restaurer une source archivée par une fusion Knowledge confirmée utilise le reçu d’archive de cette même fusion et une nouvelle revue explicite; cela n’annule ni l’Entry créée ni ses Links de provenance. Les droits actuels et la policy de restauration déclarée restent requis. Une tête archivée ou un périmètre possédé modifié doit être résolu avant confirmation. Après une réponse incertaine, reprendre la demande revue et sa clé d’origine.

Si un descendant était déjà archivé avant la fusion, il reste dans cet état. La fusion ne le réactive pas et ne modifie pas son contenu ; restaurer la fusion ne réactive que les contenus effectivement archivés par cette opération. Les références restent intactes.

Définissez les transitions de correction et de réouverture nécessaires à votre activité. Distinguez l’état métier de la soumission et l’état technique du Flow qui la prépare : une exécution interrompue ne signifie pas que le client a refusé la proposition.

La référence Foundation décrit les déclarations; le suivi des Flows explique leur présentation à l’usager.

Exemples appliqués : Passer de prospect à client actif

La transition Activer vérifie les informations et demande confirmation avant de modifier l’état.

Configuration

Fragment à placer dans lifecycles[]. Propriétés et valeurs admises.

{
  "key": "client-status",
  "definitionPaths": [
    "workspace/clients/surface/client"
  ],
  "fieldKey": "status",
  "initialState": "prospect",
  "states": [
    "prospect",
    "active",
    "inactive"
  ],
  "transitions": [
    {
      "key": "activate",
      "label": "Activer le client",
      "from": [
        "prospect"
      ],
      "to": "active",
      "ruleKeys": [
        "company-required"
      ],
      "confirmation": true
    }
  ]
}

Variante et raccordement

Fragment à placer dans rules[]. Propriétés et valeurs admises.

{
  "contract": "WorkspaceRule@1",
  "key": "company-required",
  "label": "Entreprise renseignée",
  "expression": {
    "kind": "present",
    "field": {
      "definitionPath": "workspace/clients/surface/client",
      "fieldKey": "company"
    }
  }
}

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.

1. Objet concerné
2. Changement proposé
3. Vérifications
4. Confirmer

SurfaceClients / Atelier NordExemple

Cycles de viePasser de prospect à client actif

Clients

AN

Atelier NordSoumission S-1042

À revoir

Changement proposé

La transition Activer vérifie les informations et demande confirmation avant de modifier l’état.

Données et références

Client · Besoin · Tarifs

RevenirExaminer puis confirmer