Conception statut BSD

Description

Le statut d'un BSD permet:

• d'obtenir en un coup d’œil un "résumé" de l'état d'avancement d'un bordereau sans avoir à regarder le remplissage de chaque champ.
• de catégoriser les bordereaux côté client en filtrant sur ce statut (Brouillon, Pour Action, Suivi, Archives)
• de notifier les consommateurs de l'API du passage du bordereau d'un statut à un autre via les logs de statuts

Plusieurs problèmes ont été évoqués dans la perspective de généraliser les statuts actuels aux autres bordereaux

• Les statuts DRAFT et SEALED correspondent plus à des contraintes de notre UI qu'à une véritable "réalité métier".
• On n'a pas de moyen simple d'intégrer la dissociation de signature producteur / transporteur avec la terminologie actuelle.
• Certains changement de statut peuvent ne pas être liés à une signature (réception du déchet pour les VHU par exemple)
• Difficulté de faire la correspondance entre certains statuts et le contenu du BSD, en particulier: TEMP_STORED, RESENT

Conception retenue

La notion de brouillon n'étant principalement utilisée que par l'UI elle est sortie des statuts.

isDraft : Booleen

Les changements de status nécessitent isDraft=false

Les statuts

• INITIAL
• SIGNED_BY_PRODUCER
• SENT
• RECEIVED
• PROCESSED

Mutations

createDraft (mutation privée)

crée le bsd en INITIAL, isDraft=true, tous champs optionnels

create

crée le bsd en INITIAL isDraft=false, champs émetteur obligatoires.

publish

passe le booleen isDraft de true à false

update

mise à jour champ par champ, renvoie une erreur si isDraft=false et champs obligatoires manquants

---

Propositions de conception (pour archivage)

Benoit

Garder les statuts actuels qui font référence à l'état du déchet en se débarrassant de DRAFT, SEALED et des statuts ne correspondant à aucune signature RECEIVED et TEMP_STORED.

• Créer un statut initial NOT_SENT
• Créer les BSD en "non brouillon" (isDraft=false) par défaut avec validation des données. Dans le workflow actuel, ça revient à faire createForm suivi de markAsSealed.
• Donner la possibilité de créer un bordereau en brouillon en passant le flag isDraft: true lors de la création d'un BSD. Deux possibilités ensuite pour le marquer comme prêt et valider les données:
  • faire un update avec isDraft: false
  • ajouter une petite mutation annexe mark*AsReady en plus de create* et update* qui joue le même rôle que markAsSealed.
• Ne pas ajouter de statut intermédiaire dans le cas particulier de la dissociation des signatures producteur et transporteur. On ira simplement regarder en plus le champ signature correspondant
• Supprimer les statuts intermédiaires de réception sans acceptation. On peut aller voir au besoin le champ receivedAt

Laurent

• Garder DRAFT dans les statuts - le mettre dans un booleen ça implique de gérer un champ suppl en db, de retourner un champ gql supplémentaire (c'est pas comme si on manquait de champs sur le bsd 😆 )
• Remplacer SEALED par un état initial (INITIAL) ou prêt (READY) ou equivalent
• par defaut la mutation créée le bsd en INITIAL (validation sur les champs)
• si on passe le draft isDraft: true on crée le bsd en DRAFT (validation réduite ou absente)
• on a une mutation markAsInital, markAsReady ou whatever (mais cohérente avec le nom du state) je rejoins Orion, on passe de draft à ready par un update

• Edit*

• la question de la validation draft vs ready doit effectivement être creusée, et harmonisée au mieux sur les differents bsd
• au niveau du nommage des statuts, on travaille sur une abstraction d'un document qui est lui même une abstraction d'un déchet, la philosophie initiale marche assez bien, dire qu'un déchet (ou son bsd) est SENT, RECEIVED, PROCESSED, c'est un terme proche du métier que tlm comprend. Les remplacer par AT_TRANSPORTER et cie va être sémantiquement difficile à faire cohabiter avec les cas où il y a plusieurs étapes chez un même acteur (RECEIVED-PROCESSED, REFUSED). De même utiliser des SIGNED_BY_ACTOR ça marche pas forcément partout (sur le dasri on a des signatures optionnelles dépendant de préférence utilisateur

Je suis pas très enthousiaste sur les suppressions de statuts, le statut devrait à lui seul définir l'étape à laquelle se situe le bsd et dans le cas précis de la réception il matérialise le transfert de responsabilité du trs au destinataire. Je ne vois pas l'intérêt d'aller checker des champs annexes: "le bsd est SENT mais comme on a !!receivedAt en fait il est chez le destinataire".

Orion

• avoir un champ isDraft en base, avec valeur par défaut false. Si on veut un brouillon il faut préciser explicitement isDraft=true (donc la notion de draft est optionelle et peut être complètement ignorée par la plupart des gens)
• je n'aime pas trop l'idée des markAs*. Il me semble qu'on en est sorti avec notre modèle de signature et je trouve dommage d'y revenir pour un cas particulier. Pour moi la seule manière de passer de brouillon à non brouillon doit être via un update. On n'agit plus sur le statut du bordereau, on le complète et on le signe
• pour les statuts je pense qu'on pourrait se passer d'étapes intermédiaires. A mon avis l'information qui compte est "chez qui est le bordereau actuellement ?". Ca pourrait donner qque chose du genre "AT_EMITTER", "AT_TRANSPORTER", "AT_RECIPIENT", "AT_TEMP_STORER", "DONE" (ou peut être PROCESSED / REFUSED, à voir...)
• Si on veut plus de détail alors on regarde dans les champs. Niveau temporalité ce n'est pas exactement la réalité terrain (quand le transporteur signe, le bordereau passe tout de suite à "AT_RECIPIENT" alors qu'il n'a pas encore été transporté), mais c'est la réalité de qui a la main sur les modifications du bordereau. Donc ca peut marcher je pense.)

Gabin

La notion de draft a un impact assez fort sur les étapes à suivre avant d'arriver à l'enlèvement et sur la façon dont sont validé les données. Du coup je verrai bien :

• Une mutation createDraft qui crée un BSD au status DRAFT (ou NOT_READY). Ça permettrait de rendre la création d'un draft explicite sans avoir à ajouter un champ "virtuel". Ça permet également d'avoir un schéma plus explicite au niveau des champs requis de l'input (et éventuellement de la valeur retournée).
• Une mutation publish qui fait passer un BSD de DRAFT (ou NOT_READY) à READY (à voir pour le nom exact) avec la validation complète.
• Une mutation create qui crée un BSD au status READY avec la validation complète.

Au niveau des status je pense qu'il faut qu'on colle au plus près de ce qu'on sait avec des termes simples. Des status du type SIGNED_BY_PRODUCER, SIGNED_BY_TRANSPORTER, RECEIVED_BY_TEMPORARY_STORAGE, etc. Et je pense que si on dit que le status sert à déterminer l'état du déchet, il faut qu'il soit exhaustif. Sinon on peut se retrouver avec plein de cas particuliers et le risque qu'il ne soit pas utile parce que pas suffisant.