Nettoyer les tables d'utilisateurs Joomla! et Virtuemart ?

[RobertG]

Bonjour,

Comme je l'ai dit dans une autre discussion, je m'occupe épisodiquement d'un site e-commerce où de nombreux faux acheteurs se sont enregistrés, même après la mise en place d'un captcha invisible.
A l'occasion de la migration en V4, j'aimerais nettoyer les différentes tables de ces indésirables, mais il y a au moins 4 tables concernées : utilisateurs Joomla! et leur map, utilisateurs et leurs détails dans Virtuemart, à comparer avec l'absence de commande dans la table correspondante de VM.
Je dois dire que même si j'ai souvent créé des requêtes sur des bases de données, je vois mal comment faire sur quatre.
Il faudrait donc, avec le risque de supprimer en excès des clients potentiels n'ayant pas finalisé de commande, repérer dans la table users de VM ceux n'ayant pas de commande dans orders et utiliser cette information pour supprimer les entrées correspondantes dans les tables users et user_infos de VM puis dans les tables users et usergroup_maps de Joomla!

Dans un premier temps, je m'étais dit que, côté Joomla!, je pourrais sélectionner ceux ayant exactement la même date de création du compte et de visite, mais si le visiteur finalise une commande en créant son compte et ne revient pas, son inscription est licite. Je ne peux donc pas me baser sur ce point.

Serait-il plus facile de passer par une requête SQL ou via un script PHP ?
Que me conseillez-vous ? Merci d'avance !

[RobertG]

Bien avec cette requête, je peux obtenir la liste de tous les comptes utilisateurs n'ayant jamais commandé (4214 sur 9059 ! dans la version de test de la base), et il semble que l'identifiant VM soit le même que celui de Joomla!

SELECT a.virtuemart_user_id FROM `nosn6f_virtuemart_vmusers` as a WHERE a.virtuemart_user_id NOT IN (SELECT b.virtuemart_user_id FROM `nosn6f_virtuemart_orders` as b );

Maintenant je coince sur comment compléter cette requête pour supprimer les lignes dans les quatre tables users, usergroup_map, vmusers et userinfo.

[lomart]

Bonsoir Robert,

L'extension que tu m'as suggéré ce matin ne fait-elle pas cela ? Elle prend en charge Virtuemart

https://forum.joomla.fr/forum/joomla-4-x-aa/questions-g%C3%A9n%C3%A9rales-aa/2043475-recherche-plugins?p=2043485#post2043485

[RobertG]

J'étais en train de regarder justement, mais si je comprends bien, elle fonctionne en automatique via une tâche cron, et comme il semblerait qu'avec le captcha il y ait une nette diminution des inscriptions, un clic pour lancer, après vérification de l'administration, une requête manuelle ou un script me semblerait suffire.
De plus, il semble qu'un mail est envoyé à l'inscrit et que s'il ne répond pas, il est automatiquement supprimé, mais aussi, la première clause est que s'il ne s'est jamais connecté on le supprime, or les enregistrements se faisant depuis VM, la date de dernière connexion n'est jamais nulle.
Bref, je ne suis pas sûr que ce script corresponde à ce que je cherche à faire.

[lomart]

Bref, je ne suis pas sûr que ce script corresponde à ce que je cherche à faire.

C'était une piste

Reste la délicate requête SQL.

[RobertG]

Oui, c'est pour ça que j'ai exploré ce plugin.

En effet, reste la requête. J'ai réussi à en construire une capable de renvoyer les différentes lignes des quatre tables, mais je ne sais pas comment la transformer en requête de suppression de toutes ces lignes, mais aussi s'il est possible de ne sélectionner que les enregistrements datant d'avant une date définie de manière dynamique (-365 jours par exemple).

SELECT a.virtuemart_user_id, j.id, g.user_id, f.virtuemart_user_id as infos FROM `nosn6f_virtuemart_vmusers` as a
INNER JOIN nosn6f_users as j
INNER JOIN nosn6f_user_usergroup_map as g
INNER JOIN nosn6f_virtuemart_userinfos as f
WHERE a.virtuemart_user_id NOT IN (SELECT b.virtuemart_user_id FROM `nosn6f_virtuemart_orders` as b )
AND a.virtuemart_user_id = j.id
AND j.id = g.user_id
AND j.id = f.virtuemart_user_id;

J'aurais donc tendance à envisager un script PHP autonome ou un plugin, si tant est que j'arrive à créer un plugin de A à Z.

[lomart]

J'aurais donc tendance à envisager un script PHP autonome ou un plugin, si tant est que j'arrive à créer un plugin de A à Z

Tu peux créer une action UP qui va faire le boulot fastidieux. Tu n'as plus que le coeur de ta routine à écrire.
Voir https://up.lomart.fr/docs/articles/prog-creation
J'en ai également parler lors de ma présentation au Joomladay. Voir à partir de 1h53

https://www.joomladay.fr/replay-2022?utm_source=sendinblue&utm_campaign=jd19fr&utm_medium=email#semaine8

[RobertG]

Merci Loïc,

Mon but n'est pas d'afficher mais de supprimer ces enregistrements indésirables à la demande, j'ai regardé ton tuto et je ne comprends pas comment UP le fera.

Il y a quelques mois, j'avais fait un script pour Event Booking afin de supprimer (par tâche cron) en une passe les fichiers orphelins (envoyés vie le formulaire d'inscription) puis les inscriptions et leurs fichiers joints antérieurs à une date limite. Je me demande si je ne vais pas m'en inspirer.

[lomart]

Mon but n'est pas d'afficher mais de supprimer ces enregistrements indésirables à la demande, j'ai regardé ton tuto et je ne comprends pas comment UP le fera.

Les actions de UP ne sont pas obligées d'afficher quelque chose.
Tu peux créer une action "nettoyage" qui contient la récupération des ID a effacer, puis une boucle de suppression après contrôle des dates dans virtuemart
Tu termines par un return ''; ou return 'FINI'

Tu lances l'exécution par un {up nettoyage} dans un article

[RobertG]

OK, merci Loïc, j'essaierai de m'y retrouver.

[lomart]

Un script xxx.php appelé dans l'URL doit faire la même chose.

[RobertG]

Oui, c'est ce que j'avais fait pour Event Booking : trouver les fichiers orphelins, non répertoriés dans la base, puis récupérer les inscrits des anciens événements, supprimer les fichiers correspondants, les inscrits et enfin les événements, avec une tâche toutes les deux semaines.
Je dois pouvoir faire l'équivalent pour ce projet-ci.

[RobertG]

Bon, j'ai mon script, il faut que je l'affine mais c'est bien parti.
Requête de récupération de tous les comptes n'ayant pas passé de commande et n'étant pas actifs de plus de 6 mois, et ensuite boucle pour supprimer dans les différentes tables.
J'ai ajouté aussi la suppression des comptes avec une adresse de messagerie en "ru", et je vais le faire aussi pour les "yandex".
En effet, malgré l'exclusion de ces serveurs, les comptes sont toujours créés.