Abonnements

Gérer des abonnements à des offres, et uniquement cela.

Ce plugin a pour but de regrouper tout ce qui est commun aux différents types d’abonnements possibles (à des zones restreintes, à des contenus précis, à une version papier pourquoi pas aussi...).

Il permet de définir les offres d’abonnement proposées par le site, et gère les personnes qui y sont abonnées, désactivant l’abonnement au bout d’un temps donné.

Comme il peut y avoir toute sorte de cas, ce n’est pas ce plugin qui décide quels droits sont donnés lors d’un abonnement. C’est à d’autres plugins d’implémenter cela, par exemple pour lier alors automatiquement un utilisateur à une zone restreinte.

Offres d’abonnement

L’élément central proposé par ce plugin est l’offre d’abonnement. Une offre contient :

  • un titre
  • un descriptif
  • une durée (un nombre) et un type de période (mois, jours, ou heures)
  • un prix (qui peut être 0, donc gratuit)

Vous devez donc créer au moins une offre pour ensuite avoir des abonnés. Pour cela il faut aller dans Publication => Offres d’abonnement.

Ajouter un⋅e abonné⋅e

Dans ce plugin, un⋅e abonné⋅e met en relation un⋅e utilisateurice de SPIP et une offre d’abonnement. Cette relation est datée avec un début et une fin.

Pour ajouter des abonné⋅e⋅s, vous devez donc déjà avoir des gens inscrits sur votre site, quelque soit leur statut. Dans la plupart des cas, il s’agira du statut « visiteur », qui sert uniquement dans le site (sans accès à l’admin). Il faut ensuite aller sur la page d’une offre où se situe un lien d’ajout.

Lorsqu’on ajoute un⋅e nouvel⋅le abonné⋅e, il est seulement possible de sélectionner un⋅e utilisateurice. Automatiquement, le formulaire utilisera la date de création comme date de début, et calculera la date de fin en ajoutant la durée de l’offre dans laquelle on se trouve.

Pour des besoins particulier, ces dates sont toujours modifiables après-coup. On peut donc éditer un abonnement, et changer ces deux dates. En revanche, le compte SPIP lié à l’abonnement n’est pas modifiable.

Suivre les abonné⋅es

Sur la page de chaque offre, on trouve la liste des abonné⋅e⋅s à celle-ci. Mais il existe aussi une page de suivi générale qui permet d’avoir une vue d’ensemble de tous les abonnements dans Activités => Suivre les abonnements.

Cette page liste les abonnements actifs dans une liste et les abonnements terminés dans une autre.

Dans tous les listes, vous trouverez un bouton de renouvellement rapide pour chaque abonnement. Cette action va automatiquement changer la date de fin de l’abonnement en ajoutant la durée de l’offre. Si l’offre est pour 12 mois, l’abonnement durera 12 mois supplémentaires.

Notifications de relance

Sur la page d’une offre, il est possible de configurer des dates de relance automatique. Ce sont des emails envoyés aux abonné⋅e⋅s aux dates choisies dans ce formulaire. Comme pour les offres, on choisit une durée (un nombre) et un type de période (mois ou jours).

On peut par exemple ajouter deux relances : 1 mois et 7 jours. Dans ce cas, 1 mois avant la fin, et 7 jours avant la fin, la personne recevra un email l’invitant à renouveler son abonnement.

Il est possible de personnaliser cet email en surchargeant le squelette notifications/abonnement_echeance.html.

Oui mais des abonnements à quoi ?

Comme expliqué précédemment, ce plugin ne gère que le mécanisme central d’abonnement, sans préjuger de ce qui se passe lorsqu’on est abonné⋅e.

Actuellement il existe un premier plugin qui active l’autorisation de voir des contenus restreints lorsqu’on a un abonnement valide : Abonnements à des zones restreintes.

Discussion

18 discussions

  • 2

    Bonjour,
    J’utilise ce plugin depuis plusieurs années couplé à Accès restreint et Abonnement à des zones restreintes, et c’est un gros apport fonctionnel pour mon site.
    Depuis le début, j’ai toujours obtenu : date d’échéance = date de fin, et je me suis basé depuis le début sur la date de fin pour tester la validité d’un abonnement.
    Or dans les dernières versions 4.2.2 et 4.2.3 la date de fin est à 0000. Est-ce voulu ? Dois-je désormais tester la date d’échéance ?
    Merci

    • Hello, ça dépend des cas, en partie oui mais il y a aussi un bug ou dans certain cas la date de fin *aurait dû* être remplie et où ça ne l’est plus, il y a un ticket pour ça pas encore corrigé avec exactement ton questionnement, ici : https://git.spip.net/spip-contrib-extensions/abonnements/issues/31

    • Merci pour ta réponse rapide.
      J’avais chargé les dernières versions d’Abonnements pour tester mon site en Spip 4.2, mais je vais attendre une version stable pour recommencer et essayer de comprendre tes derniers développements et les impacts sur son utilisation.
      Ce qui importe pour moi c’est que les abonnements soient bien désactivés à l’issue de leur durée (fin ou échéance) et donc que l’accès aux zones restreintes soient supprimés.
      à suivre, et merci.

    Répondre à ce message

  • 2

    Bonjour, le plugin abonnement offre par défaut une seule aux offres d’abonnements. J’aimerais savoir s’il est possible d’ajouter une autre taxe. Car je suis au Québec et ici tous les articles vendus sont soumis à deux taxes. Merci d’avance

    • Hello Allagba, alors c’est un (gros) morceau important qui n’a pas de rapport avec le plugin Abonnements en particulier. Ça vaut pour toute la chaine de commerce, quelque soit ce qu’on vend (plugins Prix, Commandes, Produits, etc), et qui pour l’instant n’a jamais été conçu et codé car… personne n’a financé ça, car tout était fait sur des sites Euro avec que la TVA pour l’instant.

      Concrètement tous les plugins en question actuellement ne gère que le cas le plus simple, européen, où il y a juste la TVA. Mais on sait bien, on a tout à fait à l’esprit, que dans plein d’autres pays du monde (dont le Canada mais pas que), il y a parfois un enchevêtrement de taxes différentes, qui sont parfois même complexe (genre des taxes calculées sur le prix HT, et d’autres calculées sur l’addition du HT et de certaines autres taxes, etc).

      On a déjà analysée tout ça avec Tcharlss ya plusieurs années, et on avait commencé à faire la conception d’un vrai plugin Taxe, comme il y a dans Thelia, Drupalcommerce ou autres, et dont le but serait de gérer tous les cas complexes autre que la TVA seule. Mais sauf que ya jamais eu de projets sur lesquels avoir le temps prévu de coder la solution…

      CEPENDANT, on n’a pas rien fait non plus :p
      Il n’y a pas, et n’aura pas avant un moment, de plugins pour gérer par interface l’ajout de multiples taxes selon plusieurs méthodes de calculs MAIS on a commencé une API « taxes », qui permet dès maintenant d’ajouter des taxes supplémentaires pour tel ou tel type d’objets !
      https://git.spip.net/spip-contrib-extensions/prix/src/branch/master/inc/taxes.php#L25

      Pour cela tu as deux possibilités :

      • soit tu crées une fonction taxes_abonnements_offre_dist() dans taxes/abonnements_offre.php, mais dans ce cas faut pas oublier d’utiliser aussi le champ taxe existant
      • soit comme le fallback utilisé déjà le champ taxe tout seul, tu peux aussi t’insérer dans le pipeline « taxes » qui reçoit notamment « objet » en args (cf dans le code ci-dessus) et dans cas la TVA sera déjà appliquée mais tu pourras modifier pour ajouter une taxe supplémentaire

      Voilà ce que je peux en dire pour le moment…

    • Sinon tu pourrais pas appliquer la taxe additionnée directement donc de 14,975 % pour le Québec ? T’as besoin que les deux taxes soient bien différenciées dans les lignes de commande ?

    Répondre à ce message

  • 5

    Bonjour,
    j’ai une erreur qui m’empeche de créer un abonnement avec spip 4.1.9 et abonnement v. 4.0.0. Impossible d’avancer. Pouvez vs m’aider ?

    • Va falloir être beaucoup plus détaillé que ça pour pouvoir t’aider. 🙂

    • Lorsque je suis sur https://monsite/ecrire/?exec=abonnements_offres et que je souhaite « créer une offre d’abonnement » en cliquant sur le bouton, (https://monsite/ecrire/?exec=abonnements_offre_edit&new=oui), j’obtiens une erreur :

      ../prive/echafaudage/contenu/objet_edit.sans_rubrique.html

    • Voici les lignes d’erreurs :

      L128: Unsupported operand types: string * int
      /*001*/ 
      /*002*/    
      /*003*/
      /*004*/<div class='cadre-formulaire-editer'>
      /*005*/<div class="entete-formulaire">
      /*006*/    
      /*007*/    
      /*008*/        Créer une offre d’abonnement
      /*009*/        <h1>Sans titre</h1>
      /*010*/    
      /*011*/</div>
      /*012*/
      /*013*/
      /*014*/        <?php
      /*015*/include_once("./" . _DIR_RACINE . "ecrire/balise/formulaire_.php");
      /*016*/if ($lang_select = "fr") $lang_select = lang_select($lang_select);
      /*017*/inserer_balise_dynamique(balise_FORMULAIRE__dyn('editer_abonnements_offre', 'oui', 'https://monsite.fr/ecrire/?exec=abonnements_offre&amp;id_abonnements_offre=0', ''), array('../prive/echafaudage/contenu/objet_edit.sans_rubrique.html', 'html_fa8f835c4329f06803374be24403815d', '', 0, 'fr'));
      /*018*/if ($lang_select) lang_select();
      /*019*/?>
      /*020*/
      /*021*/</div>
      /*022
    • OK pb de version php.
      Erreur avec 8.1, mais ca passe avec la version php 7.4.33

    • Hello, j’ai fait quelques corrections pour PHP 8 cette semaine, si tu veux retenter

    Répondre à ce message

  • 5

    Bonjour,
    Nous constatons que les abonnements dont la date de début a été modifiée avec une date future ne s’activent pas automatiquement à l’heure donnée. Pourriez vous svp nous faire un retour sur ce comportement ?
    Cdt

    • Oui je crois que c’est tout simplement un manque, ce n’est pas codé du tout cette possibilité. Il faudrait ajouter un génie qui s’occupe de ça.

    • Merci pour la rapide réponse. J’allais faire un plugin spécial pour vérifier les activations mais en vérifiant le code actuel du plugin abo, je remarque

      $liens = objet_trouver_liens(array('job' => '*'), array('abonnement' => $id_abonnement));

      qui me semble t-il doit supprimer toutes les tâches liées à un abonnement donné... cela va me forcer à faire une tache général vérifiant de façon générique les dates de début de tous les abos non activé ayant une date de début passée et une date de fin dans le futur, ce qui n’est pas optimal.

    • Je n’ai pas compris grand chose qu’est-ce qui force à faire quoi pourquoi ? et en quoi un génie n’est pas optimal ? + pourquoi un plugin ? si tu fais partie des gens qui sont capables de faire « un plugin », pourquoi ne ferais-tu pas plutôt une branche et une PR associée qui ajoute ce truc manquant directement pour tout le monde dans le plugin ? :)

      Les discussions sur le code, tickets, PR, c’est ici : https://git.spip.net/spip-contrib-extensions/abonnements

    • Ca me tente assez de contribuer à ce plugin et à Spip de manière plus large. Je dois pour cela me mettre à Git mais mieux vaut tard que jamais :) Par contre en suivant ton lien cela me dit que les inscriptions sont fermées (identification via SSO Git)

    • L’inscription est ici sur Contrib en haut à droite pour contribuer (2e form) : https://contrib.spip.net/spip.php?page=identifiants

      La règle pour un plugin est de faire un ticket, puis une branche dans le plugin avec la ref au ticket (par ex « git branch dev/issue_123_activation_abo_futur && git checkout dev/issue_123_activation_abo_futur »), de pousser cette branche en ligne, puis de faire une PR à partir de cette branche de dev depuis l’interface de la forge.

      Et passer sur IRC si t’as besoin d’aide en direct.

    Répondre à ce message

  • 2

    Bonjour,
    Nous rencontrons un problème sur les abonnements dont la date de début est dans le futur.
    En créant un abonnement, il le met par défaut à la date du jour pour le début et pour la date de fin aujourd’hui+ période. Son statut est actif. Puis l’on édite les dates. En fixant la date de début à une date futur le statu de l’abonnement reste actif, le plugin crée le cron pour la désactivation future. L’on a donc un abonnement actif dont la période de validité n’a pas encore commencée.
    Problème, quand on utilise abo + accès zone, les utilisateurs ont accès à des zones avant d’y être autorisé par leur abonnement.

    On se plante dans l’utilisation, est ce un bug ou un fonctionnement non prévu ?

    Merci à vous
    ++

    Répondre à ce message

  • Flotounette

    Bonjour,
    Une version de ce plugin est-elle prévue pour spip 4.0 ?

    Répondre à ce message

  • 1

    Bonjour,

    Comment faire pour que les abonnements soient mis en bout a bout
    quelque soit l’offre choisie ?

    Si on a par exemple une offre1 de 10 euros pour 6 mois pour
    un service (exemple acces a une partie restreinte d’un site)
    et une offre2 de 15 euros pour un an pour le meme service.

    Si un visiteur choisit d’abord de s’abonner pour 6 mois, puis
    ensuite enchaine pour une autre offre de 6 mois, les abonnements sont mis en serie et c’est parfait.
    Mais si apres avoir choisi un offre de 6 mois, il veut avant la fin de ce premier abonnement, enchainer avec une offre2 de 12 mois : alors, ca ne marche plus, car cette premiere offre2 est creee en parallele et demarre le jour ou il s’abonne, ce qui n’a pas de sens dans ce cas. Les 12 mois devraient aussi pouvoir etre ajoutes apres la fin de son abonnement de 6 mois qui est toujours en cours.

    Ce cas est-il prevu ?
    Sinon, y a t’il un workaround ?

    Merci

    • Non ce n’est pas prévu, et si c’étiat prévu ça ne serait pas comme ça exactement. :)

      Des offres différentes doivent toujours être des offres différentes, un abonnement étant obligatoirement pour UNE offre précise. Donc si on s’abonne à une autre offre : ça crée forcément un autre abonnement, puisque pas la même offre.

      Par contre ce qu’il faudrait, c’est pouvoir choisir (automatiquement et/ou en donnant le choix dans l’interface de commande) quel sera le début de l’abonnement commandé, pas forcément le jour même. Ça c’est clairement dans la todo, mais… quand on me demandera de le faire dans un projet :)

    Répondre à ce message

  • 12

    Bonjour,

    Je teste ce plugin avant mise en production.

    (tests faits avec spip 3.2.4 plugin 3.3.6)

    Je n’arrive pas à avoir de désactivation automatique (par le cron) à l’échéance.
    Ceci parce que objet_modifier se voit refuser l’autorisation par
    autoriser_abonnement_modifier_dist.

    Avec des traces dans autoriser_abonnement_modifier_dist,
    voilà les arguments (avec dump du $qui et de $opt) :

     $qui :
     array(4) {
     	 ["statut"]=> string(0) ""
      	["id_auteur"]=> int(0)
      	["webmestre"]=> string(3) "non"
     	 ["restreint"]=> array(0) {
      }
    }
    
    $faire  :modifier
    $type  :abonnement
    $id  :127
    $opt  :array(1) { ["statut"]=> string(7) "inactif" }

    Dans abonnements.log

    2020-06-21 05:26:36 127.0.0.1 (pid 1252) :Pub:debug: autoriser_abonnement_modifier_dist(modifier, abonnement, 127, ) : niet
    2020-06-21 05:26:36 127.0.0.1 (pid 1252) :Pub:debug: autoriser_instituer_dist(instituer, abonnement, 127, ) : niet
    2020-06-21 05:26:36 127.0.0.1 (pid 1252) :Pub:debug: autoriser modifier abonnement 127 () ?
    2020-06-21 05:26:36 127.0.0.1 (pid 1252) :Pub:debug: autoriser_abonnement_modifier_dist(modifier, abonnement, 127, ) : niet

    C’est refusé parce que id_auteur par le cron est 0 .
    Est-ce un comportement normal ?

    Merci.

    • Pourtant la fonction de désactivation contient parfaitement les exceptions qui disent que ça ne doit pas appeler les autorisations :
      https://git.spip.net/spip-contrib-extensions/abonnements/src/branch/master/inc/abonnements.php#L239

    • Merci Rastapopoulos ,

      Oui, mais c’est en passant par un autre objet_modifier que ça bloque.

      https://git.spip.net/spip-contrib-extensions/abonnements/src/branch/master/abonnements_pipelines.php#L138

      Pour mes tests, je force une date d’échéance pour le jour par l’interface privée ; Et j’attends le travail de la cron. Et alors ça passe par cet objet_modifier, qui n’a pas d’exception.

    • Mais cet appel est aussi à la suite de celui de la désactivation, donc bien avec l’exception autour. Sinon je ne vois pas de quel moment tu parles. Là c’est dans le pipeline, mais le pipeline lui-même il est appelé… quand il y a un objet_modifier sur spip_abonnements, et cet appel là, bah c’est lequel ? Si le tout premier appel qui déclenche toute cette suite est bien celui de la désactivation, il y a bien l’exception autour (elle vaut à l’infini tant que que pas rappelé avec false ensuite).

    • Ce n’est par le genie/abonnements_verifier_echeances.php
      que le pipeline est lancé dans mon exemple de test ?
      https://git.spip.net/spip-contrib-e...
      Si c’était le cas , comme il n’a pas d’exception,
      alors l’objet_modifier du pipeline serait aussi sans exception ?

    • Ah oui et bien ça dépend, c’est pour ça que je demande :)

      Car le truc par défaut de désactivation c’est pas ça, c’est un job prévu à une date bien précise, et qui lance alors la fonction de désactivation à cette date là. Mais ça c’est pour les abonnements qui ont déjà une date de fin.

      La deuxième méthode c’est quand l’échéance (qui n’est pas la date de fin fin fin) est vraiment trop dépassée (parce qu’un paiement automatique n’est pas arrivé par ex, ce qui arrive mais rarement), et effectivement là il manque à priori quelque chose !

      Quel est ton type d’abonnement là ?

    • L’abonnement pour mon site est le plus simple.
      Donc, la date de fin est la même que la date d’échéance .
      Mon test ne reflète pas le fonctionnement réel, c’est vrai.

    • Bé c’est bizarre alors car tu n’entres pas dans ce cas du coup. Si la date de fin est la même que celle de l’échéance, ce qui est toujours le cas quand il n’y a PAS de renouvellement automatique (quand c’est un abonnement « one shot », quelque soit la durée), et bien comme je le disais au début, tu as normalement un job précis (et non pas un génie récurent) qui est mis à la même date de fin que l’abonnement, et qui donc se lance à ce moment pour désactiver (en lançant la fonction abonnement_desactiver() qui contient bien les exceptions).

    • Oui, mais pour mon test, je mettais manuellement la date d’échéance à celle du jour, mais tout en laissant la date de fin dans le futur.
      Voilà sans doute l’explication.
      Mais, le plugin doit en réalité bien fonctionner, comme tu l’expliques, pour mon type d’abonnement.

    • Oui mais pour lé vérif d’échéance, c’est bien dans un génie qu’on change la date directement (c’est pas une autre fonction programmée qui se lance plus tard) et ya pas les ecceptions à cet endroit, donc j’ai ajouté merci (3.5.8)

    • Oui, j’ai essayé, ca règle bien le problème. Le merci , c’est surtout à moi de le dire.
      Une question : pourquoi l’objet_modifier de verifier_echeance ne bloquait pas en premier ?
      C’était seulement l’objet_modifier du pipeline (qui lui déclenchait bien la vérification d’autorisation) qui se voyait logiquement refusé ?
      Par exemple, si on met les exceptions modifier seulement autour de cet appel objet_modifier dans le pipeline : ça marche aussi (et sans exception dans verifier_echeances)

    • Parce que objet_modifier ne fait pas d’autorisation, par contre quand tu changes la date de fin, ça peut demander le changement du statut, et là ça va alors appeler objet_instituer derrière, et par contre celle là demande une autorisation par défaut (perso j’ai toujours dit que les fonctions d’API unitaires « en bout de chaine » ne devrait jamais appeler d’autorisation du tout, cas on doit pouvoir les utiliser de manière scriptée, etc, ou dans des génies, dans des conditions où ya pas d’utilisateur connecté).

    • Merci pour ces explications. C’est plus cohérent.
      C’est vrai que, en pensant le génie comme partie du système, je n’imaginais pas
      qu’il lui faille demander des autorisations :-)

    Répondre à ce message

  • 2

    Bonjour,

    Dans les logs j’ai ceci :

    2020-01-27 06:41:20 109.234.161.155 (pid 16729) :Pub:ERREUR: Erreur 1052 de mysql: Column 'id_abonnements_offre' in where clause is ambiguous
    in /abonnements/v3.3.6/genie/abonnements_verifier_notifications.php L55 [sql_allfetsel(),genie_abonnements_verifier_notifications_dist(),queue_start_job(),queue_schedule(),inc_genie_dist(),cron(),action_cron(),traiter_appels_actions(),include()]
    SELECT id_abonnement, nom, email
    FROM <span class="base64" title="PGNvZGUgY2xhc3M9InNwaXBfY29kZSBzcGlwX2NvZGVfaW5saW5lIiBkaXI9Imx0ciI+YmFzZTwvY29kZT4="></span>.v1_abonnements as a left join <span class="base64" title="PGNvZGUgY2xhc3M9InNwaXBfY29kZSBzcGlwX2NvZGVfaW5saW5lIiBkaXI9Imx0ciI+YmFzZTwvY29kZT4="></span>.v1_auteurs as u on a.id_auteur=u.id_auteur
    WHERE DATE_FORMAT(date_fin, "%Y-%m-%d") = '2020-02-03'
    	AND id_abonnements_offre = 14
    	AND email is not null

    Comme on peut amélioré pour réduire ce log ?

    merci

    Répondre à ce message

  • 1

    Bonjour,

    J’utilise le plugin pour gérer des abonnements (Dans l’idée du suivi de personnes ayant accès à mes contenus).
    Je créé un visiteur et le rattache à un abonnement.
    C’est le fait d’être connecté en public qui lui permet de lire les contenus.
    J’ai créé une page reprenant des infos sur son compte (identifiant et mail + formulaire de contact).
    Je voudrais pouvoir insérer des infos sur l’abonnement (date de fin, nom de l’abonnement,...)

    Comment faire ?

    Merci d’avance

    • Et bien comme n’importe quels autres boucles, dans tes squelettes… la table des abonnements, la table des offres… Si tu as « créé une page », c’est bien que tu crées tes squelettes, donc tu fais pareil que pour n’importe quel autre objet de SPIP. Sans plus de précision je ne vois pas trop quoi répondre de plus :)

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom