Pouvoir générer un lien pour donner un feedback

[patou]

Need from the user's point of view

Plutôt que d'envoyer un mail, on pourrait générer un lien pour partager une demande de feedback.
Cela permet de partager le lien chez le client en utilisant les outils de communication du client.

Technical improvement from the developer's point of view

Le lien n'est donc pas nominatif et peut-être remplit plusieurs fois. Peut-être avoir une expiration du lien ?

[avine]

Plutôt que d'envoyer un mail, on pourrait générer un lien pour partager une demande de feedback. Cela permet de partager le lien chez le client en utilisant les outils de communication du client.

Ubiquitous language :

• receiverEmail : Email du receveur du feedZback (forcément un Z)
• giverEmail : Email du donneur du feedZback (un Z ou un externe)
• recipient : Email du destinataire de la demande de feedZback (c'est donc le giverEmail)

Lorsqu'un Z fait une demande de feedZback, le backend génère en base (Firestore) :

• une entrée dans la collection feedback identifié par l'id du document que nous nommons feedbackId
• une entrée dans la collection feedbackRequestToken identifié par l'id du document que nous nommons tokenId

Le feedbackId est une donnée partagée entre le giver et le receiver du feedback.
Chacun peut avec cet identifiant consulter le feedback dans son historique.

Par contre, le tokenId est un identifiant connu uniquement du giver :

• Si c'est un Z, il peut répondre à la demande à partir de l'application ou à partir de l'email qui lui a été envoyé
• Si c'est un externe, il ne peut répondre à la demande qu'à partir de l'email qui lui a été envoyé

Si le tokenId peut être connu du receiver (le demandeur du feedback) alors le receiver pourrait générer ce token et l'utiliser pour répondre lui-même à sa propre demande.

Dans le cas d'un feedback partagé avec son manager, le receiver pourrait donc usurper l'identité de son client et faire croire à son manager que le client est content par exemple...

[avine]

Le lien n'est donc pas nominatif et peut-être remplit plusieurs fois. Peut-être avoir une expiration du lien ?

Même si pratiquement l'interface permet d'envoyer une demande de feedZback à plusieurs personnes, techniquement, pour chaque recipient sera généré une entrée distincte dans la collection feedback.

Donc chaque recipient aura son propre tokenId lui permettant de répondre à la demande de feedZback.

Le tokenId ne peut donc être envoyé à plusieurs personnes.

La philosophie est qu'une demande de feedZback est nominative.

[patou]

L'idée de cette fonctionnalité est de pouvoir utiliser les outils de nos clients pour envoyer la demande (l'autocomplexion ne sera pas disponible pour tous les fournisseurs de mails des clients).

La création d'un lien, crée une entrée dans la table token.
Le lien peut contenir un token qui ne contient pas de giverEmail, lorsqu'il remplit la demande, il renseigne son email, cela crée alors une entrée dans le feedback. Un email est alors envoyé au giverEmail pour valider l'email, et rendre ainsi le feedback accessible au receiverEmail.

[avine]

Je vois. C'est totalement envisageable.

Le parcours (un peu différent du tien) est le suivant :

• Le receiver fournit son lien à un giver potentiel
• Le giver accède à une page publique dans laquelle on lui dit : vous voulez donner du feedback à receiver, renseignez votre email.
• A ce moment, la demande de feedback est créée (de manière totalement classique - c'est juste que c'est le giver qui a déclenché l'écriture en base et pas le receiver)
• Le giver reçoit l'email classique pour répondre à la demande...

Parfait pour moi.

[avine]

Comme tu l'as évoqué ce lien doit avoir une date d'expiration à déterminer.

Pour obtenir le lien, le Z doit aller dans la page "Mes paramètres".