Здравствуйте, я создаю новую тему по этому вопросу, так как считаю, что мои вопросы в предыдущей теме были проигнорированы, поскольку изначально я пометил её как решённую, но на самом деле проблема не решена.
Ситуация: я мигрировал на Discourse, и у всех участников старого форума уровень доверия TL1, что они считают несправедливым. Поэтому я хотел повысить их всех до TL2, изменив требования. Многие из них неактивны, так как мне пришлось деактивировать учётные записи перед переносом.
Я изменил требования для TL2, оставив только количество сообщений, и установил количество дней посещений равным 0.
Спустя 10 дней только несколько пользователей были повышены, поэтому, похоже, чтобы проверка на TL2 сработала, пользователи должны войти в систему или написать ответ (я ещё не выяснил, что именно требуется).
Мне бы очень хотелось иметь возможность присвоить всем бывшим участникам моего форума статус TL2. Есть ли способ выполнить команду где-нибудь, чтобы сделать это? Что-то вроде перебора всех пользователей и повышения тех, кто соответствует новым критериям TL2.
Я не против временно изменить моды на tl2, думаю, я смогу вручную установить их TL после этого. Не думаю, что это повлияет на возможности модов? Или повлияет?
Спасибо! Мы говорим о 20 тысячах пользователей: после миграции 10 тысяч имеют TL1, а остальные 10 тысяч — TL0. Я хочу повысить уровень только тем, у кого TL1, и могу сделать это с помощью этого запроса, верно?
User.exec_sql("UPDATE users SET trust_level = 2 WHERE trust_level IN ( 1)")
Ещё один момент: за это время зарегистрировались «настоящие» новые участники, которых я не хочу повышать до TL2, пока они этого не заслужат
Есть ли способ добавить критерий даты регистрации? Например, все TL1, зарегистрировавшиеся до 17 марта 2020 года?
Да, @Queth. Хотите, чтобы я опубликовал копию структуры таблицы пользователей, чтобы вы могли увидеть все различные поля?
Обновление: Вот она, @Queth… Как видно из описания таблицы, у вас есть множество вариантов
таблица 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)
Всегда полезно сначала выполнить SELECT и убедиться, что запрос работает так, как вы ожидаете, прежде чем выполнять UPDATE И всегда делайте полную резервную копию перед внесением массовых изменений в базу данных. Ошибки из-за неловкости пальцев случаются даже у лучших из лучших. Одно из главных отличий эксперта от новичка в том, что эксперт всегда сначала делает резервную копию
Я бы с радостью, но некоторые вещи проще (и лучше) сделать, если вы немного потрудитесь самостоятельно. У вас уже есть все части пазла, поэтому мой совет — уделите немного времени и научитесь писать SQL-запросы. Честно говоря, это базовые знания по PostgreSQL (уровень 101), которые можно найти в множестве онлайн-уроков.
Мне не хочется повторять основы, которые легко найти другим, если они потратят время на собственный поиск в Google. Таков уж я. Спасибо за понимание, и, пожалуйста, простите меня за мою прямоту.
Примечание: SQL существует с 1974 года, то есть уже 46 лет. Если вы планируете администрировать приложение на базе базы данных, наличие базовых знаний SQL — это очень полезно.
Спасибо
У меня, конечно, есть базовые знания, но писать запросы с нуля я всё же предпочитаю копировать из проверенных источников, чем пытаться придумать свои.
Всегда хорошая идея сначала выполнить SELECT и убедиться, что вас устраивает ваш запрос, прежде чем делать UPDATE , и всегда создавать полную резервную копию, прежде чем начинать возиться с массовыми изменениями в базе данных.
