Galette

Frederic CROZET a écrit :

Hello,

Hello !

C'est un problème récurent que je rencontre depuis des années pour les courriels de rappel des échéances de cotisation.
La liste des rappels d'échéances (« Échéances proches » et « Échéances dépassées ») est toujours correcte (hormis l'anomalie #1590).

Oui, merci pour les infos que tu fais remonter sur le tracker :)
Elles me sont bien utiles pour mieux comprendre le fonctionnement de galette dans le cas de cotisations par durée.
Car le problème ne se produit pas a priori dans le cas de cotisations par date de début d'exercice (ou alors dans une bien moindre mesure).

Par contre, certains rappels ne génèrent pas de courriels. Et j'ai donc des adhérents qui ne sont pas informés de leurs échéances.
Et je ne comprends pas pourquoi.

Il y a peut-être des erreurs dans les tests unitaires des rappels (#1612).
C'est ce qui ressort de #1590.
S'assurer que les tests sont corrects devrait nous aider à mieux comprendre ;

A priori, lors de la première échéance (1ière année) tout fonctionne parfaitement, tout le monde reçoit des courriels.

Il y a plein de raisons indépendantes de Galette qui peuvent empêcher la réception d'un email.
Difficile de confirmer l'existence d'un dysfonctionnement de Galette sur ce simple constat.

À moins d'une erreur d' expédition qui serait alors normalement mentionnée dans les logs, une fois que les emails sont expédiés, la réception n'est plus du ressort de Galette :/

Par contre pour les échéances suivantes (2nd année, 3ième ...etc.) certains rappels ne fonctionnent pas alors pour que pour certains autres tout fonctionne.

Rien n'exclue un problème dans le calcul des échéances qui déclenchent les rappels.
C'est plus probablement de là que proviendrait le souci.

Le problème est le même quelque soit le type d'échéance proches et dépassées.
Je n'arrive pas à expliquer ce dysfonctionnement.
Est-ce une limitation du nombre de courriel envoyé?

Il existe effectivement des quotas sur les rappels envoyés par Galette.
Je sais que tu utilisais les rappels automatiques jusqu'à récemment (#1604).
À quelle fréquence déclenches-tu tes rappels ?

• dans le cas des retards :
  - un premier après 1 mois de retard
  - un second après 2 mois de retard
• dans le cas des échéances proches
  - un premier dans une période d'un mois précédant l'échance
  - un second dans les 7 jours précédant l'échéance

Les cotisations précédentes ont été régularisées avec + de 60 jours après l'échéance ??
Aujourd'hui par exemple, j'ai 4 sur 8 échéances proches qui n'ont pas généré de courriels et 4 sur 6 retardataires également...

Les dates d'échéances pour les emails non générés entre-elles bien dans les délais dont j'ai fait état ci-dessus ?

Hello,

Car le problème ne se produit pas a priori dans le cas de cotisations par date de début d'exercice (ou alors dans une bien moindre mesure).

Effectivement, je suis en "durée d’adhésion par défaut" de 12 mois

Il y a plein de raisons indépendantes de Galette qui peuvent empêcher la réception d'un email.
Difficile de confirmer l'existence d'un dysfonctionnement de Galette sur ce simple constat.
À moins d'une erreur d' expédition qui serait alors normalement mentionnée dans les logs, une fois que les emails sont expédiés, la réception n'est plus du ressort de Galette :/

Il n'y a pas de génération de courriel. Et je ne l'avais pas précisé précédemment mais j'ai rien dans les logs.

Rien n'exclue un problème dans le calcul des échéances qui déclenchent les rappels.
C'est plus probablement de là que proviendrait le souci.

Je pense aussi...
Lorsque j'efface la ligne d'un membre, dont les relances ne fonctionnent pas, dans la table "galette_reminders" tout refonctionne pour lui au moins pour cette année.
Voir un ancien échange avec Johan a ce sujet : [[https://listengine.tuxfamily.org/lists.galette.eu/users/2020/12/msg00010.html]]

Il existe effectivement des quotas sur les rappels envoyés par Galette.
Je sais que tu utilisais les rappels automatiques jusqu'à récemment (#1604).
À quelle fréquence déclenches-tu tes rappels ?

Auparavant, j'étais sur un déclenchement par tâche cron hebdomadaire. Puis comme il y avait des loupés, je suis passé à journalière.
Bon depuis, les relances par tache "cron" ne sont plus opérationnelles donc je suis sur des relances manuelles (1 à 3 par semaine). Ces derniers temps pour chercher à comprendre, je suis plutôt à un rappel journalier.

Les dates d'échéances pour les emails non générés entre-elles bien dans les délais dont j'ai fait état ci-dessus ?

Oui, et ils apparaissent bien dans la liste des échéances. Et j'ai bien compris le principe des deux rappels d'échéance proche et des deux autres pour les retardataires.
Notre association est un club canin avec des adhérents qui s'inscrivent tout au long de l'année. C'est un réel confort ces relances automatiques pour la gestion des cotisations de nos 120 adhérents.

Pour ma culture générale, je ne comprends pas trop le rôle de la table galette_reminders.
La colonne "reminder_date" est la date de la dernière relance, a priori.
et je n'ai pas compris également la fonction de la colonne "reminder_type" 1 ou 2 ?

Pour info, les relances, qui ne fonctionnent pas, ne mettent pas à jour "reminder_date" qui reste à l'échéance de Janvier 2021 par exemple ;)

Frederic CROZET a écrit (#note-5):

Pour ma culture générale, je ne comprends pas trop le rôle de la table galette_reminders.
La colonne "reminder_date" est la date de la dernière relance, a priori.
et je n'ai pas compris également la fonction de la colonne "reminder_type" 1 ou 2 ?

Pour info, les relances, qui ne fonctionnent pas, ne mettent pas à jour "reminder_date" qui reste à l'échéance de Janvier 2021 par exemple ;)

Cette table stocke les relances envoyées. La date est al date d'envoi, ça permet de respecter les "délais" codés en dur dans Galette.
Quant aux 1 (échéances proches) et 2 (en retard), c'est défini dans le code : https://github.com/galette/galette/blob/develop/galette/lib/Galette/Entity/Reminder.php#L77

Donc rien à voir avec #1590.

Le problème viendrait plutôt de là : source:galette/lib/Galette/Repository/Reminders.php#L143

        foreach ($results as $r) {
            if ($r->reminder_type < $type) { // <- ICI
                //sent impending, but is now late. reset last remind.
                $r->reminder_type = $type;
                $r->last_reminder = '';
            }

Cette condition peut-elle seulement être vérifiée malgré la requête (source:galette/lib/Galette/Repository/Reminders.php#L100) ?

        $select->join(
            array('r' => PREFIX_DB . self::TABLE),
            'a.' . Members::PK . '=r.reminder_dest',
            array(
                'last_reminder' => new Expression('MAX(reminder_date)'),
                'reminder_type' => new Expression('MAX(reminder_type)') // <- ICI
            ),
            $select::JOIN_LEFT

• un membre pourra recevoir les 2 rappels d'échéance proche pour sa première année d'adhésion, mais il ne pourra plus jamais en recevoir les années suivantes : source:galette/lib/Galette/Repository/Reminders.php#L163
• un membre pourra recevoir les 2 rappels d'échéance en retard pour sa première année d'adhésion, mais il recevra uniquement le rappel à 60 jours les années suivantes : source:galette/lib/Galette/Repository/Reminders.php#L180

Guillaume Agnieray a écrit (#note-7):

Si le reset du dernier rappel n'intervient jamais :

• un membre pourra recevoir les 2 rappels d'échéance proche pour sa première année d'adhésion, mais il ne pourra plus jamais en recevoir les années suivantes : source:galette/lib/Galette/Repository/Reminders.php#L163
• un membre pourra recevoir les 2 rappels d'échéance en retard pour sa première année d'adhésion, mais il recevra uniquement le rappel à 60 jours les années suivantes : source:galette/lib/Galette/Repository/Reminders.php#L180

Hum... OK, il faudra que je voie à ajouter ces cas dans les tests ; pour reproduire dans un premier temps, et m'assurer que ce soit corrigé ensuite. Les pistes que tu donnes semblent cohérentes, merci :)

Hello,

En reprenant le sujet récemment, j'ai pu (je pense, et j'espère !!) reproduire le cas.

J'ai repris les tests qui fonctionnent sur les différents rappels, et j'ai ajouté un set de rappels pour la "période" précédente. Le test échouait, aucun rappel n'était jamais trouvé... Il m'a donc semblé être tombé sur le problème rapporté ici.

J'ai donc modifié le code pour que soit correctement prise en compte la date d'envoi des rappels, qui sera ignorée si l'envoi a été effectué la période précédente (en fonction de la configuration de Galette).

Le correctif est là :
https://github.com/galette/galette/pull/373

Les tests portent sur une durée d'adhésion, mais normalement ça devrait fonctionner dans la cas d'une date de fin d'exercice.

Je croise les doigts.

J'aimerai un retour avant d'aller plus loin (peut-être que je me suis totalement fourvoyé :D), mais dans l'absolu, les modifications que je propose peuvent avoir un effet de bord : les anciens adhérents qui n'ont pas contribué depuis plus d'une période se verront envoyer un rappel...
Il faudrait donc je pense limiter également les adhérents sélectionnés sur leur date de fin d'adhésion (ça ne va pas spécialement être simple si tel est le cas).

Johan Cwiklinski a écrit (#note-11):

J'aimerai un retour avant d'aller plus loin (peut-être que je me suis totalement fourvoyé :D)

OK. J'essaie de tester les modifs dès que possible :)

Suite au récents tests unitaires et corrections tentées : https://github.com/galette/galette/pull/376

En admettant que j'ai 3 membres dans ma base.
Dont un qui est exempt de cotisation et donc n'a jamais reçu de rappel depuis son inscription.
Les 2 autres sont à jour et ont déjà reçu tous les rappels sur la période précédente ainsi que le premier rappel d'échéance proche pour la période en cours le mois dernier.

Si je ne dis pas de bêtises, voici ce que devrait retourner la requête juste après la jointure, non ? :

Et pour les autres rappels qui devraient normalement y figurer, dans les logs j'ai :

127.0.0.1 - 2023-12-07 11:38:11 - DEBUG - Reminder does not suits current requested type ArrayObject Object
(
    [storage:ArrayObject:private] => Array
        (
            [id_adh] => 2
            [date_echeance] => 2023-12-14
            [last_reminder] => 2023-11-14 00:00:00
            [reminder_type] => 2
        )

)

127.0.0.1 - 2023-12-07 11:38:11 - DEBUG - Reminder does not suits current requested type ArrayObject Object
(
    [storage:ArrayObject:private] => Array
        (
            [id_adh] => 3
            [date_echeance] => 2023-12-14
            [last_reminder] => 2023-11-14 00:00:00
            [reminder_type] => 2
        )

)

La jointure agrège pour chaque id_adh la valeur maximale des colonnes last_reminder et reminder_type enregistrée dans la table reminders .
Je pense que la jointure devrait se faire sur le résultat d'une requête sur la table reminders qui renverrait pour chaque id_adh les valeurs max enregistrées, mais pas directement sur la table elle-même, non ?

Hello,

Guillaume AGNIERAY a écrit (#note-13):

Suite au récents tests unitaires et corrections tentées : https://github.com/galette/galette/pull/376
[...]

Il faut que je me plonge dans le code, et que je mette en place un test qui va reproduire ce que tu décris.

Dans l'absolu, la requête est censée renvoyer tous les adhérents en retard, avec pour chacun d'entre eux la date - et le type - de dernier rappel. Normalement, le type est censé être le bon, sauf bug préalable -- c'est pourquoi on le récupère.