È questo correlato al fatto che l’API https://{defaultHost}/invites/link.json ha smesso di funzionare oggi?
1 Mi Piace
Non sono sicuro – potrebbe essere? Non conosco questo endpoint.
Beh, ora stiamo ricevendo alcune centinaia di email di fallimento dalla nostra automazione. Utilizzavamo l’endpoint https://{defaultHost}/invites/link e abbiamo iniziato a ricevere errori 404. Ho controllato la documentazione e l’endpoint è ora indicato come https://{defaultHost}/invites/link.json (con l’aggiunta di .json), ma anche con questa modifica continuo a ricevere errori 404.
Non sono sicuro di come risolvere il problema. Dobbiamo generare link di invito da inviare tramite i nostri sistemi. Funzionava perfettamente fino a oggi.
Inoltre, inviare una richiesta PUT a quell’indirizzo restituisce BAD REQUEST, mentre una PUT a un indirizzo inesistente restituisce NOT FOUND. Non sono sicuro se questo indichi che l’endpoint esiste ma semplicemente non funziona.
Forse dovrei specificare che ho un’istanza di Discourse ospitata da voi su https://d.strumenta.community/
Quel endpoint API è stato spostato su https://{defaultHost}/invites.json poiché abbiamo consolidato gli inviti via email e quelli tramite link.
2 Mi Piace
Ok, allora penso che la documentazione non sia aggiornata
Questo endpoint genera un link di invito, ma non invia un’email?
Perché secondo la documentazione, la differenza tra /invites.json e /invites/link.json è l’invio dell’email.
1 Mi Piace
Inoltre, una richiesta POST a /invites.json restituisce BAD REQUEST per me → mia colpa, avrei dovuto usare " invece di '**
Con la correzione, ricevo una risposta che indica che l’utente è stato contattato via email, e vorrei evitare questo:
Sarebbe utile ricevere una notifica quando ci sono modifiche all’API e avere accesso alla documentazione aggiornata; altrimenti le cose si rompono all’improvviso e non è possibile intervenire…
Aggiungo questo qui, solo per visibilità:
$ curl 'http://localhost:3000/invites.json' -X 'POST' \
-H "Api-Key: d5fc02c5f4efaafacc82e4ff3410ae283d1c5da68ac43430d5133aaf4785593f" \
-H "Api-Username: dan" \
-H "Content-Type: application/json" \
-d "{\"max_redemptions_allowed\":5}"
{"id":18,"link":"http://localhost:3000/invites/6f524dba4ced35ecae709a8614db3b05","redemption_count":0,"max_redemptions_allowed":5,"custom_message":null,"updated_at":"2021-03-10T15:44:44.259Z","expires_at":"2021-04-09T15:44:44.258Z","expired":false,"topics":[],"groups":[]}%
Agiornerò la nostra documentazione API. Grazie per avermelo segnalato e scusa per l’inconveniente.
7 Mi Piace
Sarebbe bello se create restituisse il link di invito esistente invece di generare un errore, se proviene dallo stesso utente. La risposta di errore 422 è piuttosto generica: ci ho messo un sacco di tempo a capire perché i miei test fallivano.
1 Mi Piace
Aggiunta una PR per il recupero di un invito esistente tramite indirizzo email: FEATURE: Retrieve an existing link only invite by jessicah · Pull Request #12575 · discourse/discourse · GitHub
1 Mi Piace
Ho trovato un flag non documentato skip_email che impedisce l’invio dell’email, così puoi semplicemente prendere il link. Passalo nel corpo insieme all’email e dovresti essere a posto!
{
"email": "someone@test.com",
"skip_email": "true"
}
Ho effettuato alcuni test rapidi e vale la pena notare che se lo usi per generare un link per email, non potrai più tornare indietro e utilizzarlo per inviare un’email automaticamente: emailed restituisce sempre false una volta utilizzato skip_email.
1 Mi Piace
C’è qualche motivo per cui invites/retrieve non è nella documentazione sotto Discourse API Docs? O mi sto perdendo qualcosa.
Voglio invitare indirizzi email che esistono in un database esterno, solo se a) non hanno già un account e b) se non sono già stati invitati (questo processo verrà eseguito periodicamente e non voglio spammare le persone che non hanno risposto al loro invito abbastanza velocemente). invites/retrieve.json sembra essere il modo giusto per verificare b) in base a ciò che sembra essere nel commit.
2 Mi Piace
È probabile che sia solo una svista che manchi dalla documentazione dell’API, lavorerò per aggiungerlo.
3 Mi Piace
Sarebbe bello se fossero generati da, o almeno testati contro, l’attuale core di Discourse.
Sembrerebbe esserci un modo abbastanza semplice (il che probabilmente significa 2 giorni di lavoro e non l’ora che vorrei credere!) per far sì che le specifiche vengano eseguite per testarli. Oh, o forse è quello che dovrebbe fare https://redocly.com/?
Quello che sarebbe davvero utile per il mio caso d’uso è un modo per recuperare tutti gli inviti inviati da tutti gli utenti. Se “da tutti gli utenti” è il punto critico, andrebbe bene per il mio caso d’uso recuperare tutti gli inviti (indipendentemente dallo stato).
Con questo metodo sono costretto a interrogare ogni possibilità, che potrebbero essere 1000 indirizzi email quando probabilmente ce ne sono solo pochi nella tabella.
How to get a password from database? - #3 by pfaffman indica che il database non è esposto di default, quindi usare il codice per accedere al db da un processo esterno non è fattibile direttamente, almeno non con la mia implementazione attuale – e forse non sarebbe una buona idea esporre la porta del db in ogni caso.
Sto cercando di automatizzare gli inviti e l’appartenenza ai gruppi per gli indirizzi email in un database esterno.
E due volte ha fatto riferimento al plugin data explorer, che è anche la risposta qui, ma forse devi sapere che puoi Run Data Explorer queries with the Discourse API
ah sì, questo era il punto chiave che mi mancava – grazie per il suggerimento
1 Mi Piace