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!
Thank you! We are talking about 20k users, 10k are tl1 after migration, and the other 10k are 0, I would only want to promote the TL1 ones but I can with this query, right?
User.exec_sql("UPDATE users SET trust_level = 2 WHERE trust_level IN ( 1)")
Also another point is that there have in the meantime been signups of “real” new members who I don’t want to promote to TL2 without them earning it
Would there be a way to include some kind of registration date criteria? Eg all TL1 who registered before March 17 2020?
Yes @Queth Would you like me to post a copy of the structure of the users table so you can see all the different entries there?
Update: Here is it @Queth … you can see from the table description you have a lot of choices
users table
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)
It’s always a good idea to SELECT first and make sure you are happy with your query before UPDATE and always make a full backup before you start monkeying around with mass DB changes. Fat finger mistakes happen to even the best of the best. One of the main differences between an expert and a novice is the expert always makes a backup first
I would love to; but some things are easier (and better) done by you doing a bit of your own homework. You have all the pieces of the puzzle, so my advise is to spend a bit of time and learn to write an SQL query. Honestly, this is just postgres SQL query 101 stuff that can be found on myriad tutorials online.
That’s not “my thing” to repeat “tutorial 101” kinds of things on info easily found by others doing their own Google homework. That’s just me. Thanks for understanding and please forgive me for my honesty…
Note: SQL has been around since 1974, or 46 years ago. It’s a good thing to have basic SQL knowledge if you are going to admin a DB based application.
Thanks
Well I do have basic basic knowledge but writing queries from scratch is still something I rather copy paste from a trusted source instead of trying to devise my own.
It’s always a good idea to SELECT first and make sure you are happy with your query before UPDATE and always make a full backup before you start monkeying around with mass DB changes.
