Produits Entr'ouvert » Combo

Première relecture...

Dans le hourly, on ne ferait pas self.poll_transaction_status() en premier ? Histoire de notifier aussitôt les paiements réussis à cette occasion.

• gérer un -v0 pour les print (dans l'idée que ça devienne un cron, cf ci-dessous)
• une typo "--all-baskends" dans poll-backend.py, on gère pas des baskets ici monsieur
• et en mode pénible, je dirais aussi que ça manque de test

Mais plus globalement je me demande si le "hourly" est assez fréquent et je me dis que cette commande "poll-backends" pourrait être renommée et devenir une commande à lancer par un cron général du système de paiement, lancé toutes les 10 minutes et remplaçant complétement le hourly

Voilà en fait toute ma question c'est surtout "est-ce que hourly c'est assez fréquent", j'ai l'impression que non, attendre jusqu'à une heure pour voir finalement son paiement accepté, c'est un peu relou pour un usager, je trouve.

(J'ai relu le reste et pour l'instant pas vu de truc bizarre, hormis les notations genre « payment_backend.backend » mais dans eopayment/lingo on n'est plus à ça près !)

Thomas Noël a écrit :

Mais plus globalement je me demande si le "hourly" est assez fréquent et je me dis que cette commande "poll-backends" pourrait être renommée et devenir une commande à lancer par un cron général du système de paiement, lancé toutes les 10 minutes et remplaçant complètement le hourly

T'as raté le dernier patch où le poll_backend est fait pour les transactions en cours de l'utilisateur connecté à chaque affichage de la page: mon idée c'est que dans le cas courant, il y a une seule transaction ouverte qui a réussi et dès qu'on revient sur la page des factures (à supposer qu'on ait pas déjà reçu la notification synchrone), ce sera rafraîchi et basta. En fait le poll_backend() en cron n'est là que pour rattraper les cas normalement rares où la personne n'est pas revenu sur le portail normalement. C'est aussi le commit qui contient les tests les plus intéressant je pense (mais si tu as des idées de test que tu aimerais voir dis, de mon coté je vais faire le tour de la couverture du code dans jenkins).

Je réponds plus tard sur le reste.

Benjamin Dauvergne a écrit :

T'as raté le dernier patch où le poll_backend est fait pour les transactions en cours de l'utilisateur connecté à chaque affichage de la page: mon idée c'est que dans le cas courant, il y a une seule transaction ouverte qui a réussi et dès qu'on revient sur la page des factures

Oui j'ai vu ce rafraîchissement dans une cellule et c'est très cool. Mais j'imagine aussi les cas de paiement sans cette cellule (paiement "sans panier"). Mais surtout je voulais juste dire que "hourly" ça me semble pas une fréquence faible pour faire ce genre de check, que je trouve mieux que les choses s'écoulent plus "au fil de l'eau" et donc avoir une fréquence plus élevée me semblait intéressant. Mais ça sera plutôt l'objet d'un autre ticket, évitons de surcharger ici.

Pour mon « ça manque de test » c'est juste que j'avais été voir la couverture, et poll-backends.py est tout rouge roooh.

Thomas Noël a écrit :

Oui j'ai vu ce rafraîchissement dans une cellule et c'est très cool. Mais j'imagine aussi les cas de paiement sans cette cellule (paiement "sans panier"). Mais surtout je voulais juste dire que "hourly" ça me semble pas une fréquence faible pour faire ce genre de check, que je trouve mieux que les choses s'écoulent plus "au fil de l'eau" et donc avoir une fréquence plus élevée me semblait intéressant. Mais ça sera plutôt l'objet d'un autre ticket, évitons de surcharger ici.

C'est géré aussi, tous les paiements passant par les méthodes de PayMixin (avec ou sans panier), le paiement est bloqué si la transaction est en cours de paiement jusqu'à ce que le statut change de en cours à expiré ou payé (ça prend 20 minutes avec PayFiP de faire le distingo, ou moins si la transaction a été payée). On pourrait en faire le comportement¹ par défaut même quand on ne dispose pas de polling, mais ce sera pour un autre ticket.

Pour mon « ça manque de test » c'est juste que j'avais été voir la couverture, et poll-backends.py est tout rouge roooh.

J'ai viré toute utilisation de hourly, maintenant ça passe uniquement par la commande qui est lancée toutes les 10 minutes par le cron, par ailleurs je l'ai modifié pour qu'elle puisse s'exécuter de façon concurrente sans problème: je verrouille la transaction lors d'un poll pour un cellule/paiement et pour la commande je ne poll que les transactions verrouillables (deux lancements concurrents vont poller toutes les transactions en se les répartissant automatiquement).

La branche est à jour.

¹ dès qu'on commence un paiement on bloque pendant 20 minutes le paiement sur le/les remote_item/item sélectionnés, sur le site de ma cantine scolaire (Sogeres) ça marche comme ça et je l'ai vu chez Abelium aussi avec PayFiP regie.