# ¿Comando de Rails para promover masivamente a los usuarios a TL2?

**URL:** <https://meta.discourse.org/t/rails-command-to-mass-promote-users-to-tl2/149238>\
**Category:** Development\
**Tags:** rails-console\
**Created:** [25 Abril, 2020 08:07 UTC](https://meta.discourse.org/t/rails-command-to-mass-promote-users-to-tl2/149238 "2020-04-25T08:07:07Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![neounix](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/neounix/32/215617_2.png) [@neounix](https://meta.discourse.org/u/neounix)\
**Post date:** [25 Abril, 2020 10:23 UTC](https://meta.discourse.org/t/rails-command-to-mass-promote-users-to-tl2/149238/6 "2020-04-25T10:23:09Z")

</div>

> [@Queth](#):
>
> ¿Existe alguna manera de incluir algún criterio de fecha de registro? Por ejemplo, todos los 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**
>
> ```plaintext
> 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 🙂

---

_[View the full topic](https://meta.discourse.org/t/rails-command-to-mass-promote-users-to-tl2/149238)._