Commit Graph

24 Commits (master)

Author SHA1 Message Date
RastaPopoulos 124e1e58e4 Moins de warning 3 months ago
Cerdic 121e58b482 PHPDoc, Changelog 9 months ago
Cerdic c55a10dfd5 PSR et indentations 9 months ago
RastaPopoulos e9b79c0b6f Sur la page d'une offre, afficher dans le chemin en haut les contenus où on l'a placé, en mettant de côté quand c'est aussi un objet offre, pour dire que là c'est lié 1 year ago
RastaPopoulos ed5e823e99 Des modifs pour pouvoir lier/placer/classer des offres dans n'importe quel autre objet (par ex les rubriques). Donc configuration quels objets, puis editer_liens sur eux. 1 year ago
Maïeul 114a857b79 oups 2 years ago
Maïeul 324a921c06 Adaptation au fix 4633 du core, qui supprime le sql_quote() sur la date du pipeline optimiser_base_disparus. Cf spip/spip#105
Merci Cedric pour le tip pour compatiblité multi version de SPIP :)

close #4
2 years ago
RastaPopoulos 61a322f9a1 Contournement pour résoudre une boucle infinie quand il y a Champs Extras sur les Abonnements. Normalement on ne devrait pas avoir à utiliser objet_instituer() directement, et CE ne devrait pas ajouter de champs non demandées (quand les modifs sont explicites). En attendant ça devrait résoudre. 3 years ago
rastapopoulos@spip.org a830fdb461 Version 3.1.22 : Et encore un gros bug lié au fait qu'on ne gérait pas les trucs en SEPA qui ont une date de fin nulle ou plus précisément à 0000-00-00 etc. Du coup lors des renouvellements de ces cas là, ça changeait bien les dates pour augmenter l'échéance MAIS ça passait le statut en inactif ! 6 years ago
tcharlss@bravecassine.com dc6be3e4d5 version 3.1.15 : ajout d'un formulaire pour envoyer des notifications ponctuellement aux abonnés d'une offre, en complément des notifications programmées donc. Par exemple, pour notifier les gens dont l'abonnement a expiré et qu'on ne pourrait pas inclure dans les notifications programmées.
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.
7 years ago
peetdu@gmail.com 38b64c6558 Notice PHP en moins. 7 years ago
gornety@no-log.org dd7f805f61 Gestion de prix_ht et taxe pour se rapprocher du fonctionnement de produits
le prix est copié dans prix_ht lors de la mise à jour du plugin
7 years ago
rastapopoulos@spip.org e566d18748 DEUX saloperies de bugs qui cassaient les dates de fin d'abonnement avec paiements récurents : 1) une coquille pourrie de N en trop ! et 2) une mauvaise conception qui créait le lien avec la commande APRES avec initialiser les dates, donc lors de l'initialisation, aucune info de commande, donc aucune date de fin suivant la carte bleue ou SEPA ! 7 years ago
toutati@free.fr 1deeb9bcad Cafouillage du à = au lieu de ==
Ne lier que les offres d'abonnement et pas les autres objets !
8 years ago
rastapopoulos@spip.org fc08368ef9 Lorsqu'on détecte une commande payée pour un abonnement, on détecte aussi si c'est une commande avec renouvellement auto, et si c'est le cas, on force toujours la création d'un nouvel abonnement dédié, jamais de renouvellement d'un ancien. Au passage la fonction pour creer_ou_renouveler est déplacée PAS dans action/ car c'est pas un humain qui appelle ça. On le met dans le inc/ et du coup on a des vrais arguments classiques. 8 years ago
rastapopoulos@spip.org bc0e9dbee0 Virer les jobs quand on vient de demander un autre statut, mais pas à chaque fois que c'est tel statut. 8 years ago
rastapopoulos@spip.org 98d3201a33 inclusion manquante pour chercher les liens 8 years ago
rastapopoulos@spip.org 687e9f2644 On utilise la nouvelle date d'échéance.
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…
8 years ago
rastapopoulos@spip.org 603ebb6d1d Dans creer_ou_renouveler, on ne renouvelle plus que si l'abonnement de même offre *n'est pas trop vieux*. Par défaut on dit 48h mais ça pourra se configurer dans un formulaire un jour. Dès que ça dépasse ces 48h : ça crée un nouvel abonnement différent, avec la même offre. Du coup si une personne se réabonne mais seulement 2 mois plus tard, c'est bien un nouvel abonnement. 8 years ago
rastapopoulos@spip.org 14095d7d85 Lorsqu'une Commande génère ou renouvèle un Abonnement, on fait une liaison entre les deux avec la nouvelle liaison des Commandes. Du coup si on veut utiliser Abonnements avec Commandes, ce n'est pas obligatoire mais par contre on oblige à une version >= 1.5. 8 years ago
rastapopoulos@spip.org 8a7534bf10 Lors de l'initialisation d'un abonnement, quand la date de fin n'est pas encore définie, on continue de le calculer par défaut avec la période de l'offre MAIS on ajoute un pipeline dédié à l'initialisation qui permet de changer les dates (y compris de début pourquoi pas) à ce moment. Cela permet par exemple de toujours terminer avec l'année civile ou de faire pile le début et la fin d'un mois, etc. 8 years ago
rastapopoulos@spip.org ad9fefd033 Deux ajouts notoires :
- 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.
8 years ago
rastapopoulos@spip.org ead8894f5b Quand on supprime un abonnement (poubelle), on doit enlever les tâches liées, sinon ça peut risque de mettre l'abonnement en inactif automatiquement, au lieu de rester dans la poubelle. 8 years ago
rastapopoulos@spip.org b6cc82c746 Accrobranche : en fait on déplace le plugin Abonnements nouvelle génération dans un dossier du même nom que son préfixe, qui n'est plus le même que l'ancienne version. Tout ça n'est en effet pas compatible même si c'est inspiré et à la suite de ce qui existait avant. Le préfixe et le dossier du nouveau suive un nommage plus habituel, avec le nom au pluriel, et les fonctionnalités ne sont pas du tout implémentée pareille, pas la même architecture, etc. 9 years ago