Demande de fonctionnalité : J’aimerais pouvoir proposer un abonnement qui ne dure que pour une seule période. À la fin de cette période :
L’utilisateur devrait être retiré du groupe Discourse de l’abonnement (ce qui, je pense, n’arrive pas avec les paiements uniques actuels).
Aucun paiement supplémentaire ne devrait être effectué.
Solution possible ? Le plugin Discourse Subscriptions devrait permettre de définir l’attribut iteration d’un calendrier d’abonnement. J’ai trouvé cela dans la documentation Stripe, sur la page de l’API des calendriers d’abonnement :
Définir la durée d’une phase
L’intervalle d’un prix détermine la fréquence de facturation d’un abonnement. Par exemple, un intervalle mensuel est facturé chaque mois. Les phases ont un attribut iterations que vous utilisez pour spécifier la durée d’une phase. Multipliez cette valeur par l’intervalle pour déterminer la durée de la phase. Si un calendrier d’abonnement utilise un prix avec un intervalle mensuel et que vous définissez iterations=2, la phase dure deux mois.
…
Achèvement d’un calendrier
Les calendriers d’abonnement se terminent une fois la dernière phase terminée. À ce stade, l’abonnement est conservé et n’est plus associé au calendrier. Si vous souhaitez annuler un abonnement après la fin de la dernière phase d’un calendrier, vous pouvez définir end_behavior sur cancel.
Non, malheureusement, ce plugin présentait trop d’idiomes et de fonctionnalités manquantes. Je ne sais pas s’il a été modifié depuis ma question, cependant.
N’hésitez pas à nous faire part de tout autre point sensible que vous rencontrez avec ce plugin. Je pense être au courant de la plupart, mais il y a encore des aspects sur lesquels j’aimerais en savoir plus. Par exemple, j’aimerais en apprendre davantage sur votre perception de la fonctionnalité de campagne. Y a-t-il quelqu’un ici qui l’a utilisée ?
J’utilise la campagne pour betterstreets.nz. C’est bien, mais assez rigide. Je l’ai mise en place il y a 9 mois, et elle continue de fonctionner (bien qu’extrêmement lentement !).
Mon plus gros problème est que je ne peux pas actuellement faire en sorte que les gens donnent simplement un montant X ; au lieu de cela, ils doivent s’abonner annuellement.
De plus, c’est présenté dans les mêmes termes - c’est-à-dire par mois. Cela rend les montants étranges, et ce n’est pas vraiment la façon dont la plupart des gens pensent pour une campagne : de zéro à X en tant que montant absolu. Même si c’était présenté annuellement, ce serait bien mieux.
Les bannières sont correctes (en haut pour les pages de découverte et en bas pour les sujets), mais ne sont pas très personnalisables. Ce serait bien de les rendre plus grandes ou plus petites afin de s’intégrer au reste du site (par exemple, d’autres bannières / pieds de page).
Une fois dismissées par un utilisateur sur un appareil, ce serait bien de pouvoir les forcer à réapparaître occasionnellement, ou de les réduire à quelque chose de beaucoup plus discret (mais toujours présent jusqu’à ce que la personne ait fait un don).
Je vois. Je me suis inscrit à votre forum pour vérifier cela et je comprends ce que vous voulez dire.
Peut-être serait-il bon de ne pas les rendre dismissibles du tout ? Ils ne semblent pas très intrusifs et fournissent des informations précieuses, même aux personnes qui ont déjà fait un don. Cela donne à la communauté un objectif commun et les donateurs méritent d’être reconnus pour leur contribution.
Il existe de nombreuses façons de créer des bannières dans Discourse. Quelle méthode utilisez-vous actuellement ?
Quelque chose que j’ai remarqué : je n’étais pas au courant qu’il était possible de faire un don à votre entreprise avant de m’inscrire au forum. Comme nous le savons, la plus grande partie de l’audience sera constituée de lecteurs passifs et seule une petite minorité décidera de s’inscrire.
Il semble donc judicieux d’afficher la bannière de la campagne également aux utilisateurs non connectés. Je suis sûr qu’il y a beaucoup de gens qui aimeraient faire un don mais qui ne sont pas actuellement des membres actifs / enregistrés.
Dans betterstreets.nz, j’utilise uniquement la bannière qui fait partie de la section campagne du plugin Subscriptions. Sa présence m’empêche d’ajouter d’autres bannières !
J’utilise d’autres bannières sur d’autres sites cependant.
Je suis tout à fait d’accord - mais seulement si c’était très clair et facile pour eux de le faire !
Je ne me souviens pas du jargon de Stripe, mais l’ensemble du plugin tourne autour de leur ancienne façon de faire (qui n’autorise que les cartes de crédit) plutôt que de la nouvelle façon (qui autorise une grande variété d’options de paiement).
L’annulation est décrite de manière confuse (de mémoire, il s’agit de l’annulation du renouvellement automatique mais elle semble être décrite comme une annulation immédiate).
J’ai ajouté pas mal de sujets sur le plugin il y a quelque temps. Beaucoup n’ont reçu aucune réponse, c’est donc une bonne chose d’apprendre que vous travaillez maintenant sur le plugin. Edit : voici un lien – Search results for 'tags:subscriptions @Jonathan5' - Discourse Meta
Ce serait également formidable si un abonnement pouvait être effectué en même temps que l’inscription au forum. Actuellement, le processus en deux étapes n’est pas idéal dans tous les scénarios.
J’ai réussi à résoudre l’abonnement unique avec un intervalle de temps en ajoutant de nouvelles métadonnées (“recurring:0/1”) dans l’objet price. Et lorsque vous essayez de créer un abonnement avec price[:metadata][:recurring]==“0”, je définirai la valeur cancel_at_end = true dans l’objet Subscription.
Ensuite, lorsque vous créez un prix unique, vous devez toujours choisir un intervalle (année, mois, jour, semaine), mais vous ne devez pas cocher la case “recurring”.
Et lorsqu’un utilisateur y souscrit, le backend créera un abonnement récurrent qui se terminera à la date de fin. L’utilisateur n’aura pas besoin d’annuler le renouvellement par lui-même.
Je perds le fil de ces sujets variés ! Bonne chance pour tout ça. Cela fait une éternité que je n’ai pas essayé le plugin, donc je ne peux pas vraiment aider, malheureusement.
Ce sujet est devenu plutôt confus. Il ne m’apparaît pas clairement comment je peux le démêler proprement.
Je suggérerais cependant que tout le monde essaie de s’en tenir à un seul problème/fonctionnalité par sujet afin qu’ils soient plus faciles à suivre et à garder en mémoire.
Vous devez également ajouter le secret du webhook Stripe à l’instance Discourse (en tant que paramètre du plugin “webhook secret”). Vous pouvez le trouver dans l’exemple de code à droite dans le formulaire de création de webhook sur Stripe.
J’ai réalisé une courte vidéo pour donner un aperçu des structures de données et de leur connexion aux structures de données Discourse :
Je suis à peu près d’accord avec cela, mais cela devrait être corrigé maintenant. Vous pouvez configurer tout ce que vous voulez dans Stripe avec cela (méthodes de paiement / taxes / tableau de prix, etc.) et tout devrait fonctionner.
Le plugin gère simplement la connexion entre les utilisateurs Discourse et les clients Stripe, et la création de produits, de plans, etc. est entièrement gérée dans le tableau de bord Stripe.
Il peut encore y avoir des bugs. Si vous remarquez quelque chose, veuillez le signaler.
C’est donc un fork que vous prévoyez de soumettre en tant que demande de PR pour le plugin officiel une fois qu’il sera un peu plus peaufiné ? Si c’est le cas, c’est génial !!! Et merci pour votre bon travail et votre énergie à ce sujet !
Si c’est le cas, je vais l’essayer sous peu. Il faudra un peu de bidouillage pour le tester entièrement, bien sûr.
[quote=“spirobel, post:17, topic:246395”]vous devrez exécuter la CLI Stripe localement pour relayer les messages webhook. Voici la commande à utiliser :
stripe listen --forward-to http://localhost:4200/subscriptions/hooks --api-key y
[/quote]
Où exécutons-nous cela ? Sur le serveur en tant que root, ou dans le conteneur Docker ? Et utilisons-nous notre URL d’instance avant /subscriptions/hooks ?
Et juste pour m’assurer que je fais la bonne chose, est-ce que c’est ce que nous installons à la place du plugin officiel ?
Ceci n’est nécessaire que pour une instance de développement qui s’exécute localement sur votre ordinateur. Par exemple, vous pouvez voir dans la vidéo que mon instance Discourse s’exécute sur localhost:4200, ce qui signifie qu’elle s’exécute sur mon ordinateur.
Si vous souhaitez recréer cet environnement exact, vous pouvez suivre ce guide :
Étant donné que le serveur Stripe ne peut pas atteindre l’adresse localhost:4200 sur mon réseau local, il est nécessaire d’exécuter cette commande pour relayer les requêtes webhook provenant du serveur Stripe.
Si vous souhaitez essayer cela sur un serveur connecté à Internet, vous pouvez suivre la configuration du webhook du tutoriel officiel : Discourse Subscriptions Plugin
Veuillez ne pas l’installer (encore) sur une instance qui contient déjà des données clients en direct et l’ancienne version du plugin Discourse Subscriptions. Essayez-le sur un second serveur de staging, car les deux versions seront en conflit.
Merci beaucoup de tester ceci ! Cela permettra également aux visiteurs qui n’ont pas encore de compte d’acheter un plan. Ils seront automatiquement invités à l’instance Discourse et auront les appartenances de groupe appropriées une fois qu’ils auront payé.
J’ai un site en production relativement calme (betterstreets.nz) avec seulement 3 clients, moi y compris, suite à une expérience précédente essentiellement ratée. Je serais tout à fait disposé à le tester là, en supprimant le plugin précédent et ses données si nécessaire (bien qu’il me faudrait un coup de main pour la commande Rails console correcte). Aurais-je toujours un conflit dans ce cas ?
