Per favore, valuta uno script Ruby breve per sospendere utenti inattivi

[TonyG]

Questo è il mio primo script Ruby personalizzato in assoluto. In quasi 50 anni di programmazione con oltre 20 linguaggi e dialetti, non ho mai avuto bisogno (o voluto ) scrivere in Ruby, ma OK, mi hai convinto… per favore, sii gentile.

Il mio obiettivo è identificare gli account utente che non sono stati autenticati tramite link via email e sospendere gli account in modo da poterli controllare prima dell’eliminazione. Durante la configurazione iniziale, ho avuto impostazioni in varie fasi di sviluppo. Le email 2FA non sono state inviate per alcune registrazioni, e ci sono state molte registrazioni fasulle che ora vorrei filtrare.

Versione 0.0.1

rails c

# Prima assicurati che i TL utente siano conformi alle ultime definizioni
User.all.find_each do |user|
  Promotion.recalculate(user)
end
Group.ensure_consistency!

# Preparazione per il ciclo
logger = StaffActionLogger.new(User.where("id = 'admin'"))
# data temporanea, gli utenti verranno rimossi prima di questa data
suspend_till = DateTime.new(2028, 12, 31)
suspend_at = DateTime.now
reason = 'Inactive'

# Identifica account potenzialmente inattivi
User.where("views = 0 OR approved = FALSE OR last_seen_at IS NULL")
    .where("id > 0")
    .find_each do |user|
  user.suspended_till = suspend_till
  user.suspended_at = suspend_at
  user.change_trust_level!(TrustLevel[0])
  # salva l'utente, registra l'azione e... fai quello che si fa per questo trigger
  user.save!
  logger.log_user_suspend(user, reason)
  DiscourseEvent.trigger(:user_suspended, user: user)
  # evita di abusare del server di posta
  sleep(10)
end

Innescando l’evento, vorrei che venissero inviate email agli utenti - ci saranno molti rimbalzi, e potrebbero esserci alcune persone che torneranno per autenticarsi. Dopo una settimana selezionerò tutti gli account ancora sospesi e li eliminerò.

Domande:

1. In generale, questo farà ciò che è previsto?
2. Esiste un approccio migliore?
3. La registrazione è ridondante con l’innesco dell’evento?
4. Possiamo farlo con JavaScript?
5. Dovrei pubblicare questo in un’altra categoria?
6. Qualche altro consiglio?

Grazie!!

[TonyG]

Hmm, guardando questo, penso che dovrei silenziare un account piuttosto che sospenderlo. Se l’account è sospeso, l’utente non può accedere per rivendicarlo.

Ecco una revisione…

Versione 0.0.2

silence_reason = 'Inattivo'
User.where("views = 0 OR approved = FALSE OR last_seen_at IS NULL")
    .where("id > 0") # evita gli utenti di sistema
    .find_each do |user|
  user.silence(reason: silence_reason)
  user.change_trust_level!(TrustLevel[0])
  user.save!
  logger.log_user_silence(user, silence_reason)
  DiscourseEvent.trigger(:user_silenced, user: user)
  sleep(5)
end

Sì, eseguirò un backup prima di fare qualsiasi cosa.
Sì, so che alcuni TL esistenti verranno mescolati e dovrò correggerli.

Inoltre, invece di silenziare, dovrei impostare Approved=false o Active=false? Credo che ciò costringerà l’utente a fare clic sul link dell’email piuttosto che farlo manualmente, il che serve allo scopo di convalidare l’indirizzo email.

Tutto questo è correlato al mio recente thread: notes-on-silencing-or-deleting-users

[EDIT]
Ho anche impostato “purge unactivated users grace period days” a 7.
Un silenzio o una sospensione resettano questo? Se sì, se le persone non rispondono a un’azione dell’account entro 7 giorni, non ho problemi a eliminarle.

Infine (sì, davvero) ho anche impostato “clean up inactive users after days” a 365. Posso impostarlo a 60 mentre il forum si sta ancora aprendo e semplicemente lasciare che gli account esistenti escano dalla lista. Poi aumentarlo di nuovo a 365. È un approccio ragionevole per la potatura automatica degli account in un nuovo ambiente?

[pfaffman (Jay Pfaffman)]

@TonyG

Ho anche impostato “purge unactivated users grace period days” a 7.

Perché non è sufficiente a risolvere il tuo problema?

@TonyG

User.where("views = 0 OR approved = FALSE OR

Non dovrebbero essere AND invece di OR?

@TonyG

che serve allo scopo di convalidare l’indirizzo email.

Discourse li impone per convalidare gli indirizzi, quindi non mi è molto chiaro quale problema tu stia risolvendo. Dici questo

@TonyG

Vorrei che le email venissero inviate agli utenti - ci saranno molti rimbalzi e potrebbero esserci alcune persone che torneranno per autenticarsi.

Sembra piuttosto improbabile che tu riesca a trovare utenti che volevano accedere ma non potevano prima, ma potresti sapere qualcosa che io non so sulla tua configurazione.

E discourse non invierà email ad indirizzi non convalidati, quindi non credo che questo invierà alcuna email.

Faccio sempre queste cose su alcuni account ma a mano per vedere cosa succederà.

[TonyG]

Grazie per il tuo interesse, @pfaffman!

@TonyG

Ho anche impostato “purge unactivated users grace period days” a 7.

@pfaffman

Perché non è sufficiente a risolvere il tuo problema?

Ci sono record utente senza last_seen_at, creati mesi fa, approved=False, active=False, e non vengono eliminati.
Ci sono record utente con last_seen_at > 7 giorni (vecchi di mesi) e 0 visualizzazioni, e non vengono eliminati.

Qualunque sia il criterio utilizzato con questo flag di periodo di grazia, non seleziona questi record.
Qualcuno può pubblicare la query esatta che viene utilizzata in modo che io possa capire quali altri fattori sono coinvolti?

@TonyG

User.where("views = 0 OR approved = FALSE OR last_seen_at IS NULL")

@pfaffman

Non dovrebbero essere AND invece di OR?

No, guardando direttamente il DB ci sono record utente che soddisfano ciascun criterio ma non tutti. Sembra che la tabella utenti nel database sia incoerente. Ci sono record con topics_entered o posts_read_count non nulli, ma con views=0. Ci sono record con topics_entered=0 e posts_read_count=0, ma views è non nullo.

Il punto chiave da ricordare è che mentre questo sito veniva sviluppato le impostazioni non erano ottimali e si registravano umani e bot. La clausola OR sembra catturare tutti questi. Ora che il sito è stabilizzato con (spero) impostazioni sensate, non mi aspetto che le nuove registrazioni producano le stesse anomalie.

Ho intenzione di eseguire lo script molte volte con criteri diversi. Interrogherò prima i record, al di fuori dell’ambiente, e poi eseguirò lo script di silenziamento per indirizzare solo i record che voglio veramente. Tra un paio di settimane farò un’ultima esecuzione, selezionerò solo i record silenziati (a chiunque sia effettivamente tornato verrà rimosso il flag) e li eliminerò tutti:

UserDestroyer.new(admin_user).destroy(user, reassign_to: archive_user)

La mia domanda generale è se lo script v0.0.2, con il suo approccio alla selezione, alla registrazione e al silenziamento, sia corretto per un sistema Discourse. Non so se ci sia qualcos’altro da fare in un ciclo come questo. Non ho mai creato ed eseguito il mio script, quindi questa è una richiesta di controllo per errori da principiante.

Grazie!!