Hallo, ich eröffne hier ein neues Thema, da ich der Meinung bin, dass meine Fragen in einem früheren Thema über dieses Anliegen übersehen wurden, da ich es ursprünglich als gelöst markiert habe, es jedoch nicht ist.
Fall: Ich habe zu Discourse migriert, und alle Mitglieder des alten Forums haben das Vertrauensniveau TL1, was sie als unfair empfinden. Daher wollte ich sie alle auf TL2 hochstufen, indem ich die Anforderungen änderte. Viele von ihnen sind inaktiv, da ich die Konten vor der Migration deaktivieren musste.
Ich habe die Anforderungen für TL2 auf die reine Anzahl der Beiträge und die Anzahl der Besuchstage auf 0 geändert.
Nach 10 Tagen wurden nur wenige Benutzer befördert. Es scheint also, dass sich Benutzer einloggen oder eine Antwort veröffentlichen müssen, damit die TL2-Prüfung stattfindet. (Ich habe noch nicht herausgefunden, welche der beiden Bedingungen ausschlaggebend ist.)
Ich würde gerne allen ehemaligen Mitgliedern meines Forums das TL2-Status erteilen. Gibt es eine Möglichkeit, einen Befehl auszuführen, um dies zu tun? Etwas wie das Durchgehen aller Benutzer und deren Beförderung, wenn sie die neuen TL2-Kriterien erfüllen?
Vielen Dank im Voraus für Ihre Hilfe und Ihre Einschätzungen!
Es gibt eine Anleitung, wie man alle Benutzer von einem niedrigeren Vertrauenslevel auf ein höheres Level verschiebt (und umgekehrt): Modify trust level for all users
Es stört mich nicht, Mods vorübergehend auf TL2 zu ändern; ich kann ihren TL danach manuell anpassen. Ich denke, das würde die Mod-Fähigkeiten nicht beeinträchtigen. Oder doch?
Danke! Wir sprechen hier von 20.000 Nutzern: Nach der Migration haben 10.000 den TL1 und die anderen 10.000 den TL0. Ich möchte nur die mit TL1 befördern, kann das aber mit dieser Abfrage tun, oder?
User.exec_sql("UPDATE users SET trust_level = 2 WHERE trust_level IN (1)")
Ein weiterer Punkt: In der Zwischenzeit haben sich auch „echte
Ja, @Queth. Möchtest du, dass ich eine Kopie der Struktur der users-Tabelle poste, damit du alle verschiedenen Einträge darin sehen kannst?
Update: Hier ist sie, @Queth … du kannst der Tabellendescription entnehmen, dass du viele Möglichkeiten hast
users-Tabelle
discourse=# \d users
Tabelle "public.users"
Spalte | Typ | Kollation | Nicht null | Standard
---------------------------+-----------------------------+-----------+----------+-----------------------------------
id | integer | | nicht null | nextval('users_id_seq'::regclass)
username | character varying(60) | | nicht null |
created_at | timestamp without time zone | | nicht null |
updated_at | timestamp without time zone | | nicht null |
name | character varying | | |
seen_notification_id | integer | | nicht null | 0
last_posted_at | timestamp without time zone | | |
password_hash | character varying(64) | | |
salt | character varying(32) | | |
active | boolean | | nicht null | false
username_lower | character varying(60) | | nicht null |
last_seen_at | timestamp without time zone | | |
admin | boolean | | nicht null | false
last_emailed_at | timestamp without time zone | | |
trust_level | integer | | nicht null |
approved | boolean | | nicht 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 | | nicht null | 0
flag_level | integer | | nicht 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 | | nicht 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 | | |
Indizes:
"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)
Referenziert von:
TABELLE "user_security_keys" CONSTRAINT "fk_rails_90999b0454" FOREIGN KEY (user_id) REFERENCES users(id)
TABELLE "poll_votes" CONSTRAINT "fk_rails_b64de9b025" FOREIGN KEY (user_id) REFERENCES users(id)
TABELLE "bookmarks" CONSTRAINT "fk_rails_c1ff6fa4ac" FOREIGN KEY (user_id) REFERENCES users(id)
Es ist immer eine gute Idee, zuerst SELECT auszuführen und sicherzustellen, dass du mit deiner Abfrage zufrieden bist, bevor du UPDATE ausführst Und mache immer ein vollständiges Backup, bevor du mit massiven Änderungen an der Datenbank herumspielst. Fehler durch Ausrutscher passieren sogar den Besten unter den Besten. Einer der Hauptunterschiede zwischen einem Experten und einem Anfänger besteht darin, dass der Experte immer zuerst ein Backup erstellt
Ich hätte das sehr gerne gemacht; aber einige Dinge sind einfacher (und besser), wenn du dir selbst ein wenig die Mühe machst. Du hast alle Puzzleteile, also mein Rat ist, dir etwas Zeit zu nehmen und zu lernen, wie man eine SQL-Abfrage schreibt. Ehrlich gesagt ist das nur grundlegendes Postgres-SQL-Wissen, das in unzähligen Online-Tutorials zu finden ist.
Es liegt nicht in meinem Interesse, “Tutorial 101”-artige Inhalte zu wiederholen, die andere leicht durch eigene Google-Recherchen finden können. Das bin einfach ich. Danke für dein Verständnis und bitte verzeih mir meine Offenheit.
Hinweis: SQL gibt es seit 1974, also seit 46 Jahren. Grundlegende SQL-Kenntnisse sind eine gute Sache, wenn du eine datenbankbasierte Anwendung administrieren möchtest.
Danke
Ich habe zwar grundlegendes Grundwissen, aber Abfragen von Grund auf zu schreiben, ist etwas, das ich lieber von einer vertrauenswürdigen Quelle kopiere und einfüge, anstatt sie selbst zu entwickeln.
Es ist immer eine gute Idee, zuerst SELECT auszuführen und sicherzustellen, dass du mit deiner Abfrage zufrieden bist, bevor du UPDATE ausführst . Mache zudem immer ein vollständiges Backup, bevor du mit massiven Datenbankänderungen herumspielst.
