Pas de doublon : si on envoie une notification et qu'elle est déjà programmée le même jour, elle ne partira qu'une seule fois.
On peut choisir les abonnements en fonction de leurs statuts et de leurs dates de création/fin.
Il y a une étape de vérification avant d'envoyer pour éviter les fausses manoeuvres.
1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction :
- si c'est SEPA, on annule la date de fin, par défaut ça sera infini
- si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a
1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair.
2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant.
3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard.
4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée.
5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement.
Ce n'est PAS FINI. Il manque :
- rendre configurable les deux délais qui sont en lire_config()
- afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement
- possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic)
- sûrement plein de bugs à corriger, j'espère pas trop…
- Quand on modife les dates d'un abonnement, ça vérifie si aujourd'hui on est dedans ou dehors, et ça active ou désactive l'abonnement automatiquement. Il est toujours possible de changer le statut manuellement pour mettre inactif même si on est dans les bonnes dates, ou inversement.
- Surtout, le plugin est désormais copain avec Commandes : quand un utilisateur commande des offres d'abonnements, alors dès qu'il a enfin payé, ça le détecte et ça crée un nouvel abonnement OU ça renouvelle un existant si on en avait déjà un avec cette offre. Au passage, on ajoute donc une action pratique "creer_ou renouveler_abonnement" qui sait bien faire les choses en lui donnant un auteur et une offre.
- Pour que tout marche, on déplace "inactif" en statut par défaut (premier), pour que ça le change ensuite, et que "abonnements à des zones" détecte bien une activation lors de la toute première création.
Maïeul
RastaPopoulos