Rails command to mass promote users to TL2?

Hello, I am opening a new topic for this since I think my questions in a Previous topic about this have been looked over since I originally marked it as resolved, but it isn’t.

case: I migrated to discourse, and members of the old forum all have TL1, which they find not fair, so I wanted to bump them all to TL2 by changing the requirements. A lot of them are inactive because I had to deactivate the accounts prior to move.

I changed the TL2 requirements to postcount based only, and visited days 0.

After 10 days, only a handful users have been promoted, so it seems people have to login or post a reply in order for the TL2 check to happen. (Haven’t figured it out yet which one it is)

I wold love to be able to grant all former members of my forum TL2 status, so is there a way to run a command somewhere to do that? Something like going through all the users and promote them if they meet the new TL2 criteria.

Thank so much in advance for your help & your insights! :slight_smile:

2 Likes

Maybe:

users = User.where('admin = false')
users.update_all(trust_level: 2)
1 Like

This query will change all moderators to trust level 2 as well.

I’m not sure @Queth really wants to do that.

3 Likes

There is an Howto to bulk move all the users from a lower TL to an higher level (and viceversa)

8 Likes

Thank you so much for your fast replies!

@Canapin, @neounix

I don’t mind changing mods to tl2 temporarily, I can set their TL manually afterwards I think. I don’t think it would impact mod abilities? Would it?

@dax

Thank you! We are talking about 20k users, 10k are tl1 after migration, and the other 10k are 0, I would only want to promote the TL1 ones but I can with this query, right?

User.exec_sql("UPDATE users SET trust_level = 2 WHERE trust_level IN ( 1)")

Also another point is that there have in the meantime been signups of “real” new members who I don’t want to promote to TL2 without them earning it :wink:
Would there be a way to include some kind of registration date criteria? Eg all TL1 who registered before March 17 2020?

2 Likes

Yes @Queth Would you like me to post a copy of the structure of the users table so you can see all the different entries there?

Update: Here is it @Queth … you can see from the table description you have a lot of choices :slight_smile:

users table
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)

It’s always a good idea to SELECT first and make sure you are happy with your query before UPDATE :slight_smile: and always make a full backup before you start monkeying around with mass DB changes. Fat finger mistakes happen to even the best of the best. One of the main differences between an expert and a novice is the expert always makes a backup first :slight_smile:

3 Likes

Thank you @neounix!

Would it be possible to help me with the correct query? Because I don’t know how to do that… probably include somewhere

Where user created at < [march 17 2020 but then formatted correctly]
1 Like

I would love to; but some things are easier (and better) done by you doing a bit of your own homework. You have all the pieces of the puzzle, so my advise is to spend a bit of time and learn to write an SQL query. Honestly, this is just postgres SQL query 101 stuff that can be found on myriad tutorials online.

That’s not “my thing” to repeat “tutorial 101” kinds of things on info easily found by others doing their own Google homework. That’s just me. Thanks for understanding and please forgive me for my honesty…

Note: SQL has been around since 1974, or 46 years ago. It’s a good thing to have basic SQL knowledge if you are going to admin a DB based application.

3 Likes

Thanks :slight_smile:
Well I do have basic basic knowledge but writing queries from scratch is still something I rather copy paste from a trusted source instead of trying to devise my own.

But thank you indeed for the building blocks!

2 Likes

It’s always a good idea to SELECT first and make sure you are happy with your query before UPDATE :slight_smile: and always make a full backup before you start monkeying around with mass DB changes.

3 Likes