Doc de la résiliation de prélèvement auto

rastapopougros commented 4 years ago

Je ne trouve pas de doc pour la fonction de "résiliation" des prélèvements auto dans Bank.

Je n'arrive vraiment pas à comprendre cette suite de fonctions qui… ne fait en gros rien du tout, et après avoir le commentaire code de la fonction appelée par la fonction appelée par la fonction… on nous dit qu'il faut l'implémenter soi-même en fait, mais je pige toujours pas pourquoi.

Ya une action bank_resilier_abo qui appelle une fonction abos/resilier qui appelle un pipeline bank_abos_resilier et… rien. Ya sûrement une raison logique que ça doit marcher dans tel sens et que j'ai pas pigé :smile:

Dans mon idée :

soit on a sa propre action/bouton de désabonnement (par ex le plugin Abonnements aurait le sien) et dedans, SI on détecte que l'abonnement est lié à un UID bancaire, on appelle une fonction d'API de Bank pour résilier aussi le prélèvement du prestataire
soit le plugin Bank fournit une action de résiliation qui fait réellement quelque chose (on doit lui fournir un UID en arg donc pourquoi ça fait pas le boulot jusqu'au bout ?) et dedans ça appelle un pipeline trigger qui dit que c'est bien fait, et du coup d'autres plugins (Abonnements) résilie un truc SPIP lié s'il y en a un

rastapopougros commented 4 years ago

Question subsidiaire : si jamais on veut appeler abos_resilier_notify_bank soi-même, ça attend juste l'uid seul (le abo_uid qu'on garde en mémoire dans bank_uid de Commandes), ou avec "uid:" devant ? Car dans l'action ça ajoute bizarrement "uid:" en préfixe…

En gros si je fais

include_spip('abos/resilier');
abos_resilier_notify_bank($bank_uid);

bam ça va résilier chez le presta bancaire, si l'uid est ok ?

Cerdic commented 4 years ago

Par défaut la fonction du plugin bank ne fait rien, car résilier le prélèvement automatique sans avoir fait l'action client qui va avec ça semble une très mauvaise idée.

Autrement dit, par défaut on préfère ne rien toucher que de résilier des prélèvement automatiques alors que par ailleurs le client continuera à recevoir sa prestation (vu que la fonction n'aura pas été branchée).

Donc c'est à l'intégrateur de mettre en place les actions clients (plugin abonnement ou tout autre action réelle visant à stopper la prestation en face du paiement automatique), et ensuite du coup à si tout est bien en place on peut appeler la fonction qui résilie chez le prestataire bancaire.

Il est certain que la construction de cette partie avec empilement d'une action surchargeable et d'un pipeline n'est pas des plus limpides et souffre en peu de l'historique du développement du plugin et du fait que j'ai fait en sorte de ne rien casser sur les mises à jour.

Mais AUSSI : d'expérience il est très désagréable de se retrouver avec des résiliations de paiement à tort, avec le service qui continue d'être délivré. Il est donc bien préférable que par défaut ça ne fasse rien...

Cerdic commented 4 years ago

En gros si je fais
include_spip('abos/resilier');
abos_resilier_notify_bank($bank_uid);
bam ça va résilier chez le presta bancaire, si l'uid est ok ?

Oui c'est bien ça, et en passant l'abo_uid tel quel

rastapopougros commented 4 years ago

Super, merci. C'est donc bien ce que j'avais fait en attendant, en choisissant l'option 1 : le plugin Abo a sa propre action SPIP, et dedans si on trouve un UID lié, on appelle la résiliation (et bien seulement après avoir désactivé la prestation dans le site) : https://git.spip.net/spip-contrib-extensions/abonnements/src/branch/master/action/resilier_abonnement.php#L41

nursit / bank

Doc de la résiliation de prélèvement auto #47