Bonjour, j’ouvre un nouveau sujet à ce sujet car je pense que mes questions dans un sujet précédent à ce sujet ont été ignorées depuis que je l’ai initialement marqué comme résolu, mais ce n’est pas le cas.
Cas : J’ai migré vers Discourse, et les membres de l’ancien forum ont tous le niveau TL1, ce qu’ils jugent injuste. J’ai donc voulu les promouvoir tous au niveau TL2 en modifiant les exigences. Beaucoup d’entre eux sont inactifs car j’ai dû désactiver les comptes avant la migration.
J’ai modifié les exigences du niveau TL2 pour qu’elles soient basées uniquement sur le nombre de publications et les jours de connexion à 0.
Après 10 jours, seule une poignée d’utilisateurs a été promue. Il semble donc que les utilisateurs doivent se connecter ou publier une réponse pour que la vérification du niveau TL2 ait lieu. (Je n’ai pas encore déterminé lequel des deux est nécessaire).
J’aimerais beaucoup pouvoir accorder le statut TL2 à tous les anciens membres de mon forum. Existe-t-il un moyen d’exécuter une commande quelque part pour le faire ? Quelque chose comme parcourir tous les utilisateurs et les promouvoir s’ils répondent aux nouveaux critères du niveau TL2.
Merci beaucoup par avance pour votre aide et vos éclaircissements !
Je n’ai pas de problème à changer temporairement les mods pour tl2 ; je pense pouvoir régler leur TL manuellement ensuite. Je ne pense pas que cela affecte les capacités des mods, n’est-ce pas ?
Merci ! Nous parlons de 20 000 utilisateurs : 10 000 seront en tl1 après la migration, et les 10 000 autres seront à 0. Je voudrais seulement promouvoir ceux qui sont en tl1, mais je peux le faire avec cette requête, n’est-ce pas ?
User.exec_sql("UPDATE users SET trust_level = 2 WHERE trust_level IN ( 1)")
Un autre point est qu’entre-temps, de nouveaux membres « réels » se sont inscrits, et je ne veux pas les promouvoir en tl2 sans qu’ils l’aient mérité
Y aurait-il un moyen d’inclure un critère de date d’inscription ? Par exemple, tous les tl1 qui se sont inscrits avant le 17 mars 2020 ?
Oui @Queth, veux-tu que je publie une copie de la structure de la table users afin que tu puisses voir toutes les différentes entrées ?
Mise à jour : Voici @Queth … tu peux voir, grâce à la description de la table, que tu as de nombreuses options
table users
discourse=# \d users
Table "public.users"
Column | Type | Collation | Nullable | Default
---------------------------+-----------------------------+-----------+----------+-----------------------------------
id | integer | | not null | nextval('users_id_seq'::regclass)
username | character varying(60) | | not null |
created_at | timestamp without time zone | | not null |
updated_at | timestamp without time zone | | not null |
name | character varying | | |
seen_notification_id | integer | | not null | 0
last_posted_at | timestamp without time zone | | |
password_hash | character varying(64) | | |
salt | character varying(32) | | |
active | boolean | | not null | false
username_lower | character varying(60) | | not null |
last_seen_at | timestamp without time zone | | |
admin | boolean | | not null | false
last_emailed_at | timestamp without time zone | | |
trust_level | integer | | not null |
approved | boolean | | not null | false
approved_by_id | integer | | |
approved_at | timestamp without time zone | | |
previous_visit_at | timestamp without time zone | | |
suspended_at | timestamp without time zone | | |
suspended_till | timestamp without time zone | | |
date_of_birth | date | | |
views | integer | | not null | 0
flag_level | integer | | not null | 0
ip_address | inet | | |
moderator | boolean | | | false
title | character varying | | |
uploaded_avatar_id | integer | | |
locale | character varying(10) | | |
primary_group_id | integer | | |
registration_ip_address | inet | | |
staged | boolean | | not null | false
first_seen_at | timestamp without time zone | | |
silenced_till | timestamp without time zone | | |
group_locked_trust_level | integer | | |
manual_locked_trust_level | integer | | |
secure_identifier | character varying | | |
Indexes:
"users_pkey" PRIMARY KEY, btree (id)
"index_users_on_secure_identifier" UNIQUE, btree (secure_identifier)
"index_users_on_username" UNIQUE, btree (username)
"index_users_on_username_lower" UNIQUE, btree (username_lower)
"idx_users_admin" btree (id) WHERE admin
"idx_users_moderator" btree (id) WHERE moderator
"index_users_on_last_posted_at" btree (last_posted_at)
"index_users_on_last_seen_at" btree (last_seen_at)
"index_users_on_uploaded_avatar_id" btree (uploaded_avatar_id)
Referenced by:
TABLE "user_security_keys" CONSTRAINT "fk_rails_90999b0454" FOREIGN KEY (user_id) REFERENCES users(id)
TABLE "poll_votes" CONSTRAINT "fk_rails_b64de9b025" FOREIGN KEY (user_id) REFERENCES users(id)
TABLE "bookmarks" CONSTRAINT "fk_rails_c1ff6fa4ac" FOREIGN KEY (user_id) REFERENCES users(id)
C’est toujours une bonne idée de faire un SELECT en premier pour vérifier que ta requête te convient avant de faire un UPDATE Et fais toujours une sauvegarde complète avant de commencer à manipuler des modifications massives de base de données. Les erreurs de frappe arrivent même aux meilleurs. L’une des principales différences entre un expert et un novice, c’est que l’expert fait toujours une sauvegarde en premier
J’aimerais beaucoup le faire, mais certaines choses sont plus faciles (et mieux) réalisées si vous faites un peu vos propres recherches. Vous avez toutes les pièces du puzzle, donc mon conseil est de prendre un peu de temps pour apprendre à écrire une requête SQL. Honnêtement, il s’agit simplement de notions de base sur les requêtes SQL pour PostgreSQL, que l’on trouve dans d’innombrables tutoriels en ligne.
Ce n’est pas « mon truc » de répéter des choses du type « tutoriel de base » sur des informations facilement accessibles par ceux qui font leurs propres recherches sur Google. C’est juste ma façon de voir. Merci de votre compréhension et veuillez m’excuser pour mon honnêteté.
Note : SQL existe depuis 1974, soit il y a 46 ans. Il est bon d’avoir des connaissances de base en SQL si vous devez administrer une application basée sur une base de données.
Merci
J’ai certes des connaissances de base, mais rédiger des requêtes à partir de zéro reste quelque chose que je préfère copier-coller d’une source fiable plutôt que d’essayer d’en concevoir moi-même.
C’est toujours une bonne idée de sélectionner d’abord et de s’assurer que vous êtes satisfait de votre requête avant de faire une mise à jour , et de toujours faire une sauvegarde complète avant de commencer à bricoler avec des modifications massives de la base de données.
