Is this related to the fact that the https://{defaultHost}/invites/link.json API stopped working today?
I’m not sure - it could be? I am not familiar with this endpoint.
Well, I have got a few hundreds emails from our automation now failing. We used the endpoint https://{defaultHost}/invites/link and we started getting 404. I check the documentation and the endpoint is now reported to be https://{defaultHost}/invites/link.json (with the extra .json), but also with that change I keep getting 404.
I am not sure how to fix that. We need to generate invite links to send them through our systems. It worked beautifully until today
Also, doing a PUT to that address return BAD REQUEST, but a PUT to an unexisting address returns NOT FOUND. I am not sure if this is an hint that the endpoint is there and it is just not working
Maybe I should specify that I have an instance of Discourse hosted by you at https://d.strumenta.community/
That API endpoint was moved to https://{defaultHost}/invites.json as we consolidated the email and link invites.
Ok, then I think the documentation is not up-to-date
Does this endpoint generates an invite link, but does not send an email?
Because according to the documentation the difference betweek /invites.json and and /invites/link.json is the sending of the email
Also, a post to /invites.json returns BAD REQUEST for me → my bad, I should use " and not '
With the correction, I get an answered telling the user was emailed, and I would like to prevent that:
It would be useful to have a notification when API changes and get access to the current documentation, otherwise stuff breaks all of a sudden and one cannot fix it…
Adding this here, just for visibility:
$ 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":[]}%
I will be updating our API documentation. Thank you for bringing that to my attention and sorry for the inconvenience.
It would be nice if create returned the existing invite link instead of throwing an error if it’s from the same user. The 422 error response is pretty generic, it took me ages to figure out why my tests were failing.
Added a PR for retrieving an existing invite by email address: FEATURE: Retrieve an existing link only invite by jessicah · Pull Request #12575 · discourse/discourse · GitHub
I found an undocumented flag skip_email that prevents the email being sent so you can just grab the link. Pass it in the body with the email and you should be good!
{
"email": "someone@test.com",
"skip_email": "true"
}
I did some brief testing and it’s worth noting that if you use it to generate an email link, then you can’t go back and use it to send an email automatically - emailed always returns false once skip_email is used.
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.
È probabile che sia solo una svista che manchi dalla documentazione dell’API, lavorerò per aggiungerlo.
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


