wf-order-review-request
Objectif
Périmètre 2 du système d’avis : demander une fois au client, une fois le travail terminé.
Une exécution trouve une commande terminée depuis suffisamment longtemps, avec un client à contacter, qui n’a encore jamais été sollicité ; elle crée son lien d’avis personnel à usage unique dans ; puis envoie la demande via rp-reviews.lm-ses
Pourquoi s’agit-il d’un workflow
La question « quelles commandes terminées n’ont pas encore fait l’objet d’une demande ? » couvre deux services
qui n’ont pas le droit de se connaître : ne sait pas ce qu’est unrp-orders
avis, et conserve rp-reviews comme une chaîne opaque. Mettre les deux listes côte à côte est précisément le rôle d’un flow — et orderId permet de fairert.node
survivre la création du lien à un redémarrage sans en créer un second.
Structure
read-settings → list-finished (completed, updatedAt ≤ now − delay)
→ list-invites (lesquelles ont déjà fait l’objet d’une demande)
→ create-invite → send-email → mark-sent | mark-failed
Un seul e-mail par exécution, afin qu’une adresse bloquée ne bloque jamais la file derrière elle, le planning déterminant le débit. génère l’e-mail sans rien créer : une répétition qui laisserait un lien actif ferait que la prochaine exécution réelle ignorerait cette commande, considérée comme déjà sollicitée.dryRun
Un e-mail refusé revient de sous la forme lm-ses, et non sous forme d’exception ; il s’agit donc d’une branche ordinaire qui marque l’invitation comme { success: false } — et non d’une limite d’erreur.failed
Paramètres
(obligatoire) — adresse de l’expéditeur.from(obligatoire) —ses.SesCredentials— injecté dansshopNamedans les modèles.{{shopName}}— remplacedelayHourspour un rattrapage.ReviewSettings.requestDelayHours— générer et s’arrêter.dryRun
L’objet, le corps, la base du lien et le délai proviennent de , afin que la boutique puisse modifier elle-même son texte sans toucher à ce flow.reviews.getSettings()
Dépendances directes du module
g-ordersg-reviewsg-ses
Source
modules/workflows/wf-order-review-request