こんにちは、この件については新しいトピックを作成しました。以前は「解決済み」としてマークしてしまっていたため、前のトピック での質問が見落とされているように思われますが、実際には解決していません。
状況：Discourse に移行したところ、旧フォーラムのメンバー全員が TL1 のままです。これは不公平だと彼らも感じているため、要件を変更して全員を TL2 に引き上げたいと考えています。移行前にアカウントを無効化していたため、多くのユーザーが非アクティブな状態です。
TL2 の要件を「投稿数のみ」に変更し、ログイン日数を 0 に設定しました。
10 日経っても、ごく少数のユーザーしか昇格していません。どうやら、TL2 の判定が行われるためにはログインするか、返信を投稿する必要があるようです（どちらの条件かはまだ特定できていません）。
旧フォーラムの全メンバーに TL2 権限を付与したいと考えています。何かコマンドを実行して、条件を満たす全ユーザーを昇格させる方法はありますか？
ご協力とご知見を心よりお待ちしております！
おそらく:
users = User.where('admin = false')
users.update_all(trust_level: 2)
このクエリを実行すると、モデレーターもすべて信頼レベル2に変更されてしまいます。
@Queth が本当にそれを望んでいるのかはわかりません。
より低い信頼レベルからより高いレベル（およびその逆）へ、すべてのユーザーを一括で移動させる方法について、Howto が存在します。
迅速なご返信、誠にありがとうございます！
一時的に mods を tl2 に変更しても構いません。後で手動で TL を設定できると思います。mod の機能に影響はないでしょうか？
ありがとうございます！移行後、20,000 人のユーザーのうち 10,000 人は tl1、残りの 10,000 人は 0 です。tl1 のユーザーのみを昇格させたいのですが、このクエリで可能でしょうか？
User.exec_sql("UPDATE users SET trust_level = 2 WHERE trust_level IN ( 1)")
また、この間に「本当の」新規メンバーが登録しており、彼らがその資格を得る前に TL2 に昇格させたくありません 
登録日時の条件を含める方法はありますか？例えば、2020 年 3 月 17 日以前に登録したすべての tl1 ユーザーなど。
はい、@Queth さん。ユーザーテーブルの構造のコピーを投稿して、そこに含まれるさまざまなエントリをご覧いただいてもよろしいでしょうか？
更新：こちらです @Queth さん… テーブルの説明から、多くの選択肢があることがお分かりいただけると思います
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)
UPDATE を実行する前に、まず SELECT を実行してクエリが意図通りであることを確認するのが常に賢明です また、大量のデータベース変更を行う前に、必ず完全なバックアップを取得してください。熟練者であっても誤操作は起こり得ます。エキスパートと初心者の主な違いの一つは、エキスパートは常に最初にバックアップを作成するということです
@neounix さん、ありがとうございます！
正しいクエリについてお手伝いいただけますか？やり方がわからないので…
おそらく、以下のように記述する必要があると思います。
Where user created at < [2020 年 3 月 17 日（正しい形式に変換）]
ぜひお手伝いしたいのですが、ある程度ご自身で調べていただく方が（結果としても）簡単で良い場合もあります。パズルのピースはすべて揃っていますので、少し時間をかけてSQLクエリの書き方を学ばれることをお勧めします。正直なところ、これはPostgreSQLのSQLクエリの基礎中の基礎（101レベル）であり、インターネット上の無数のチュートリアルで確認できます。
私には、他者が自分でGoogle検索すれば簡単に入手できるような「チュートリアル101」的な内容を繰り返し説明するのは得意ではありません。それが私のスタンスです。ご理解いただき、私の率直さを許してください。
注：SQLは1974年、つまり46年前から存在しています。DBベースのアプリケーションを管理されるのであれば、SQLの基礎知識を持っていることは非常に役立ちます。
ありがとうございます
確かに基礎的な知識はありますが、クエリを一から書くのは、自分で考案するよりも信頼できるソースからコピー＆ペーストする方が好きです。
とはいえ、構築の基礎となるものを教えていただき、本当にありがとうございます！
UPDATE する前に必ず SELECT を実行し、クエリに満足してから進めるのが良い習慣です 。また、大量のデータベース変更を始める前には、必ず完全なバックアップを取得してください。