Mécanisme pour le renouvellement d'une souscription

  • Posts: 238
  • Thank you received: 4
1 year 6 months ago #286385

-- HikaShop version -- : 3.2.2
-- HikaSerial version -- : 2.0.2
-- Joomla version -- : 3.8.3
-- PHP version -- : 5.6.33

Bonjour,

Nous utilisons HikaShop et Hikaserial pour vendre des clefs de licences d'un logiciel. Nous avons écrit un générateur pour HikaSerial qui interroge l'API de LIMElm pour générer des clefs que les clients récupèrent une fois qu'ils ont payé. Tout ceci fonctionne très bien. Merci Hika !

Ces achats concernent un abonnement pour un an. Actuellement, passée une année, leur logiciel n'est plus actif et nos clients doivent acheter une nouvelle licence.

Nous souhaitons mettre en place un mécanisme de renouvellement avec la possibilité d'inciter les clients à le faire avant le terme de leur abonnement. Nous avons acheté HikaSubscription qui semble bien adapté à cet objectif.

Que se passe-t-il quand le client reçoit le mail l'incitant à renouveler son abonnement avant son terme ? Est-il renvoyé vers l'achat d'un produit spécifique ? Du même produit avec une variante "renouvellement" ? Faut-il associer le "plan" de la souscription au produit de l'achat initial ou au produit correspondant au renouvellement ? Comment faire pour que le client qui renouvelle avant le terme de son abonnement bénéficie d'un prix remisé par rapport à ce qu'il devra payer s'il laisse passer la date (il faut qu'il achète une nouvelle clef) ? Comment faire pour que les clients qui n'ont pas d'abonnement en cours ne puisse pas choisir d'acheter le renouvellement (même si l'achat échoue in fine, ce serait mieux qu'ils ne puissent pas du tout y avoir accès) ?

Par ailleurs, au moment où le client paye son renouvellement, je dois déclencher une mise à jour de la date correspondant à la clef générée par HikaSerial lors de l'achat initial sur les serveurs de LIMELm. Etant donné que j'ai un plugin générateur spécifique qui interroge l'API LIMElm pour récupérer cette clef, comment je fais pour différencier l'appel initial (génération d'une clef qui fonctionne actuellement) de l'appel pour renouvellement (passage de la clef en paramètre et modification de la date d'expiration). Existe-il un "hook" spécifique pour accrocher ma fonction ? Genre onRenewSub.... ?

Comment fait le client ? Il consulte ses "serials" et clique sur un bouton "renouveler" qui l'envoie vers un produit ? après s'être connecté ? via un lien de connexion automatique dans le mail ? Il paye et si ok cela déclenche mon trigger pour que je mette à jour sa clef ? Je n'ai pas trouvé de réponses dans la doc disponible. Sauf erreur.

Enfin, nous avons plusieurs centaines de clients ayant acheté un abonnement. Comment fait-on pour "raccrocher" ces achats existants au plan mis en place de façon à ce qu'ils reçoivent un mail au bon moment et qu'ils puissent renouveler via le nouveau mécanisme ?

Merci d'éclairer ma lanterne ! :-).

Laurent

Please Log in or Create an account to join the conversation.

  • Posts: 23611
  • Thank you received: 3666
  • MODERATOR
1 year 6 months ago #286401

Bonjour,

CF : www.hikashop.com/support/documentation/4...derstanding_workflow

Afterwards, your customer will be able to renew, automatically or not, his subscription.
That action can be done via recurring (when using a recurring payment plugin and a specific relation between the product and the plan) ; but also manually by letting the customer buy specific renewal products.
If you want that the renewal have a different price or different duration, you would have to use several products for that task (usage of variants is also possible).

Since the renewal of a subscription must have the information of which subscription will be renew ; the customers can just renew their subscription via the specific interface in the customer panel.


Comme expliqué dans la documentation du tutorial, le renouvellement se passe uniquement dans la partie "souscription" accessible via le panneau de l'utilisateur en front-end.
Pour ne pas afficher un renouvellement en front-end il suffit de ne pas le mettre dans une catégorie visible.

Il n'y a aujourd'hui pas d'option permettant de bloquer la création de commande lorsqu'il y a un produit de type "renew" ; mais cela fait parti de notre TODO list avec l'intégration du renewal directement depuis les fiches produits et l'utilisations de paniers classiques.

Au niveau des triggers, il y a "onAfterSubscriptionCreate" et "onAfterSubscriptionUpdate" qui peuvent être utilisés.
Le système ne fait aujourd'hui pas la différence entre une modification en backend (qui peut rajouter de la durée) et une mise à jour via un renouvellement.
Mais via le trigger vous pouvez voir que la date de fin est modifiée (via le sous objet "old" qui contient les valeurs avant mise à jour).

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 238
  • Thank you received: 4
1 year 6 months ago #286430

Merci pour ces éléments de réponse. Je vais faire des essais et reviendrez éventuellement sur le forum si j'ai des questions plus précises.
Est que le trigger de renouvellement invoque la classe définie dans le plugin "Generator Serial" que nous avons créé pour les clefs ou est-ce qu'il faut créer un plugin spécifique ?
Et pour le dernier point (rattachement des clients existants) ?

Last edit: 1 year 6 months ago by laurent.

Please Log in or Create an account to join the conversation.

  • Posts: 23611
  • Thank you received: 3666
  • MODERATOR
1 year 6 months ago #286460

Bonjour,

Actuellement il n'y a pas de générateur pour les souscriptions dans HikaSerial.
Donc si vous souhaitez avoir la main sur la création du "subscription_data" ; vous devez utiliser le trigger "onBeforeSubscriptionCreate".
Votre plugin de génération est un plugin de type "hikaserial", il peut donc implémenter ce trigger pour modifier la valeur du subscription_data.

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 238
  • Thank you received: 4
1 year 6 months ago #286538

J'avance....
Tel que livré, le plugin subscription génère une "subscription data" qui est soumise à une validité. Si j'associe le produit à un hikaserial, je n'ai pas de liaison entre les deux. Le hikaserial me fournit un "numéro" et le hikasub un autre qui sont relatifs à la même commande. Ce n'est pas très confortable pour le client. Quand ils consulte ses serials, rien ne l'informe sur la validité restante et la possibilité de renouveler. Et quand il consulte ses abonnements, rien ne lui rappelle son serial. Le numéro affiché n'a rien à voir. Il faut qu'il passe par le numéro de la commande pour faire le rapprochement "à la main" (cf. les copies écran).

Dans notre cas, acheter un produit revient à récupérer une clef. Clef qui est fournie par l'appel d'une API externe. Cette clef ayant une durée de vie limitée nous sommes très intéressés par le mécanisme de renouvellement de hikaSub. Donc, finalement, ne suffit-il pas d'utiliser simplement hikaSub et de générer la "vraie clef" comme étant la "subscription data" ? Et on se passe d'associer le produit à un serial puisqu'on n'utilise pas les mécanismes utilisation/consommation. Un achat = une clef spécifique pour une période donnée.Qu'est-ce qu'on perd ?

Où se trouve l'appel du onBeforeSubscriptionCreate ? quels sont les paramètres ?

Merci,

Attachments:
Last edit: 1 year 6 months ago by laurent.

Please Log in or Create an account to join the conversation.

  • Posts: 23611
  • Thank you received: 3666
  • MODERATOR
1 year 6 months ago #286546

Bonjour,

1 - L'appel du trigger se trouve (tout logiquement) dans la class "subscription" d'HikaSerial Subscription.
Et comme tous les trigger de type "onBefore...Create" de nos composants, il y a deux paramètre, le premier avec l'objet en question et le deuxième un "$do" pour pouvoir empêcher, si besoin, le déroulement de l'action de création.

CF :
www.hikashop.com/support/documentation/6...#onBeforeOrderCreate
www.hikashop.com/support/documentation/6...nBeforeProductCreate
( etc )

2 - Le système de serial est une chose et les souscriptions une autre.
HikaSerial Subscription a été créé à partir d'HikaSerial car justement le système de serial apporte d’excellentes bases pour un système de souscription et permet de combler ce qui n'était pas possible avec les serials et leur "vie".
Je vais vous dire que bien évidement vous ne devez pas utiliser les deux système en même temps et qu'une souscription est un serial avec une "vie" différente ; elle ne s'utilise pas, elle est active ou non en fonction des paiements du client.

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 238
  • Thank you received: 4
1 year 6 months ago #286684

Bonjour,

Merci pour le point 1. Ce qui me manquait c'était l'emplacement de la classe (administrator/components/com_hikaserial/classes/subscription.php). Je cherchais cela dans un répertoire "model" sous components (front).... :-)

Ok pour le point 2. Que des subs. donc. Du coup, n'est-il pas préférable d'écrire un plugin spécifique au même niveau que Acymailing Subscriber ou GroupSubscriber dans "plan actions" du plan ? Sinon le plugin "serial" ne sera pas déclenché si mon produit n'a qu'une "sub" et pas de serial ? Il risque de ne pas trouver les functions correspondant aux triggers ?

Autre point. Lorsque la commande est créée et pas encore confirmée, la souscription a le statut "clôturée". Ce n'est pas gênant dans le cas d'un paiement par CB car le client voit tout de suite que sa souscription est "active". Mais dans le cas d'un paiement par virement bancaire par exemple, le client qui consulte ses souscriptions dans son espace la voit mentionnée "clôturée" alors qu'elle n'a jamais été "ouverte". Il faudrait plutôt qu'elle soit indiquée commet "en attente" ou "créée". D'un point de vue logique, c'est vrai que si elle n'est ni "active", ni "expirée", elle est "clôturée". Mais d'un point de vue client, ce serait plus normal d'avoir un état de "non activation" avant la première activation/expiration/annulation...

Merci.

Please Log in or Create an account to join the conversation.

  • Posts: 23611
  • Thank you received: 3666
  • MODERATOR
1 year 6 months ago #286685

Bonjour,

Vous pouvez créer un plugin "subscriber" si jamais vous avez des besoins de stocker des paramètres spécifiques au niveau des plans et pouvoir être appelé lorsqu'une souscription est activée, passe expirée ou est clôturée.
N'ayant aucune idée de ce que vous souhaitez faire, je ne peux pas vous aiguiller beaucoup plus.

Un plugin de la famille "hikaserial" sera chargé quand HikaSerial est chargé, donc vous avez accès à tous les triggers.
La variable "type" du plugin permet simplement d'accéder plus facilement à certaines fonctions du helper et changer l'affichage dans le listing du backend.

Il y a trois status possibles pour une souscription : activée, expirée et clôturée.
Oui, HikaSubscription va créer une souscription dès la création de la commande et comme vous l'avez souligné puisque la souscription n'est ni active, ni expirée ; elle est tout logiquement clôturée.
J'aurais souhaité ne pas avoir à créer la souscription en amont mais cela pose malheureusement des soucis de fonctionnement.

Je crains que rajouter un nouveau status soit superflus et potentiellement contre productif.
Par contre, vous pouvez très bien renommer "SERIAL_CLOSED" en "inactive" afin de mieux mettre en exergue le fait qu'elle ne soit pas (encore) active.

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 238
  • Thank you received: 4
1 year 5 months ago #289998

Bonjour,

Je reprends ce sujet après un long moment. Merci pour votre dernière réponse.

Je suis en train de mettre au point notre propre plugin "subscriber". Il doit aller chercher une clef api lors de l'activation et synchroniser la fin de cette clef avec la fin de la souscription. Si renouvellement, il doit prolonger cette même clef via l'API.

1/ petit bug qui "m'énervait" car mon plugin ne voulait pas être du bon type : ligne 119 du fichier administrator/components/com_hikaserial/views/plugins/tmpl/listing.php (le elseif qui est sur le type "subscriber"), la deuxième variable du "substr" devrait être -10 et non pas -8 (copier-coller du précédent).

2/ j'ai créé un champ "input" dans la configuration de façon à ce qu'il apparaisse dans les actions du pack (numéro de version du logiciel souscrit dans notre cas). Mais la valeur n'était jamais ré-affichée à l'édition du plan. J'ai corrigé le fichier administrator/components/com_hikaserial/views/plan/view.html.php autour de la ligne 280 :

switch ($value[1]) {
				case 'input':
				case 'int':
				case 'float':
// vide ....		$v = @$this->element->$paramsType->$key;
					$v = @$this->plan->pack_params->{$section}[$key];
					if(empty($v) && !empty($value[2]))
						$v = $value[2];
					if($value[1] == 'int') $v = (int)$v;
					if($value[1] == 'float') $v = (float)hikaserial::toFloat($v);

Je continue à explorer :-) ....

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 23611
  • Thank you received: 3666
  • MODERATOR
1 year 5 months ago #290040

Bonjour,

J'ai corrigé les deux points de mon côté, les patchs seront inclus dans la prochaine release.

Merci de vos retours !

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 238
  • Thank you received: 4
1 year 4 months ago #290092

Bonjour,

Tests en cours. Les mécanismes généraux ont l'air de bien fonctionner. J'avais juste oublié d'activer le CRON. Peut-être à mettre en "gros" au début de la documentation ?... ;-)

Le réglage qui permet de déterminer si un client peut renouveler avant/après la date d'expiration et sur quel délai est fixé au niveau général. Il me semble que dans le cadre d'une évolution de votre produit, il faudrait le ramener au niveau de l'abonnement. Ou plus exactement, avoir ce réglage aussi au niveau de l'abonnement pour altérer le fonctionnement par défaut positionné au niveau général. Par exemple, nous commercialisons des licences logicielles et du support. Pour le premier, il est important que le client ne puisse pas renouveler avant la "fenêtre" choisie, proche de la date d'expiration. Et il peut tout à fait renouveller après la date d'expiration. Par contre, pour le support, il n'y a aucune raison de l'empêcher de renouveler quand il veut avant la date d'expiration mais on ne doit pas le laisser faire, une fois cette date passée. Ces deux abonnements ne devraient pas avoir le même comportement sur ce plan.

Quel est le rôle de la dernière ligne de la fonction onSubscriptionActivation du plugin groupsubscriber qui affecte vraisemblablement la valeur true/false à la variable "$ret" ? Cette variable ne semble pas accessible à cet endroit ? N'est ce pas plutôt :

return $this->updateGroups($user_cms_id, $check);

Dans certains plugins d'action, comme onBeforeSubscriptionCreate, on a les variables $sub et $do avec le $do permettant de bloquer la chaîne de traitement. Mais sur d'autres, comme onSubscriptionExpiration, on a $sub, $user et $status. quel est le rôle de cette variable ?

Les 3 déclencheurs onBeforeSubscriptionExpire, onSubscriptionExpiration et onAfterSubscriptionExpire sont déclenchés dans le même "mouvement" dans cet ordre ? Ou bien est-ce lié aux dates avant/après que l'on peut positionner ?

Merci.

Please Log in or Create an account to join the conversation.

  • Posts: 23611
  • Thank you received: 3666
  • MODERATOR
1 year 4 months ago #290152

Bonjour,

1 - Oui, il est tout à fait possible de faire évoluer HikaSubscription afin de gérer une surcharge des "dates" autorisées pour le renouvellement au niveau des plans.
Il s'agit d'un point que nous avons déjà dans la liste des idées mais nous attendons surtout d'avoir des retours utilisateurs afin de pouvoir organiser au mieux les tâches que nous allons implémenter en priorité.

2 - En fait il n'y a pas d'utilité à la variable $ret ; on récupère le résultat mais celui-ci n'est pas utilisé pour la gestion de l'échec.
Sachant que nous sommes dans un "after", il n'y a pas de "$do" puisqu'on ne va pas annuler une action déjà terminée.
Il n'y a pas non plus de besoin de faire de return puisque l'on souhaite que le code après soit exécuté.

3 - pour "onSubscriptionExpiration", la variable $status est le status du plan. Il est passé au cas ou un plugin change la donnée de l'objet. C'est une petite précaution.

4 - il n'y a pas de trigger "onBeforeSubscriptionExpire" ; il s'agit du trigger "onBeforeSubscriptionsExpire".
Ce trigger fournis un tableau de souscriptions et non un seul élément.
Son contexte est donc très différent puisqu'il est lié à la CRON.
Pour ce qui est de onSubscriptionExpiration ; ce trigger est relatif à un seul élément et il est relié au "save" d'une souscription ; se déroulant tout à la fin, après le onAfterSubscriptionUpdate et uniquement dans le cas ou une souscription vient d'être modifiée et sa modification la fait expirer.

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 238
  • Thank you received: 4
1 year 4 months ago #290201

Bonjour Jérôme,

Quelle patience ! :-)

Merci pour ces explications. Tout commence à bien s'articuler. Reste un dernier point (pour l'instant !), concernant les 4 rattachements produit-plan.

Pour le Create : c'est limpide. Le produit apparaît en front. Le client achète autant de souscriptions différentes qu'il indique de quantité.
Pour le Renew : limpide aussi. Le produit DOIT être caché sur le front. Il n'est sollicité que par le bouton "renouveler" qui apparaît dans la liste des souscriptions. Il est dédié au renouvellement.

Pour les deux autres... c'est moins clair. La doc dit

and can be use for renewal

. Je pensais donc que le produit disponible en front pour un premier achat de souscription serait aussi celui qui est sollicité au moment du renouvellement via le bouton adhoc dans la liste des souscriptions actives. Mais apparemment, il n'apparaît pas.

En dehors du mécanisme de paiement récurrent qui est encore autre chose, dans une procédure manuelle (pilotée par le client), ,je ne vois que 3 associations possibles produit-abonnement :
  • En création (boutique) avec les quantités qui s'appliquent aux nombre des souscriptions différentes
  • En création avec les quantités qui s'appliquent à la durée (x fois la durée de base) pour une seule souscription
  • En renouvellement (liste des souscriptions actives), souscription par souscription. Les durées de renouvellement étant gérées via les variantes.

Un cas d'usage que je ne vois pas encore ?

Merci.

Laurent

Please Log in or Create an account to join the conversation.

  • Posts: 23611
  • Thank you received: 3666
  • MODERATOR
1 year 4 months ago #290203

Bonjour,

La fonction "getSubscriptionsRenewals" de la classe "Subscription" cherche bien dans les produits ayant une relation "renew" ou "create_renew" mais il est vrai qu"il manque "renew_create".
Donc, je peux valider que les "Renewal or Creation" ne soient pas affichées dans la version courante (ce qui sera corrigé) mais les "Creation then Renewal" doivent l'être.

Pour le détails des différents mode, il y a une explication dans notre tutorial :
www.hikashop.com/support/documentation/4...iption-tutorial.html

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 238
  • Thank you received: 4
1 year 4 months ago #290230

Bonjour,

Ok. Bien reçu.
Ceci dit, dès que j'associe un produit à un abonnement pour autre chose que "create" ou "renew", c'est à dire soit "create_renew", soit "renew_create", il refuse d'associer un moyen de paiement au produit. Le panier n'est donc pas utilisable (paiement impossible) lors du premier achat de souscription. Nos moyens de paiements actifs sont le virement, la CB (AtosSips) et PayPal (non récurrent).

Laurent

Please Log in or Create an account to join the conversation.

  • Posts: 23611
  • Thank you received: 3666
  • MODERATOR
1 year 4 months ago #290256

Bonjour,

En effet, lorsque vous utilisez "create_renew" ou "renew_create" ; HikaSerial va calculer les données relatives au paiement récurrent.
Cela a pour effet de n'afficher que les plugins de paiement gérant la récurrence.

Il faudrait rajouter un élément dans HikaShop permettant à HikaSerial de fournir des informations de récurrence mais indiquer qu'il n'est pas obligatoire d'avoir un plugin le gérant (et donc que la récurrence ne soit pas ajoutée à la commande).

Ce que je peux vous proposer pour l'instant est de modifier la class "cart" d'HikaSerial en remplaçant

	public function checkPaymentOptions(&$paymentOptions, &$order) {
		if(empty($order->products) && empty($order->cart->full_products))
			return;
Par
	public function checkPaymentOptions(&$paymentOptions, &$order) {
		if(empty($order->products) && empty($order->cart->full_products))
			return;
		// Do nothing
		return;
Afin de ne pas faire ce calcul de données de récurrence.

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 238
  • Thank you received: 4
1 year 4 months ago #290529

Bonjour,

Tout est à peu près fonctionnel. Les premiers tests se passent bien.

J'aurais besoin d'un "coup de main" de plus :

On permet à nos clients qui ont acheté une clef (activation d'un logiciel qui tourne sur Windows/Mac) via le mécanisme "Serials" d'HikaSerial, de renouveler cette clef (la clef elle-même est fournie par une API externe). Ce renouvellement est en fait l'achat "normal" d'une souscription spécifique via un lien dans le listing "Serials" qui peuple un champ spécifique que je récupère à la création de la souscription. Ainsi, au lieu de générer une nouvelle clef on réutilise l'existante en calant sa fin de vie sur l'expiration de la souscription.

Ainsi les nouveaux clients n'achètent plus que des "souscriptions" et les anciens migrent doucement au fur et à mesure qu'ils "renouvellent" leur ancien "serial". A terme, ils pourront tous bénéficier des mécanismes de renouvellement et d'alertes propres aux souscriptions.

Dans le cas du renouvellement d'un ancien serial, j'aurais voulu changer le statut du serial (à "delete" par exemple) de façon à ce qu'il disparaisse du tableau de bord de l'utilisateur (listing des serials qu'il a achété).
Il faudrait que cela se passe au moment de l'activation de la souscription "onSubscriptionActivation" ou "onAfterSubscriptionUpdate". Dans le premier cas, j'ai bien un objet "user" mais il ne contient pas d'info sur ses serials.

Sachant que je connais le "serial->data" concerné (stocké dans la souscription), comment je peux le retrouver et changer son statut à l'intérieur d'un trigger "subscription" ? Récupérer l'objet "serial" et le mettre à jour ? Methode du genre updateSerialStatus ?

Merci.

Please Log in or Create an account to join the conversation.

  • Posts: 23611
  • Thank you received: 3666
  • MODERATOR
1 year 4 months ago #290546

Bonjour,

Si vous avez un object $serial ; le plus simple est de modifier le "serial_status" et d'appeler la function save de la class serial.
Vous pouvez aussi faire l'object "à la main"

$serial = new stdClass();
$serial->serial_id = (int)$serial_id;
$serial->serial_status = 'deleted';
$serialClass = hikaserial::get('class.serial');
$serialClass->save($serial);

Cordialement,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 238
  • Thank you received: 4
1 year 4 months ago #290573

Bonjour,

Parfait, merci. En m'inspirant de votre code et en jetant un oeil à la classe, je commence par chercher le serial basé sur sa donnée et je la "supprime".... Ci dessous le code pour le cas où cela peut intéresser un autre utilisateur :

$serialClass = hikaserial::get('class.serial');
$serial = $serialClass->find($key);
if (count($serial) != 1)	{
	$this->LimeLMsublog("Erreur : il y a plus qu'un serial avec ce numéro de clef !");					
} else {
	if(isset($serial[0]->serial_user_id) && $serial[0]->serial_user_id != $user->user_id) {
		$this->LimeLMsublog("Erreur : le serial trouvé ne correspond pas au user !");	
	} else {
		$serial[0]->serial_status = 'deleted';
		$op = $serialClass->save($serial[0]);			
		if ($op != $serial[0]->serial_id) {
			$this->LimeLMsublog("Erreur : la suppression de l'ancien Serial n'a probablement pas eu lieu !");							
		}
	}
}

Last edit: 1 year 4 months ago by laurent.

Please Log in or Create an account to join the conversation.

  • Posts: 238
  • Thank you received: 4
1 year 4 months ago #291220

Bonjour,

Les mécanismes semblent bien fonctionner.
Mais je n'arrive pas à récupérer le mail de l'utilisateur "onBeforeUpdate" lorsque l'utilisateur vient de s'enregistrer.
En effet, s'il passe commande en tant que nouveau client, l'objet "user" de Joomla n'est pas renseigné au moment du "onBeforeUpdate" où on détecte le passage de "closed" à "active" pour déclencher la génération d'une clef via notre API externe.

Peut-on récupérer un objet "$user" comme dans "onActivation" et sera-t-il renseigné (adresse email) dans le onBeforeUpdate qui fait passer la subscription de "close" à "active" quand le client enchaîne les opérations directement (enregistrement-->creation de la commande-->paiement) ?

Merci.

Laurent

Please Log in or Create an account to join the conversation.

Moderators: Obsidev
Time to create page: 0.092 seconds
Powered by Kunena Forum