Le support de la version 1.4 de Prestashop a été ajouté. Si vous aviez la version 2.0 BETA 1 RC1 du module d’installé, il n’est pas nécessaire de procéder à une désinstallation/réinstallation, un simple remplacement des fichiers est suffisant (cela reste cependant nécessaire à toute migration 1.x vers 2.x) vous conserverez ainsi vos options de configuration.
Have fun 🙂
Changelog:
- INTERNAL/COMPAT: tpl/tgg_atos-front-payment-redirect.tpl corrigé pour compatibilité PS 1.4
- INTERNAL/COMPAT/COSMETIC: associe le module à la catégorie payments_gateways si PS >= 1.4
Télécharger :
Deux jours que la version compatible est sortie, et encore aucun remerciement ?
Diantre, il faut combler cette grosse lacune 😉
Grand merci pour ton travail !!
Je m’en vais de ce pas tester cette mise à jour.
Merci encore !
bof, si tu n’es pas en PS 1.4 la mise à jour du module ne t’apportera pas grand chose, à part la mise à jour de la documentation…
Mais merci 😉
Je pense sortir une RC3 avant la release finale 2.0, pour la prise en charge du paiement différé en une fois ainsi qu’une option supplémentaire de configuration « Montant minimum » pour ne pas proposer cette méthode de paiement lorsque les commandes sont inférieures à ce montant. Deux améliorations pas trop grosses qui me semblent valoir l’effort de les caser avant la 2.0 finale. Mais sinon, à moins que quelqu’un débusque un bug, les versions 2.0 RC1 (si PS < 1.4) et RC2 sont tout à fait valables pour une mise en production. Je recommande d'ailleurs l'installation d'une de ces versions plutôt que la 1.0 stable pour toute nouvelle installation dans l'optique de pouvoir mettre à jour plus facilement ensuite.
Si je persiste, c’est bien sur un P 1.4 que j’évolue. En fait il s’agit d’un nouveau projet et j’appréhendais le fait que la version ne soit pas pleinement compatible. Cependant, afin que cela « fonctionne » en attendant ta mise à niveau, j’avais suivi les recommandations figurant dans un précédent article (forcer le Smarty2 entre autre).
Bon, mais malheureusement, je me retrouve avec une erreur :
L’exécutable request a retourné une erreur.
(127): sh: /home/mysite/public_html/modules/tgg_atos/bin/request: No such file or directory
Bien sûr, l’arborescence est bonne…
Je ne pense pas que ce soit un pb de droits d’accès, mon admin système m’a paramétré ça au poil. Je continue à investiguer, mais si t’as un premier élément de réponse, je suis bien entendu preneur 😉
Tiens, je me demande si ce ne serait pas un pb avec la fonction exec(). Je vais voir ça avec l’admin sys.
Je ne pense pas que cela puisse venir de la fonction exec() : si elle ne s’était pas exécutée le shell n’aurait pas pu te retourner une erreur 😛
Passe le module en mode debug pour récupérer la commande complète, connecte toi en ssh sur la bécane et lance la commande sous le même user que celui qu’usurpe exec() pour vérifier si ses droits sont suffisants.
C’est chouette ça de pouvoir récupérer la commande complète !
J’ai un user ssh spécial qui ne permet que la lecture (mon admin sys aime bien blinder son serveur ;-). J’ai tout de même tenté et j’ai la même erreur que rapportée par le module :
-bash: /home/mysite/public_html/modules/tgg_atos/bin/request: Aucun fichier ou répertoire de ce type
Je vais voir ce qu’il en dit et te tiens au courant
🙂 Pour bien développer, toujours prévoir un bon système de débug ! On récupère toujours rapidement le temps que l’on y a passé 😉
Mais est-tu bien certain que l’adresse du fichier est bonne ?
Que donnent ces commandes :
> cd /home/mysite/public_html/modules/tgg_atos/
> ls -la bin
> bin/request
?
Sur certains serveurs l’exécution de binaires depuis php n’est permise que dans certains dossiers (souvant nommés « cgi-bin »)
user@web3:/home/mysite/public_html/modules/tgg_atos$ ls -la bin
total 532
drwxr-x— 2 www www 4096 mar 11 18:30 .
drwxr-xr-x 11 www www 4096 mar 11 18:30 ..
-rw-r–r– 1 www www 59 mar 9 22:46 .htaccess
-rwxr-x— 1 www www 0 mar 9 22:46 index.php
-rwxr-x— 1 www www 117257 mar 9 22:46 request
-rwxr-x— 1 www www 140370 mar 9 22:46 request.exe
-rwxr-x— 1 www www 113737 mar 9 22:46 response
-rwxr-x— 1 www www 136786 mar 9 22:46 response.exe
user@web3:/home/mysite/public_html/modules/tgg_atos$ bin/request
-bash: bin/request: Aucun fichier ou répertoire de ce type
Ce doit être ce que tu indiques : l’exécution ne veut pas se faire car binaires placés au mauvais endroit. Je vais voir à déplacer ce répertoire dans une arborescence qui l’autoriserait.
Non le listing prouve le contraire, je pense plus à un problème de restriction/permission. Cela dit, je vois que tu utilises bash, moi sh, je ne connais pas les différences subtiles entre les deux donc j’ai peur de t’induire en erreur.
Ton admin système devrait pouvoir te régler ça en moins de deux si tu lui transmets tous ces éléments.
# file request
request: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped
Le problème vient de ton binaire compilé 32bits hébergé sur une machine 64bits.
2 solutions :
– soit tu files les sources de ton binaire pour pouvoir les compiler sur la machine (meilleure méthode)
– soit il faut installer ia32-libs
Est ce que tu fournis les sources ?
Bonjour Damien,
D’abord un grand merci pour votre module, qui est des module Atos que j’ai pu tester le plus complet.
C’est une excellente idée que d’envisager un paiement différé, et un montant minimum.
Pour ma part pour que ce module soit complet il ne manque que lorsque le paiement en 2 ou 3 fois est activé la possibilité pour nos boutique de pouvoir rajouter des frais de transactions (soit en pourcentage soit en montant) comme le font les plus grand sites.
Il faut savoir que les transactions bancaires ne sont pas gratuites, et que souvent lorsque les produits sont vendu avec une marge très mince, voire inexistante scinder un paiement peut revenir a une vente à perte.
avez vous envisager de prevoir une option 2 ou 3 fois avec frais ?
Oui je l’ai effectivement envisagé, malheureusement les dons pour le module sont très loin de couvrir le coût de maintient du serveur d’hébergement et qui sert aussi à effectuer les divers test, débuggages, recettes du module avant diffusion, et je ne parle même pas des heures que j’y passe…
Cette modification ne sera probablement pas créée bénévolement, en tout cas pas par moi, car :
– il ne s’agit plus là d’une fonctionnalité de base, nécessaire pour commencer une activité e-Commerce, mais d’une fonctionnalité avancée
– c’est une modification lourde, car en ce cas, légalement, il faut pouvoir faire revalider le panier complet avec les frais supplémentaires dus à la méthode de paiement (cela dit je me trompe peut-être, je ne suis pas expert en ce domaine, mais je n’ai pas les moyens de payer un avocat pour qu’il réponde à cette question…)
– le manque vient plutôt ici de Prestashop qui ne prévoit pas que les frais puissent varier selon les méthodes de paiement, je trouve qu’il serait dommage d’implémenter cela au niveau du module alors qu’il s’agit d’une réalité générique à tous les modules de paiement. Par exemple vous pourriez aussi décider de majorer les paiement par virement bancaire ou chèques car le traitement de ces transactions par les employés de la société a un coût supérieur à une transaction totalement automatique, et puis il y a aussi Paypal qui prend des marges plus hautes que la plupart des autres systèmes mais offre un certain confort aux utilisateurs de cette solution, on devrait pouvoir répercuter cette marge sur le paiement…
Si Prestashop évoluait en ce sens avec une API solidement construite pour cela, je me ferai un plaisir de « mettre en règle » le module selon cette nouvelle logique.
En attendant, trois possibilités :
– payer un prestataire pour modifier à la fois votre boutique et votre instance du module. (ou le faire vous même si vous avez les compétences)
– payer cette modification du module (devis effectué sur présentation d’un story-board détaillé du mode de fonctionnement voulu, à la fois frontal et coté administration), sachant que toute modification payée du module est ensuite répercuté sur la version suivante si cela est d’utilité publique et ne perturbe pas les autres modes de fonctionnement du module, comme cela le fut pour l’ajout d’un ID minimal de transaction permettant de faire tourner plusieurs boutiques sur un seul ID marchand qui a été financé par http://www.01primalarme.fr/, je vous conseille de vous regrouper à plusieurs pour payer le développement car je pense que vous n’êtes pas le seul à pouvoir profiter de cette évolution du module.
– chercher un développeur bénévole pour soit améliorer Prestashop pour permettre des frais variables par méthode de paiement, soit améliorer mon module pour implémenter une fonction similaire plus localisée, si le code est de qualité et que le développeur le désire, la fonctionnalité sera ajoutée à la version publique du module.
Désolé, je me doute que ce n’est pas la réponse que tu attendais, mais tu comprendras aisément que tout comme toi je dois gagner ma vie et que le temps dont je dispose n’est pas extensible.
Salut TgG
navré de prendre contact ici mais je viens de mettre en place du module v2 rc2 et j’ai toujours ce message lors de la validation mode de règlement par cb : « Le paiement par carte est indisponible jusqu’à demain, nous vous prions d’accepter nos excuses pour cet inconvénient. »
C’est bien la première fois que j’ai ce message tu as une idée ?
Merci en tout cas pour tout, dès que possible je ne manquerai de faire valider un don par mon boss 😉
Salut TgG : navré pour ma question de ‘noob’ j’ai bien que ce message était déjà maintes fois traité… Sorry.
Par contre j’ai une erreur 404 lorsque le client souhaite annulé et clic sur le bouton annulation – retour boutique et lorsque la transaction est ok lorsque que le client client sur le bouton retour boutique. Je n’ai bien sûr aucune trace des commandes sur le BO.
J’ai modif mon htaccess avec ta soluce (peu propre à ton gout ;))RewriteCond %{REQUEST_URI} !^.*/tgg_atos/.*$ mais rien.
Peux-tu me donner une URL pour que je vois le problème par moi-même ? (il me manques énormément d’informations pour te répondre)
Si tu veux m’envoyer cela en privé, utilise le système de messages privés du forum Prestashop.
La modification du .htaccess dont tu parles n’est plus nécessaire depuis la version 2.0 Bêta 1 du module puisque vous pouvez configurer des domaines et protocoles canoniques justement pour éviter les redirections « barbares » à coup de mod_rewrite et les problèmes que posaient le dispatch du front et de l’administration sur deux domaines différents avec les versions antérieures.
Bonjour,
Merci pour ce module très bien réalisé.
J’espère que mes dons vont t’aider à prendre en charge de nouveaux développements ainsi que l’hébergement.
Oui, merci beaucoup, ils furent d’une grande utilité autant d’un point de vu financier que pour le maintient de la motivation à maintenir ce module à jour et exempt de bugs.
Il est cependant dommage que la seule agence web à faire ce pas soit une agence suffisamment sérieuse pour avoir pu se passer de requêtes de support, lorsque d’autres n’hésites pas à me contacter pour des questions prouvant qu’ils n’ont même pas la décence de lire la documentation Atos et/ou du module, et généralement montrant que leur niveau technique est bien trop insuffisant pour installer un système aussi sensible, ou même pour être simplement un prestataire de confiance pour le développement/maintenance d’un site eCommerce.
Je vous remercie pour vos dons, mais vous salue avant tout pour votre sérieux dont peu font preuve dans les mêmes conditions.
Salut Damien
Un grand merci, je suis maintenant passé systempay (ex-cyberplus) / payzen et j’avais oublié tous les soucis SIPS/ATOS, sauf que pour donner un coup de main j’ai du replonger dans les difficultés 🙁
J’ai trouvé par hasard le lien vers ton site et j’ai installé ta version 2.0.b2-RC2 (je n’ai pas trouvé s’il y avait une plus récente) et avec un coup de tar hop tout fonctionne du premier coup en test un import du certif de prod et hop cela fonctionne du premier coup.
Et une super doc qui m’a permis de régler le pb des 54 caractères
Le seul truc c’est que je n’ai pas bien compris où on téléchargeait les version 😉
Si tu as un jour besoin d’un coup de main pour payzen/systempay n’hésite pas
Laurent
Bonjour,
le site n’a volontairement pas de navigation évidente pour télécharger les versions du module car les solutions ATOS doivent être manipulées par des techniciens compétents, sérieux et impliqués et malheureusement mon module n’échappe pas à cette règle. Pour télécharger la dernière version il faut tout simplement cliquer sur la catégorie correspondant au module dans le menu de droite pour voir le différentes versions disponibles pour se rendre sur l’article correspondant à la version voulue. Même en l’état du site il y a déjà beaucoup trop de personnes sans aucun sérieux qui téléchargent le module et font bêtises sur bêtises par manque d’implication.