Le mode management doit permettre de modifier les valeurs entrées dans les formulaire en prenant en compte les différents états des variables.

• COLLECTED, la variable entrée par l'utilisateur
• EDITED, variable modifiée par l'administrateur
• FORCED, variable modifiée par une valeur calculée

Cela se traduit au niveau de l'interface par de nouveaux boutons situés à droite des champs qui permettent d'agir sur la valeur et son état.

On veut aussi pouvoir suivre l'historique des changement avec plusieurs valeurs associé à chaque réponse.

Proposition technique

D'après les besoins, Lunatic ne peut pas porter la responsabilité de cette logique car l'état des variables et la priorité dans le choix de la valeur est dépendant de la logique choisit par l'orchestrateur (la notion de "valeur la plus récente" varie en fonction du contexte). Il est d'ailleurs prévu dans Lunatic de retirer cette notion d'état pour qu'il ne reçoive que les valeur associé à chaque question (plutôt qu'un objet d'état qu'il ignore actuellement).

// Lunatic actuel
{
  "NOM": {  
    "COLLECTED": "John", 
    "PREVIOUS": null, // Ignoré par lunatic 
    "FORCED": null,   // Ignoré par lunatic  
    "EDITED": null,   // Ignoré par lunatic  
    "INPUTTED": null, // Ignoré par lunatic
  }
}

// A l'avenir
{
	"NOM": "John"
}

C'est l'orchestrateur qui se chargera de réconcilier les variables à envoyer au hook useLunatic() en correspondance avec ses propre règles. Lunatic conservera lui les variable entrée dans le formulaire mais ne se charge pas de gérer l'état. Côté orchestrateur les variables pourront être sauvegardé avec une historisation.

   {
      "type": "PREVIOUS",
      "value": "John1",
      "timestamp": "2021-01-01T08:05:32:011"
    },
    {
      "type": "COLLECTED",
      "value": "John",
      "timestamp": "2022-01-02T08:05:32:011"
    },
    {
      "type": "EDITED",
      "value": "john doe",
      "timestamp": "2022-01-03T11:47:27:128"
    },
    {
      "type": "FORCED",
      "value": "John Doe",
      "timestamp": "2022-01-03T12:05:32:011"
    },
    {
      "type": "EDITED",
      "value": "Jane Doe",
      "timestamp": "2022-01-04T11:47:27:128"
    }

Comme on le voit ici c'est l'ordre qui détermine la valeur à sélectionner pour l'affichage plutôt que l'état de la variable. Cette logique ne peut être portée que par l'orchestrateur qui a une connaissance de la logique métier (reprise des variable).

Implications côté orchestrateur

Dans le cadre de la solution précédente il y a plusieurs développement à prévoir côté orchestrateur :

• Création d'une fonction qui permet de réconcilier les données pour les envoyer ensuite à plat à Lunatic (prendre la valeur la plus récente).
• Écoute du changement des valeur (via onChange) pour enregistrer les modifications des variables dans l'historique.
• Création de composants react pour créer les boutons de changement d'état (libellé de l'état de la variable, bouton reset...)

Implication côté Lunatic

Côté Lunatic il faudra prévoir un moyen de simplifier l'injection de composants avant et après un champs pour permettre l'intégration des nouveaux contrôles attendu pour la reprise des données.

Il faudra aussi prévoir un moyen de désactiver les filtres pour permettre une navigation dans le formulaire dans son intégralité en cas de besoin (à confirmer).

Maquette Figma : https://www.figma.com/file/fDaBco0WxIXZ68DRBYEk4n/PERRET?node-id=1099%3A69152&mode=design