Hola, estoy abriendo un nuevo tema para esto, ya que creo que mis preguntas en un tema anterior sobre este asunto fueron pasadas por alto, ya que originalmente lo marqué como resuelto, pero no lo está.
Caso: Migré a Discourse y todos los miembros del antiguo foro tienen nivel de confianza 1 (TL1), lo cual consideran injusto, así que quería subirlos todos al nivel 2 (TL2) modificando los requisitos. Muchos de ellos están inactivos porque tuve que desactivar sus cuentas antes de la migración.
Cambié los requisitos del TL2 para que dependan únicamente del número de publicaciones y establecí los días de visita en 0.
Después de 10 días, solo un puñado de usuarios ha sido promovido, por lo que parece que los usuarios deben iniciar sesión o publicar una respuesta para que se ejecute la verificación del TL2. (Aún no he determinado cuál de las dos es la condición necesaria).
Me encantaría poder otorgar el estatus de TL2 a todos los exmiembros de mi foro. ¿Existe alguna forma de ejecutar un comando en algún lugar para lograrlo? Algo como recorrer todos los usuarios y promoverlos si cumplen con los nuevos criterios del TL2.
¡Muchas gracias de antemano por su ayuda y sus comentarios!
No me importa cambiar los mods a tl2 temporalmente; creo que puedo establecer su TL manualmente después. No creo que afecte las capacidades de los mods, ¿verdad?
¡Gracias! Estamos hablando de 20 mil usuarios: 10 mil son tl1 después de la migración y los otros 10 mil tienen nivel 0. Solo querría promover a los de TL1, ¿puedo hacerlo con esta consulta, verdad?
User.exec_sql("UPDATE users SET trust_level = 2 WHERE trust_level IN ( 1)")
Además, otro punto es que, mientras tanto, se han registrado nuevos miembros “reales” a los que no quiero promover a TL2 sin que lo hayan ganado
¿Existe alguna forma de incluir algún criterio de fecha de registro? Por ejemplo, ¿todos los de TL1 que se registraron antes del 17 de marzo de 2020?
Sí, @Queth. ¿Te gustaría que publique una copia de la estructura de la tabla de usuarios para que puedas ver todas las entradas diferentes que contiene?
Actualización: Aquí está, @Queth… puedes ver por la descripción de la tabla que tienes muchas opciones
tabla de usuarios
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)
Siempre es una buena idea ejecutar primero un SELECT y asegurarse de que estás satisfecho con tu consulta antes de hacer un UPDATE y siempre hacer una copia de seguridad completa antes de empezar a hacer cambios masivos en la base de datos. Los errores por despiste le ocurren incluso a los mejores de los mejores. Una de las principales diferencias entre un experto y un novato es que el experto siempre hace una copia de seguridad primero
Me encantaría ayudarte, pero algunas cosas es más fácil (y mejor) que las resuelvas tú mismo haciendo un poco de tu propia tarea. Tienes todas las piezas del rompecabezas, así que mi consejo es que dediques un poco de tiempo a aprender a escribir una consulta SQL. Honestamente, esto es solo material básico de SQL para PostgreSQL que se puede encontrar en una multitud de tutoriales en línea.
No es “mi estilo” repetir cosas tipo “tutoriales básicos” sobre información que otros pueden encontrar fácilmente haciendo su propia búsqueda en Google. Eso simplemente soy yo. Gracias por entender y perdóname por mi honestidad.
Nota: SQL existe desde 1974, es decir, hace 46 años. Es bueno tener conocimientos básicos de SQL si vas a administrar una aplicación basada en bases de datos.
Gracias
Bueno, tengo conocimientos básicos, pero escribir consultas desde cero aún es algo que prefiero copiar y pegar de una fuente confiable en lugar de intentar crear las mías propias.
Pero, ¡gracias de verdad por los bloques de construcción!
Siempre es una buena idea ejecutar primero un SELECT y asegurarte de que estás satisfecho con tu consulta antes de hacer un UPDATE . Además, siempre haz una copia de seguridad completa antes de empezar a hacer cambios masivos en la base de datos.
