Empecher un client de choisir une méthode de paiement, Les clients à risque ne peuvent payer contre facture Options

[smalto]

Bonjour à tous,

Dans mon shop les clients peuvent choisir comme moyen de paiement la carte de crédit, Paypal et contre Facture. Le mode de paiement contre facture est repris sur le mode existant tranfert.php qui permet comme tous les modules de limiter la présentation du module à certains clients sur un critère géographique.

Comme faire pour également limiter (ne pas montrer ce module) si le client est un client à risque (par exemple exclure le no client dans le module ou exclure un fichier dans lequel il y a les clients ou no clients)

Le plus simple serait peut-être de travailler sur la limitation à la zone géographique et faire quelque chose de pareil pour les client indésirables.

Le résultat final serait que si le client est un client à risque (déterminé par le fait qu'il a déjà eu des prob avec le shop) il soit obligé de payer par un autre moyen Carte de crédit ou Paypal.

Ne sachant pas vraiment programmer, mais seulement bidouiller quelqu'un pourrait-il m'aider ?

Merci et à bientôt.

smalto

[Gnidhal]

dans tous les modules tu trouveras cette ligne ou équivalent :

Code

      $this->enabled = ((MODULE_PAYMENT_XXXXXX_STATUS == 'True') ? true : false);

En codant en dur tu peux interdire la dispo d'un module à un client ou une liste de clients.
1/ ajouter en tête de fonction dans la ligne globals l'id du client en cours :
global $order;
devient alors :
global $order, $customer_id;
2/ créer une liste de client indésirables à partir de leur id que tu place dans un array
$refus_client_liste = array('13',26','203','567');
chaque id de client qui n'a pas accès à ce module est donc dans ce tableau : les customers_id = à 13, 26, 203 ou 567
et donc dans le code en dessous de la ligne où il y a $this->enabled tu ajoute une ligne de ce genre

Code

      if (in_array($customer_id,$refus_client_liste)) $this->enabled =  false;

Ce qui correspond à si le client est dans la liste, le module est désactivé.

ça c'est le principe.
Après pour bien faire il conviendrait de faire en sorte que la liste des clients interdits soit modifiable depuis la section clients dans l'admin.
Il faudrait donc ajouter un champ à la table customers modifiable depuis le script admin/customers.php qui marquerait par un 1 ou un 0 si le client a droit à ce module.
Une requête dans le module permettrait alors de créer dynamiquement le tableau $refus_client_liste.
Mais si tu ne sais pas coder, il va falloir passer la main ou te mettre au code

[smalto]

Merci Gnidhal pour cette réponse rapide.
Effectivement je ne suis pas codeur mais bidouilleur en php. Je comprend la logique mais ne saurais pas le mettre en php.
Peut-être que d'autres personnes trouvent cette possibilité d'empêcher un client d'utiliser un moyen de paiement intéressant et pourraient m'aider dans le code.
De mon côté je peux aider quiconque à traduire en DE, EN, FR.....

Bonne soirée à tous,

smalto

[smalto]

Hello Gnidhal,

J'ai décidé de me lancer au risque de perdre tout le weekend et contre toute attente cela marche nickel......... C'est vraiment super!

Dans le array puis-je mettre aussi des noms ou emails ?

Si tu as encore de la patience aurrais-tu également une marche à suivre pour la suite (implémentation dans le fichier customers.php et ajount de champs dans la table customers pour indiquer depuis l'admin si le client doit être interdit de methode de paiement).

Bonne soirée,

smalto

[Gnidhal]

Salut Smalto,
Bien ! tu vois ça n'était pas si compliqué
Non dans ton array, tu ne peux mettre que les id des clients bannis.

Mais à ce niveau tu n'as pas besoin d'autre chose car on est dans une condition qui saura reconnaitre le client juste par son id.
Comme tu as l'air volontaire et débrouillard, je te guide un peu pour l'étape suivante.
En effet l'étape suivante est plus délicate :
il faut ajouter un champ dans la table customers (là c'est pas dur, avec phpmyadmin tu fais ça en direct)

Code

ALTER TABLE `customers` ADD `customers_option_flag` INT( 1 ) NOT NULL DEFAULT '0';

il faut modifier le script customers de l'admin pour ajouter ce champ.
Assez facile, tu as un champ customers_newsletter qui a presque les même caractéristiques.
La méthode consiste à rechercher ce qui se rapporte à customers_newsletter dans ton script et dupliquer les zones en remplaçant customers_newsletter par customers_option_flag (le nom de ton nouveau champ)
Avec un peu d'attention, tu verras ça se fait tout seul exemple :
tu trouves :

Code

        $customers_newsletter = tep_db_prepare_input($HTTP_POST_VARS['customers_newsletter']);

tu ajoutes à la suite comme ça :

Code

        $customers_newsletter = tep_db_prepare_input($HTTP_POST_VARS['customers_newsletter']);
        $customers_option_flag = tep_db_prepare_input($HTTP_POST_VARS['customers_option_flag']);

idem plus loin :

Code

                                'customers_newsletter' => $customers_newsletter);

en

Code

                                'customers_newsletter' => $customers_newsletter,
                                'customers_option_flag' => $customers_option_flag);

etc...
en fait à chaque fois que tu rencontres un customers_newsletter tu dupliques le code qui le concerne et tu remplaces le doublon customers_newsletter par customers_option_flag.

Je te laisse t'occuper des autres occurrences à traiter sur le même principe (sans oublier la requête) pour finir par cette section :

Code

          <tr>
            <td class="main"><?php echo ENTRY_NEWSLETTER; ?></td>
            <td class="main">
<?php
  if ($processed == true) {
    if ($cInfo->customers_newsletter == '1') {
      echo ENTRY_NEWSLETTER_YES;
    } else {
      echo ENTRY_NEWSLETTER_NO;
    }
    echo tep_draw_hidden_field('customers_newsletter');
  } else {
    echo tep_draw_pull_down_menu('customers_newsletter', $newsletter_array, (($cInfo->customers_newsletter == '1') ? '1' : '0'));
  }
?></td>
          </tr>

à la suite de quoi tu ajoutes

Code

          <tr>
            <td class="main"><?php echo "La désignation de ton champ..."; ?></td>
            <td class="main">
<?php
  if ($processed == true) {
    if ($cInfo->customers_option_flag == '1') {
      echo 'Oui';
    } else {
      echo 'Non';
    }
    echo tep_draw_hidden_field('customers_option_flag');
  } else {
    echo tep_draw_pull_down_menu('customers_option_flag', $option_flag_array, (($cInfo->customers_option_flag == '1') ? '1' : '0'));
  }
?></td>
          </tr>

Comme tu peux voir, il faudra aussi créer un $option_flag_array identique à $newsletter_array...
si tu fais tout comme il faut, tu as un nouveau champ dans ta fiche client qui est un menu déroulant qui permet de "marquer" un client avec cette option. (oui = 1 dans la bdd par exemple)
Et voilà! ça c'est pour gérer tes clients interdits dans l'admin.

Si tu arrives jusque là, on voit après la requête pour récupérer cette valeur directement dans ton module et ainsi automatiser la validation selon cette option dans la fiche client... tu verras c'est super vite fait (3 ou 4 lignes de code)

[smalto]

Salut Gnidhal,

J'en croyais pas mes yeux ce matin.... comme un gosse devant un sapin de Noël (un peu tôt dans la saison).

J'ai donc appliqué l'ensemble du code comme tu me l'avais proposé et tout fonctionne parfaitement. Vraiment super!

J'ai juste inversé les oui - non pour faciliter la lecture dans le tableau (j'utilise la contrib customers détails qui me permet de voir plus d'info). le oui (qui est avec valeur 0 dans la base) laisse le client utiliser le module Sur facture et le non (valeur 1 dans la bd) l'en empêche.

Je me suis attribué la valeur Non et j'ai vérifié dans la base j'obtiens bien la valeur 1 dans le champs. Tout marche nickel.

Alors je suis évidemment preneur pour la suite comme tu me l'a proposé, c'est à dire la dernière boulce pour faire communiquer la bd avec le module de paiement.
Merci beaucoup pour ton aide et bonne journée.

smalto

[Gnidhal]

Well! c'est cool!
alors maintenant, tu reviens dans ton module que tu as modifié comme indiqué en première réponse et tu remplaces

Code

$refus_client_liste = array('13',26','203','567');

ou ce que tu avais mis dans cet array
par

Code

  $customers_query = tep_db_query(" select customers_id from ".TABLE_CUSTOMERS." where customers_option_flag ='1' ");// la requête qui récupères les id clients en fonction du flag à 1
  $refus_client_liste = array(); // initialisation du tableau
  while ($custom_array = tep_db_fetch_array($customers_query)){ // fetch de la requête
    $refus_client_liste[] = $custom_array['customers_id'];// ajout des id clients correspondant à la requête dans le tableau
  }

Là c'est simple, on va rechercher dans la table customers, tous les clients qui sont marqués et on les insère dans le tableau ce qui leur interdit l'accès.
les autres modifs dans le module précisées en première réponse donc cette ligne

Code

      if (in_array($customer_id,$refus_client_liste)) $this->enabled =  false;

restent inchangées.

Complément d'infos : je t'ai donné ici les moyens de faire ce que tu voulais en te guidant sur ce qu'il fallait faire et comment. Tu as suivi mes conseils et a agi dans ton code avec autonomie. C'est super, le résultat est surement fonctionnel (sauf erreur de ma part).
Ne va toutefois pas prendre cela comme une habitude en venant demander tes ajouts et modifications à l'envie (non ce n'est pas ton anniversaire ni Noël!)
J'ai répondu à ta demande car tu t'es montré volontaire et m'a semblé capable de réaliser cette modif.
Cela peut servir de modèle à d'autres :
Ce petit guide est une méthode de codage et de modification rapide qui prouve qu'on peut faire un code actif avec peu de lignes en se basant sur l'existant sans pour autant être un développeur chevronné.
Il suffit d'attention, de bon sens et de logique.

Cette méthode peut s'appliquer à d'autres cas.

En réalité, ce qui est le plus délicat dans ton genre de demande est de savoir comment procéder. Et pour ça, il est vrai que bien connaitre le fonctionnement des scripts osC permet de savoir rapidement où agir et comment faire.

Je vais d'ailleurs déplacer ce post dans "échange développeurs" où il a désormais sa place.
Et si tout fonctionne, n'oublies pas de mettre "Résolu" dans le titre de ton post initial

[FoxP2]

pourquoi envoyer autant dans un tableau ?
les modules de paiement ne sont accessibles que si le client est loggué non ?
autant ajouter la globale customer_id dans le constructeur de la class et rajouter une méthode de validation(return true/false) avec une requète sur le flag et le customer_id(dans la table customers) plutôt que lister tous les clients ... nan ?
j'ai tout faux ... ? bah je alors ...

[Gnidhal]

Bah pas tout, mais le but est d'interdire le module à une liste de clients, donc :
- j'ai voulu faire un code simple, compréhensible par un béotien, optimisable certes, mais bon.
- la requête ne mets dans le tableau que les id de clients non voulus ; //where customers_option_flag = '1' ; '0' est la valeur par défaut, donc en principe le plus grand nombre.
- on ne passe pas le customer_id à la classe mais à la méthode via un global dans cette fonction ; //wai : on en a pas besoin ailleurs, mais mieux, cet id doit se trouver dans l'objet $order : $order->customer['id'] donc on pourrait s'en passer, ok. Toutefois il est bon de savoir que cette variable $customer_id identifiant le client quand il est loggué est en session et qu'elle est récupérable partout via un global si nécessaire. En complément, un module de paiement n'est en principe accessible que quand le client est loggé. Donc cette variable est remplie.
- pour le reste, si le $customer_id est dans le tableau des id non autorisé, le flag enabled de la classe passe à false
On peut faire plus court et plus simple ?

[FoxP2]

oui, y'a plus simple :
fichier login :
ajouter le champs :
customers_option_flag à la requête $check_customer_query
l'assigner à une variable :
$customer_option_flag = $check_customer['customers_option_flag'];
l'enregistrer en session :
tep_session_register('customer_option_flag');
appeler la globale $customer_option_flag dans le constructeur de la class de paiement et vérifier :
if ($customer_option_flag == 1) $this->enabled = false;

ce qui donne pour le module cod (par exemple)

Code

// class constructor
    function cod() {
      global $order, $customer_option_flag;
.../...
      if ($customer_option_flag == 1) $this->enabled = false;
    }

cqfd

Ce message a été modifié par FoxP2 - 28 Sep 2010, 08:01.

[Gnidhal]

Donc désigner le client comme appartenant au bon groupe dès son enregistrement.
En effet, plus rapide. Puriste va!

[smalto]

Hello Gnidhal,

Juste un petit retour quant à l'implémentation de la suite du code que tu m'as donné. En effet tout fonctionne à merveille et c'est un gain de temps considérable pour mon travail. Je pense également que ce hack peut intéresser pas mal de monde qui veulent interdire ou autoriser un module de paiement pour certains clients.

Merci beaucoup pour le temps consacré ainsi que l'aide apportée. A bientôt et bonne soirée.

smalto

[FoxP2]

Puriste va!

pas vraiment, si tu suis ce prochain cas de figure capilotracté :
tu as un client, bernard madoff (au hasard) à qui tu veux interdire un moyen de paiement. mais celui ci est déjà loggé sur la boutique et pousse son caddie dans tes rayons ... sapristi !
-> il faut ajouter une requête imbriquée sur les tables whos_online(customer_id / session_id) et sessions(sesskey) et modifier le contenu du champs value ... donc modifier la valeur enregistrée en session pour bernard. (dans le fichier admin/customers à l'action update)

et si il a déjà passé l'étape du paiement (avant que t'es enregistré dans ton backoffice ), bah notre flag sera insuffisant.
0 ou 1, en l'état, est guère pratique sans requête supplémentaire dans le checkout_confirmation/checkout_process.

c'est pour cela que je recommande que la valeur du flag soit le 'code' du mode de paiement interdit. ils sont enregistrés dans MODULE_PAYMENT_INSTALLED et donc accessible via un menu déroulant dans le fichier admin/customers.
ce qui permet ensuite de faire un simple :

Code

if($payment == $customer_option_flag) {
   tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL'));
  }

dans checkout_confirmation et checkout_process.
le cas de figure (une fois l'étape paiement passée) se présente également avec ta méthode en cas de changement dans le back office.

pour conclure, j'admet que cela dépasse le 'coup de pouce' de départ que tu as donné à smalto. mais comme nous sommes dans 'échanges développeurs' je me suis permis de développer cet échange.


[edit]correction : le flag doit être le 'code' du module, pas le 'title', imbécile que je suis[/edit]

Ce message a été modifié par FoxP2 - 30 Sep 2010, 14:12.

[Gnidhal]

Oui alors là, tu compliques... (ok : échange développeur mais ne trollons pas tout de même)
Avec ma méthode la vérif se fait dans le module, donc quand il est dans la page paiement.
Si tu as changé le flag après son identification mais avant qu'il ne soit dans la page paiement, il ne verra pas le module.
Avec ta méthode de capter le flag lors de l'identification, on économise une requête dans le module car on a cette variable en session. Mais tu ne peux modifier le flag dès lors que le client est déjà identifié. Ou alors il faut refaire une requête de vérif dans le module que ce soit sur un whois_online ou dans la table customers. Ce qui n'économise rien.
Donc je ne te suis pas sur ton développement et persiste dans ma méthode car c'est :
1 la plus simple à mettre en oeuvre
2 la plus sure dans le fonctionnement même si le client est déjà enregistré.
Note qu'après paiement, on s'en fout un peu car justement le but est de masquer un module pour un client qui ne devrait pas y avoir accès et que le cas où on voudrait bloquer un client qui est déjà en ligne doit être assez rare pour que on puisse reprendre ton procédé avec un flag en session placé à l'identification.
Donc 1 partout et balle au centre

[FoxP2]

2 la plus sure dans le fonctionnement même si le client est déjà enregistré.

je trouve que ça n'a rien de sûr.
tu ne vérifies pas si le type de paiement est autorisé au client au checkout_confirmation & checkout_process.
ça me parait indispensable, comme l'est tout autant celle de vérifier si le mode de livraison est présent.

Ou alors il faut refaire une requête de vérif dans le module que ce soit sur un whois_online ou dans la table customers. Ce qui n'économise rien.

la requête supplémentaire ne se fait que côté admin pour 1 client à 1 moment donné (lors de l'update pour le flag)
ta requête se fait pour tous les clients dès qu'ils arrivent sur la page paiement.

je vais même aller un peu plus loin :
mettre le nom du module de paiement dans le flag (d'un champs de la table customers) permet de simplifier et dynamiser les choses.
car dans ce cas là, il n'y a plus lieu de toucher au class des modules de paiement, il suffit de modifier une seule ligne de la class payment dans la méthode selection :
(sur la même conditionnelle qui vérifie si les modules sont enabled, auquel cas il met dans un tableau)

Code

.../...
function selection() {
.../...
if ($GLOBALS[$class]->enabled) {

devient:

Code

if ($GLOBALS[$class]->enabled && $class != array_shift(func_get_args(0))) {

le flag qu'on envoie (à la méthode de la class payment) dans la page checkout_payment :

Code

.../...
<?php  
  $selection = $payment_modules->selection($customer_flag_option);
.../...

totalement dynamique :
un client X peut avoir un module A interdit
un client Y peut avoir un module B interdit

Code

on voudrait bloquer un client qui est déjà en ligne doit être assez rare pour que on puisse reprendre ton procédé avec un flag en session placé à l'identification.

on ne programme pas en fonction des cas rares mais plutôt pour répondre à toutes les situations.


si quelqu'un connait un add-on qui fait ça, je suis preneur, histoire d'étudier le code. merci

[FoxP2]

sacrebleu !
j'ai zappé une méthode de la class payment :
il faut modifier :

Code

function checkout_initialization_method() {
.../...
if ($GLOBALS[$class]->enabled && method_exists($GLOBALS[$class], 'checkout_initialization_method')) {

par :

Code

if ($GLOBALS[$class]->enabled && method_exists($GLOBALS[$class], 'checkout_initialization_method') && $class != array_shift(func_get_args(0))) {

et changer dans la page shopping_cart:

Code

$initialize_checkout_methods = $payment_modules->checkout_initialization_method();

par :

Code

$initialize_checkout_methods = $payment_modules->checkout_initialization_method($customer_flag_option);

cette méthode checkout_initialization_method est par exemple usité dans le module paypal_express.

[Gnidhal]

tu ne vérifies pas si le type de paiement est autorisé au client au checkout_confirmation & checkout_process.

Un truc m'a échappé sûrement mais comme le module est désactivé par lui-même dans sa fonction, comment veux-tu qu'il devienne actif dans une autre page ?
Puisqu'il fait le test de savoir si le $customer_id permet son activation, je ne vois pas comment passer outre.
Ou alors cela signifie qu'un module installé mais placé en "désactivé" dans la partie admin reste utilisable ?

un client X peut avoir un module A interdit
un client Y peut avoir un module B interdit

Bah ça c'est simple, il suffirait de modifier un peu le patch que je propose pour admin/customers.php pour étendre de fait assez facilement cela à tous les modules présents en l'état avec une simple modif on peut gérer 3 modules
Au départ j'utilise un champ de type int avec un 0 par défaut. (on pourrait utiliser un champ boolen, ok)
Cela dit, sur 1 caractère (de 1 à 9, 0 signifiant inutilisé) on peut gérer 3 modules :
1, 2, 4, et addition des combinaisons : 1+2, 1+4, 2+4, 1+2+4. Pour 4 modules il faudrait passer en varchar sur 1 seul caractère (besoin de 24 valeurs et on en a 35 mais c'est un peu lourdingue à décrypter pour savoir si le module D est dans le groupe K ou R) ou carrément sur un varchar à plusieurs caractères (dans ce cas on ne cherche plus mais on fait un codage par matrice qu'on explode en tableau) puisqu'à partir de 5 modules à gérer on devra avoir recours à ce type de masque.

Donc je persiste : secure et évolutif.

[FoxP2]

ta question de départ était :

On peut faire plus court et plus simple ?

et quand je lis :

Bah ça c'est simple,
.../...
dans ce cas on ne cherche plus mais on fait un codage par matrice qu'on explode en tableau puisqu'à partir de 5 modules à gérer on devra avoir recours à ce type de masque.

je me laisse à penser qu'on est loin de la première question, qui était mon intérêt dans ce débat.
au plus simple, à mes yeux, en conception objet,
1 c'est enregistrer la variable en session du module désactivé (par le fichier login - sans requète supplémentaire) en changeant la nature du flag.
2 vérifier via la class 'globale' payment la valeur de cette variable, auquel cas, le module n'est pas sélectionnée. (2 fichiers : catalog/shopping_cart[1 ligne] & /catalog/includes/classes/payment[2 lignes])
si tu considères que ta solution est plus simple, nous avons alors des façons de développer diamétralement opposées.
je crois que j'ai perdu asszez de temps sur sujet, donc je le laisse en l'état ma réflexion.

[Gnidhal]

si tu considères que ta solution est plus simple, nous avons alors des façons de développer diamétralement opposées.

Pas forcément.
Une manière de voir et d'analyser différente, c'est sûr.
J'ai admis que le flag en session était plus court. Mais dans le dev et les évolutions futures je vois les choses autrement.
Peut-être que cela vient d'une déformation conséquente à un usage récurent de ces forums et à de mauvaises habitudes de codage liées à notre osC même.