If one wanted to write a plugin specific to the Review Queue (new users)
Is there a few hints you guys can provide on the getting started side of things?
End goal I want to provide a 3rd option to new users from Delete, Delete and Block I want a 3rd Custom option that will do other things.
I have looked through the getting started with plugins topic and that’s’ all well and good just looking on pointers on how to hook into the Review Queue
This is an interesting use case and I’d like to help you get it working.
Actions for reviewable types are returned from the build_actions method.
What I’d recommend is having your plugin open the ReviewableUser class and alias the build_actions method. In your version, get the actions from the method you aliased, then add your new action to the delete bundle.
That should work, although you might end up with some hacky looking code. I’d suggest once you get it working to post it here and we can see if we can tidy it up, and perhaps add internal APIs to help out improve it further.
Robin,
Sto attualmente preparando una PR per il plugin Discord OAuth, principalmente per memorizzare più informazioni sugli utenti Discord in Discourse. Sto cercando di utilizzare il tuo modello ReviewableUser per mantenere la funzionalità che implementa l’approvazione automatizzata.
Poiché l’implementazione attualmente avvia una revisione per i nuovi utenti in modo asincrono, devo verificare se è stata creata una tale revisione e cancellarla.
Sfortunatamente sto ricevendo un errore Ruby molto strano e mi chiedevo se ti fossi imbattuto in qualcosa di simile.
Il codice è:
def after_create_account(user, auth)
super
data = auth[:extra_data]
if !user.approved && data[:auto_approve]
user.approved = true
user.approved_by_id = Discourse.system_user.id
if reviewable_user = ReviewableUser.find_by(target: user)
reviewable_user.set_approved_fields!(user, Discourse.system_user)
end
end
end
Non appena viene eseguito ReviewableUser.find_by, ottengo un’eccezione:
*** NameError Exception: wrong constant name #<Class:0x000056134e417870>::DiscordAuthenticator
Pensavo di aver fatto buoni progressi con Ruby, ma non sono chiaro sul motivo per cui stia accadendo questo.
È un problema di percorso? Ho provato un sacco di require, ma la situazione si complica.
È molto simile a pattern simili altrove nel codice principale. Qualsiasi idea è molto apprezzata!
Il repository è qui, se necessario: discourse-plugin-discord-auth/plugin.rb at master · merefield/discourse-plugin-discord-auth · GitHub
Quell’errore costante non è molto informativo, vero! Credo che abbia a che fare con gli engine di Rails e i namespace. Una cosa rapida che potresti provare è ::ReviewableUser con i due punti prima. Questo gli dice di utilizzare il namespace radice, non quello dell’engine.
Questo codice sembra anche un po’ obsoleto per l’API reviewable. Dovrebbe essere qualcosa del genere:
if !user.approved && data[:auto_approve] && reviewable = ::ReviewableUser.pending.find_by(target: user)
reviewable.perform(:approve, Discourse.system_user)
end
Quello ha risolto l’errore. Immagino che, non riuscendo a trovare la Classe in precedenza, la stesse trattando come una Constant? In ogni caso, il problema è risolto, ottimo, grazie mille! Sono sbloccato!
Quindi il motivo per cui avevo questo:
user.approved = true
user.approved_by_id = Discourse.system_user.id
prima di:
reviewable.perform(:approve, Discourse.system_user)
è che l’aggiunta alla coda di revisione è asincrona. Nel job, la revisione viene creata solo se approve è falso da (discourse/app/jobs/regular/create_user_reviewable.rb at 888e68a1637ca784a7bf51a6bbb524dcf7413b13 · discourse/discourse · GitHub):
if user = User.find_by(id: args[:user_id])
return if user.approved?
@reviewable = ReviewableUser.needs_review!(
target: user,
created_by: Discourse.system_user,
reviewable_by_moderator: true,
payload: {
username: user.username,
name: user.name,
email: user.email
}
)
C’è il rischio che il job venga eseguito dopo che hai già verificato l’esistenza della voce di revisione?
Il risultato è che la voce di revisione sembra non esistere, ma il job è semplicemente in attesa di essere eseguito. Il job viene poi eseguito e crea la voce di revisione, e tu hai perso l’opportunità di eliminarla perché il tuo codice di test è già stato eseguito.
È una potenziale condizione di gara?
Imposta approved su true prima di verificare l’esistenza di una voce di revisione e avrai risolto il problema (poiché una revisione non verrà mai creata dopo questo, in quanto è una dipendenza).
Ho incontrato questo problema testando il mio codice: in dev funzionava, ma in produzione ha fallito perché le cose venivano eseguite in un ordine diverso.
NB: Apprezzo che tu non abbia scritto questo per supportare questo caso d’uso, ma ritengo importante permettere ai plugin di poter approvare automaticamente i nuovi utenti in circostanze speciali (ad esempio, come fa il plugin di Discord, che lo fa se l’utente è membro di una gilda affidabile).
Infatti, il record revocabile viene creato in modo asincrono e ciò risulta problematico in questa situazione, poiché l’accesso crea l’utente e il record di approvazione potrebbe non essere ancora presente.
Una soluzione migliore sarebbe non creare il record revocabile in questa situazione; tuttavia, ciò richiederebbe modifiche al core per funzionare correttamente. Potrebbe funzionare in questo modo:
skip_approval: true.Grazie Robin, sì.
Per ora ho adottato la mia soluzione temporanea, consapevole del fatto che dovrà essere risolta prima che venga rimossa l’accesso diretto all’API.
C’è da parte del Team la volontà di dare priorità a questo prima che venga rimosso l’accesso di scrittura diretto per user.approve?
Credo che tale modifica interromperà la funzionalità attuale di auto-approvazione delle Guild fidate nel plugin Auth Discord Login (anche senza la PR che ho appena aperto per quel plugin). @featheredtoast
Sarei felice di aggiornare la mia PR per supportare tale modifica, se verrà implementata.
Non credo che lo rimuoveremo a breve. Non voglio dipendere da esso per sempre, ma dovrebbe andare bene per un po’ di tempo.
La coda è comoda e anche la funzione ‘raggruppa per argomento’ è utile.
Tuttavia, per quanto ne so, non esiste un modo per selezionare ed elaborare i post in blocco. Ogni post deve essere elaborato singolarmente.
La selezione e l’elaborazione in blocco sarebbero un vero risparmio di tempo!
Penso che sarebbe un ottimo miglioramento. Per essere onesti, la coda dei flag non ha mai avuto operazioni in batch, quindi non è come se questo fosse un regresso.
Inoltre, alcune operazioni come “Sospendi” sono un po’ strane quando si lavorano più righe. Dovrebbero essere limitate alle operazioni di base per avere senso.
Ho trovato un piccolo problema: qualcuno ha pubblicato in una categoria che richiede approvazione, quindi l’articolo appare nella coda di revisione. Hanno pubblicato nella categoria sbagliata, quindi ho provato a spostarlo dalla coda di revisione senza problemi, tranne che la categoria in cui vorrei spostarlo richiede un tag specifico. Tuttavia, quel tag è riservato alla nuova categoria, mentre l’articolo in coda di revisione è ancora considerato parte della categoria originale, che non consente quel tag. Quindi mi trovo bloccato. Sarebbe abbastanza semplice approvare l’articolo e modificarlo dopo, ma sembra qualcosa che dovrebbe essere corretto.
So che questo dovrebbe essere risolto, ma gli URL non vengono ancora aggiunti all’elenco monitorato. Probabilmente non fa nemmeno molta differenza, dato che l’azione per gli URL monitorati è comunque
Per confermare, hai aggiornato alla versione corretta? Dovrebbero essere filtrati se non sono in grado di essere onebox o interni.
Sì, sono su v2.4.0.beta2 +66. La prossima volta che succede, farò una copia del post.
Sì, dopo aver cliccato su “Elimina utente” nella coda di revisione, l’indirizzo email e l’indirizzo IP sono stati aggiunti alle liste di controllo, ma non gli URL. Il post era:
Desideri un [Servizio di scrittura accademica](https://myassignmenthelp.com/uk/academic-writing-service.html) online presso il fornitore di servizi di scrittura accademica n. 1 al mondo, Myassignmenthelp.com. Servizio professionale di scrittura accademica che offre un'ampia gamma di opzioni per gli studenti al miglior prezzo.
Per quanto mi ricordi, gli URL non sono mai stati aggiunti automaticamente alla lista filtrata? Beh, suppongo di sì, ho controllato la mia istanza e ci sono un sacco di URL lì dentro 
Ah sì, mi sono ricordato. In realtà non fanno nulla, sono solo informativi.
Puoi aggiungere quei nomi di dominio alle parole monitorate in modo che non possano essere inseriti, ma dovrai farlo tu stesso.
È per questo che sarebbe utile se venissero aggiunti all’elenco filtrato: anche se non viene intrapresa alcuna azione automatica sugli URL, ci permetterebbe di vedere quali spam vengono pubblicati. Tieni presente che i moderatori possono utilizzare la coda di revisione, ma non possono (credo) aggiungere parole monitorate.
Alcuni piccoli feedback sull’esperienza utente: sarebbe fantastico se la coda di revisione ricordasse le mie impostazioni. Dato che lavoriamo con un team di moderatori, sono personalmente interessato principalmente a vedere le nuove segnalazioni e le ordino per “Data di creazione”, ma questa impostazione non viene “memorizzata”.
Non è una cattiva idea. Per fortuna, al momento esiste una soluzione alternativa: i filtri di ricerca vengono salvati nella stringa di query (URL). Se aggiungi un filtro ai preferiti, potrai sempre tornarci.
