Produits Entr'ouvert » w.c.s.

Sinon on connait comment l'email du demandeur ?

Je me suis déjà retrouvée confrontée à ce souci, pour Ha-Py, effectivement il faut dans le workflow configurer l'adresse comme autre et indiquer la variable du formulaire.
J'imagine comme difficulté, le cas où on demande plusieurs courriels dans un formulaire, comme parent 1, parent 2 et on voudrait (ou au contraire on ne voudrait pas) que les 2 adresses reçoivent le courriel.

Pour poser le contexte plus général :

• on peut préremplir un champ avec des données du profil de l'usager, dont l'email,
• ça indique de manière assez sûre que dans ce champ se trouvera l'adresse email de l'usager,
• on utilise donc cette adresse comme étant l'adresse email de l'usager qui a déposé la demande.

Quand on est face à un usager pas connecté,

• il n'y a pas de préremplissage,
• mais on ne perd pas de vue le fait que le champ est prévu pour l'adresse email de l'usager,
• et donc on utilise donc cette adresse comme étant l'adresse email de l'usager qui a déposé la demande.

S'il n'y avait pas de configuration de préremplissage, pour indiquer que le champ est prévu pour l'adresse email de l'usager, on aurait deux options :

• prendre un champ email quelconque dans la demande, risque que ça ne corresponde pas,
• ajouter une option pour dire "dans ce champ email viendra l'adresse email de l'usager", mais c'est assez redondant vu que le préremplissage dit déjà ça.

Je me suis déjà retrouvée confrontée à ce souci, pour Ha-Py, effectivement il faut dans le workflow configurer l'adresse comme autre et indiquer la variable du formulaire.

Je ne sais pas de quel soucis il est question ici.

Frédéric Péters a écrit :

Je me suis déjà retrouvée confrontée à ce souci, pour Ha-Py, effectivement il faut dans le workflow configurer l'adresse comme autre et indiquer la variable du formulaire.

Je ne sais pas de quel soucis il est question ici.

Pas un souci technique, simplement je n'avais pas paramétré le workflow comme il faut dans une démarche sans compte et sans remplissage. Aucun mail envoyé. On avait échangé là-dessus et c'est réglé.

S'il n'y avait pas de configuration de préremplissage, pour indiquer que le champ est prévu pour l'adresse email de l'usager, on aurait deux options :

• prendre un champ email quelconque dans la demande, risque que ça ne corresponde pas,

• dans le cas d'un formulaire n'ayant qu'un seul champ de type courriel alors ce champ est utilisé comme courriel de l'usager, qu'il soit pré-rempli ou pas (ce doit être le cas de la très grande majorité de nos formulaires),
• dans le cas d'un formulaire avec plusieurs champs de type courriel, on reste en l'état actuel, le pré-remplissage pour l'un de ces champs doit explicitement signaler le courriel souhaité pour communiquer avec l'usager.

dans le cas d'un formulaire n'ayant qu'un seul champ de type courriel alors ce champ est utilisé comme courriel de l'usager, qu'il soit pré-rempli ou pas (ce doit être le cas de la très grande majorité de nos formulaires),

Ça demanderait alors l'introduction d'une option pour débrayer ça.

Notamment parce qu'il faut se rappeler que sur une demande associée à un usager, on pose quand même la préférence sur le champ saisi dans la demande. À ça vient la réponse "ok on prendrait la valeur s'il y a un seul champ uniquement quand la demande n'est pas associée à l'usgager", et continue ainsi l'escalade.

Brice Mallet a écrit :

S'il n'y avait pas de configuration de préremplissage, pour indiquer que le champ est prévu pour l'adresse email de l'usager, on aurait deux options :

• prendre un champ email quelconque dans la demande, risque que ça ne corresponde pas,

Ce qui serait possible :

• dans le cas d'un formulaire n'ayant qu'un seul champ de type courriel alors ce champ est utilisé comme courriel de l'usager, qu'il soit pré-rempli ou pas (ce doit être le cas de la très grande majorité de nos formulaires),
• dans le cas d'un formulaire avec plusieurs champs de type courriel, on reste en l'état actuel, le pré-remplissage pour l'un de ces champs doit explicitement signaler le courriel souhaité pour communiquer avec l'usager.

Je vois deux demandes dans les remarques d'Anaïs, effectivement prendre un compte un champ email même si on a pas configuré le pré-remplissage (et ça tu essaies d'y répondre), mais aussi notifier deux emails comme étant considéré "l'usager" et ça on pourrait le faire son gérait que la méthode qui retourne l'email de l'usager puisse en retourner plusieurs (et à mon avis c'est déjà nécessaire parce que lorsqu'une demande est faite pour le "compte de" avec un compte connecté on devrait notifier l'email configuré mais aussi l'email du compte si elles diffèrent).

• modifier formdef.get_submitter_email() et ses sites d'appel pour pouvoir retourner plusieurs emails (dédoublonner en comparant en ignorant la casse et les blancs et en favorisant l'email dans formdata.user.email, celle-ci est validée)
• en l'absence de champ pré-rempli, toujours considérer le premier champ email comme l'email de l'usager + l'email de l'utilisateur attaché à la demande
• sinon prendre tous les champs pré-remplis + l'email de l'usager attaché à la demande, donc ça gère papa + maman ou demandeur/bénéficiaire

Ça me semble répondre à tout.

Benjamin Dauvergne a écrit :

mais aussi notifier deux emails comme étant considéré "l'usager" et ça on pourrait le faire son gérait que la méthode qui retourne l'email de l'usager puisse en retourner plusieurs (et à mon avis c'est déjà nécessaire parce que lorsqu'une demande est faite pour le "compte de" avec un compte connecté on devrait notifier l'email configuré mais aussi l'email du compte si elles diffèrent).

oui, ça se serait très utile, j'ai déjà échangé avec des collectivités là-dessus, notamment pour ceux qui mettent une place un véritable accompagnement, et ça ferait le job avec moins de paramétrage côté workflow.

Frédéric Péters a écrit :

Allez hop pas de changement.

bah, t'as fermé le ticket bien vite...

mais aussi notifier deux emails comme étant considéré "l'usager" et ça on pourrait le faire son gérait que la méthode qui retourne l'email de l'usager puisse en retourner plusieurs (et à mon avis c'est déjà nécessaire parce que lorsqu'une demande est faite pour le "compte de" avec un compte connecté on devrait notifier l'email configuré mais aussi l'email du compte si elles diffèrent).

oui, ça se serait très utile, j'ai déjà échangé avec des collectivités là-dessus, notamment pour ceux qui mettent une place un véritable accompagnement, et ça ferait le job avec moins de paramétrage côté workflow.

La saisie qui a lieu "pour le compte de", en backoffice, envoie bien à l'usager renseigné et/ou sélectionné, et pas à l'agent, et on ne veut pas envoyer ces mails à l'agent d'accueil.

Si le propos est maintenant de discuter de pratiques à adopter, comme laisser dans les formulaires un champ de contact supplémentaire, pour que je puisse y taper l'adresse de ma sœur, parce qu'en fait c'est elle qui a saisi la demande parce que je me suis cassé les deux bras, svp pas dans un ticket wcs.

Anaïs, pour ton besoin de notifier 2 ou x personnes, rien ne t'empêche aujourd'hui d'indiquer un autre champ mail (destinaire : Autre => saisie de la bonne variable)

Marie Kuntz a écrit :

Anaïs, pour ton besoin de notifier 2 ou x personnes, rien ne t'empêche aujourd'hui d'indiquer un autre champ mail (destinaire : Autre => saisie de la bonne variable)

oui, c'est déjà ce que je fais, je réagissais simplement au ticket de Corentin avec un autre retour utilisateur, pour faire avancer les choses, mais on a fini par se perdre dans ce ticket, je crois,

Frédéric Péters a écrit :

La saisie qui a lieu "pour le compte de", en backoffice, envoie bien à l'usager renseigné et/ou sélectionné, et pas à l'agent, et on ne veut pas envoyer ces mails à l'agent d'accueil.

Ce que je j'appelle "pour le compte de" n'a rien à voir avec Publik et son backoffice, c'est simplement le fait de faire une demande pour quelqu'un d'autre en front; dans ce cas il est fréquent de séparer le demandeur et le bénéficiaire dans les données du formulaire. C'est assez fréquent d'avoir cette séparation dans les formulaires administratifs (c'est vrai qu'on le voit assez peu chez nous j'ai l'impression).