Archives de la liste a​i​d​e​@p​a​h​e​k​o​.c​l​o​u​d​

Échec majoritaire d'envoi de Message collectif sur Recherche enregistrée (complexe ?)

Eric Buissonnet

19/10/2022 11:09:28

Bonjour,

J'ai une recherche enregistrée qui me permet de lister l'ensemble des 
membres inscrits à une activité donnée, depuis la date d'ouverture de 
ladite activité (à période définie).

Cette requête SQL, qui nécessite d'accéder à des tables autres que la 
seule table 'membres', fonctionne bien en tant que telle. Elle produit 
moins de 100 lignes.

Par contre, lorsqu'elle est utilisée pour envoyer un message collectif, 
la majeure partie du temps le message collectif échoue avec un 
explicatif variable, voir les deux captures d'écrans. Et parfois je 
passe le cap de la prévisualisation ????

A bien relire la documentation, de plus en plus précise merci l'équipe, 
je n'ai pas trouvé quelles sont les colonnes à sortir pour qu'une telle 
requête soit - aussi - utilisable pour générer la liste des 
destinataires d'un message collectif. J'ai un instant cru que rajouter 
la colonne en "_user_id" allait suffire, mais non !

Merci,
Eric

La requête utilisée :

SELECT
   m.id AS _user_id,
   m.nom AS 'Nom',
   s.label AS 'Activité',
   f.label AS 'Tarif',
   su.paid AS 'Payé',
   su.date AS 'Date'
FROM membres m
   INNER JOIN services_users su ON su.id_user = m.id
   INNER JOIN services s ON s.id = su.id_service
   INNER JOIN services_fees f ON f.id = su.id_fee
WHERE s.id = 1 AND su.id_fee = 2 AND su.date >= s.start_date
ORDER BY m.nom ASC LIMIT 1000
;

Échec majoritaire d'envoi de Message collectif sur Recherche enregistrée (complexe ?)

Eric Buissonnet

30/10/2022 16:37:07

Bonjour,

Je me permets de relancer ce problème d'envoi collectif handicapant qui 
joue sur la confiance des responsables d'activités à utiliser Garradin 
aussi pour les envois collectifs ; la bonne vieille feuille Excel 
d'avant est toujours prête ????

En attendant qu'ils puissent utiliser une routine qui cible les seuls 
adhérents de l'année à leur section (le problème décrit dans l'envoi du 
19/10) j'ai créé une routine palliative qui n'utilise que la table 
membres ; elle arrose un peu plus large que nécessaire, pas grave. Je 
n'ai jamais eu avec cette routine les pb que j'ai avec celle plus ciblée 
du 19/10.

Hier un responsable d'activité m'a dit avoir utilisé la routine 
palliative, qui adresse 81 membres, et pourtant je n'ai nulle trace en 
date ou en nombre dans la table *emails *de cet envoi (et je n'étais pas 
à côté !) ; perso je n'ai jamais eu de pb avec l'envoi collectif (à part 
la situation 19/10), mais je ne m'adresse à guère plus que 4 personnes 
(et pour le moment, j'hésite à arroser tout le monde pour un test, mais 
je prends soin de tester avec les mêmes droits que les responsables 
d'activité que j'arrive jusqu'au bouton "Envoyer")

Y-a-t-il un pb avec des envois en nombre tel 81 membres ? Y a-t-il 
d'autre situations connue/suspectée d'échec en envoi collectif ?

A bientôt, merci
Eric

Le 19/10/2022 à 11:09, Eric Buissonnet a écrit :
>
> Bonjour,
>
> J'ai une recherche enregistrée qui me permet de lister l'ensemble des

> membres inscrits à une activité donnée, depuis la date d'ouverture de 
> ladite activité (à période définie).
>
> Cette requête SQL, qui nécessite d'accéder à des tables autres que la

> seule table 'membres', fonctionne bien en tant que telle. Elle produit

> moins de 100 lignes.
>
> Par contre, lorsqu'elle est utilisée pour envoyer un message 
> collectif, la majeure partie du temps le message collectif échoue avec 
> un explicatif variable, voir les deux captures d'écrans. Et parfois je 
> passe le cap de la prévisualisation ????
>
> A bien relire la documentation, de plus en plus précise merci 
> l'équipe, je n'ai pas trouvé quelles sont les colonnes à sortir pour

> qu'une telle requête soit - aussi - utilisable pour générer la liste 
> des destinataires d'un message collectif. J'ai un instant cru que 
> rajouter la colonne en "_user_id" allait suffire, mais non !
>
> Merci,
> Eric
>
> La requête utilisée :
>
> SELECT
>   m.id AS _user_id,
>   m.nom AS 'Nom',
>   s.label AS 'Activité',
>   f.label AS 'Tarif',
>   su.paid AS 'Payé',
>   su.date AS 'Date'
> FROM membres m
>   INNER JOIN services_users su ON su.id_user = m.id
>   INNER JOIN services s ON s.id = su.id_service
>   INNER JOIN services_fees f ON f.id = su.id_fee
> WHERE s.id = 1 AND su.id_fee = 2 AND su.date >= s.start_date
> ORDER BY m.nom ASC LIMIT 1000
> ;
>

Échec majoritaire d'envoi de Message collectif sur Recherche enregistrée (complexe ?)

BohwaZ/Garradin

30/10/2022 20:01:43

> Y-a-t-il un pb avec des envois en nombre tel 81 membres ? Y a-t-il 
> d'autre situations connue/suspectée d'échec en envoi collectif ?

Aucun souci pour envoyer à 81 membres, ou même 1500 ou 3000 membres ;)

Après je ne sais pas si tu es sur Garradin.eu ou en auto-hébergement.

La table emails ne contient *QUE* la liste des adresses invalides.
La table emails_queue contient la liste des messages en attente d'envoi
(sur Garradin.eu ils sont envoyés toutes les minutes, donc il n'y a
quasiment pas d'attente).

Les envois ne sont pas enregistrés actuellement : une fois que les
messages sont expédiés, ils ne laissent aucune trace. Sauf si tu es sur
Garradin.eu auquel cas dans "Abonnement Garradin.eu" -> "Statistiques
emails envoyés" tu as le nombre de messages envoyés mais c'est tout.

Si le message a été envoyé (car c'est possible que ton membre ait aussi
oublié de cliquer sur envoyer après l'étape de prévisualisation),
alors, comme quand tu envoie un e-mail toi-même depuis ta messagerie, le
message est délivré au serveur destinataire mais après on ne sait pas
ce qu'il devient (à moins de recevoir un message indiquant que
l'adresse est invalide, ou que le message a été bloqué pour spam, cas
qui sont traités automatiquement par Garradin).

On a maintenant un très bon taux de délivrabilité, de l'ordre de 99%,
donc seuls 1% des messages envoyés ne parviennent pas au destinataire,
donc normalement sur 81 destinataires tu devrais avoir une bonne partie
qui ont reçu les mails :)