Ciao, sto aprendo un nuovo argomento per questo, poiché penso che le mie domande in un argomento precedente su questo siano state trascurate, dato che l’avevo originariamente contrassegnato come risolto, ma non lo è.
Caso: ho migrato a Discourse e tutti i membri del vecchio forum hanno il livello TL1, cosa che ritengono ingiusta, quindi volevo promuoverli tutti a TL2 modificando i requisiti. Molti di loro sono inattivi perché ho dovuto disattivare i loro account prima della migrazione.
Ho modificato i requisiti per TL2 basandomi solo sul numero di post e ho impostato i giorni di accesso a 0.
Dopo 10 giorni, solo una manciata di utenti è stata promossa, quindi sembra che gli utenti debbano accedere o rispondere a un post affinché venga eseguita la verifica per TL2. (Non ho ancora capito quale delle due condizioni sia necessaria).
Mi piacerebbe molto poter concedere lo status TL2 a tutti i vecchi membri del mio forum; esiste quindi un modo per eseguire un comando da qualche parte per farlo? Qualcosa come scorrere tutti gli utenti e promuoverli se soddisfano i nuovi criteri TL2.
Grazie mille in anticipo per il vostro aiuto e le vostre riflessioni!
Non mi dispiace cambiare i mod a tl2 temporaneamente; penso di poter impostare manualmente il loro TL in seguito. Non credo che ciò influisca sulle capacità dei mod, vero? Sarebbe?
Grazie! Stiamo parlando di 20.000 utenti: 10.000 sono tl1 dopo la migrazione e gli altri 10.000 hanno livello 0. Vorrei promuovere solo quelli con TL1, ma posso farlo con questa query, giusto?
User.exec_sql("UPDATE users SET trust_level = 2 WHERE trust_level IN ( 1)")
Un altro punto è che nel frattempo ci sono state nuove iscrizioni di membri “veri” che non vorrei promuovere a TL2 senza che se lo siano guadagnati
Esiste un modo per includere qualche criterio relativo alla data di registrazione? Ad esempio, tutti quelli con TL1 registrati prima del 17 marzo 2020?
Sì, @Queth. Vorresti che pubblicassi una copia della struttura della tabella users, così da poter vedere tutte le diverse voci presenti?
Aggiornamento: Eccola qui, @Queth… dalla descrizione della tabella puoi vedere che hai molte opzioni da scegliere
tabella 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)
È sempre una buona idea eseguire prima un SELECT e assicurarsi che la query sia corretta prima di procedere con un UPDATE Inoltre, fai sempre un backup completo prima di iniziare a fare modifiche di massa al database. Anche i migliori possono commettere errori di distrazione. Una delle differenze principali tra un esperto e un principiante è che l’esperto fa sempre un backup prima
Mi farebbe molto piacere, ma alcune cose sono più semplici (e migliori) se fai un po’ di ricerche da solo. Hai tutti i pezzi del puzzle, quindi il mio consiglio è di dedicare un po’ di tempo e imparare a scrivere una query SQL. Onestamente, si tratta di concetti base di PostgreSQL SQL che si trovano in innumerevoli tutorial online.
Non è “il mio genere” ripetere cose tipo “corso base 101” su informazioni facilmente reperibili da chiunque faccia le proprie ricerche su Google. È solo il mio modo di essere. Grazie per la comprensione e perdonami per la mia onestà.
Nota: SQL esiste dal 1974, ovvero da 46 anni. È utile avere conoscenze di base su SQL se devi amministrare un’applicazione basata su database.
Grazie
Beh, ho delle conoscenze di base, ma scrivere query da zero è ancora qualcosa che preferisco copiare e incollare da una fonte affidabile piuttosto che cercare di elaborarle da solo.
È sempre una buona idea eseguire prima una SELECT e assicurarsi di essere soddisfatti della propria query prima di fare UPDATE , e fare sempre un backup completo prima di iniziare a fare esperimenti con modifiche di massa al database.
