Olá, estou abrindo um novo tópico sobre isso, pois acredito que minhas perguntas em um tópico anterior sobre o assunto foram ignoradas, já que originalmente o marquei como resolvido, mas não está.
Caso: Migrei para o Discourse, e os membros do fórum antigo têm todos o nível TL1, o que eles consideram injusto. Então, eu gostaria de promovê-los todos ao TL2 alterando os requisitos. Muitos deles estão inativos porque precisei desativar as contas antes da migração.
Mudei os requisitos do TL2 para basearem-se apenas na contagem de postagens e dias de visita para 0.
Após 10 dias, apenas alguns usuários foram promovidos, então parece que as pessoas precisam fazer login ou responder a uma postagem para que a verificação do TL2 ocorra. (Ainda não descobri qual das duas é a condição necessária).
Gostaria muito de poder conceder a todos os antigos membros do meu fórum o status TL2. Existe alguma maneira de executar um comando em algum lugar para fazer isso? Algo como percorrer todos os usuários e promovê-los se atenderem aos novos critérios do TL2.
Muito obrigado antecipadamente pela sua ajuda e insights!
Não me importo de mudar os mods para tl2 temporariamente; acho que posso definir o TL deles manualmente depois. Acredito que isso não afetaria as habilidades dos mods? Afetaria?
Obrigado! Estamos falando de 20 mil usuários: 10 mil são tl1 após a migração e os outros 10 mil são 0. Eu gostaria de promover apenas os tl1, e consigo fazer isso com essa consulta, certo?
User.exec_sql("UPDATE users SET trust_level = 2 WHERE trust_level IN ( 1)")
Outro ponto é que, nesse meio tempo, houve inscrições de novos membros “reais” que eu não quero promover para TL2 sem que eles tenham conquistado isso
Haveria uma maneira de incluir algum critério de data de registro? Por exemplo, todos os TL1 que se registraram antes de 17 de março de 2020?
Sim, @Queth. Você gostaria que eu publicasse uma cópia da estrutura da tabela de usuários para que você possa ver todas as entradas diferentes?
Atualização: Aqui está, @Queth… você pode ver, pela descrição da tabela, que você tem muitas opções
tabela de usuários
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)
Sempre é uma boa ideia fazer um SELECT primeiro e ter certeza de que você está satisfeito com sua consulta antes de fazer um UPDATE e sempre faça um backup completo antes de começar a mexer em alterações em massa no banco de dados. Erros de digitação acontecem até mesmo com os melhores dos melhores. Uma das principais diferenças entre um especialista e um iniciante é que o especialista sempre faz um backup primeiro
Eu adoraria ajudar; mas algumas coisas são mais fáceis (e melhores) quando você mesmo faz um pouco do seu trabalho de casa. Você tem todas as peças do quebra-cabeça, então meu conselho é dedicar um tempo e aprender a escrever uma consulta SQL. Honestamente, isso é apenas o básico de SQL para PostgreSQL, algo que pode ser encontrado em inúmeros tutoriais online.
Não é “minha praia” repetir coisas do tipo “tutoriais básicos” sobre informações que outros podem facilmente encontrar fazendo sua própria pesquisa no Google. Isso é apenas eu. Obrigado pela compreensão e, por favor, perdoe minha honestidade.
Nota: SQL existe desde 1974, ou seja, há 46 anos. É bom ter conhecimentos básicos de SQL se você vai administrar um aplicativo baseado em banco de dados.
Obrigado
Bem, eu tenho um conhecimento básico, mas escrever consultas do zero ainda é algo que eu prefiro copiar e colar de uma fonte confiável, em vez de tentar criar a minha própria.
Sempre é uma boa ideia fazer um SELECT primeiro e ter certeza de que você está satisfeito com sua consulta antes de fazer um UPDATE , e sempre faça um backup completo antes de começar a mexer em mudanças em massa no banco de dados.
