Isso está relacionado ao fato de que a API https://{defaultHost}/invites/link.json parou de funcionar hoje?
1 curtida
Não tenho certeza — pode ser? Não estou familiarizado com esse endpoint.
Bem, recebi algumas centenas de e-mails de nossa automação relatando falhas. Usávamos o endpoint https://{defaultHost}/invites/link e começamos a receber erros 404. Verifiquei a documentação e o endpoint agora é informado como https://{defaultHost}/invites/link.json (com o .json extra), mas mesmo com essa alteração, continuo recebendo 404.
Não tenho certeza de como corrigir isso. Precisamos gerar links de convite para enviá-los por meio de nossos sistemas. Funcionava perfeitamente até hoje.
Além disso, fazer um PUT para aquele endereço retorna BAD REQUEST, mas um PUT para um endereço inexistente retorna NOT FOUND. Não tenho certeza se isso é uma pista de que o endpoint existe e apenas não está funcionando.
Talvez eu devesse especificar que tenho uma instância do Discourse hospedada por vocês em https://d.strumenta.community/
Esse endpoint da API foi movido para https://{defaultHost}/invites.json, pois consolidamos os convites por e-mail e por link.
2 curtidas
Ok, então acho que a documentação não está atualizada
Esse endpoint gera um link de convite, mas não envia um e-mail?
Porque, de acordo com a documentação, a diferença entre /invites.json e /invites/link.json é o envio do e-mail.
1 curtida
Além disso, uma postagem para /invites.json retorna BAD REQUEST para mim - > minha culpa, eu deveria usar " e não ’
Com a correção, recebo uma resposta informando que o usuário foi notificado por e-mail, e gostaria de evitar isso:
Seria útil ter uma notificação quando houver mudanças na API e acesso à documentação atual, caso contrário as coisas quebram de repente e não é possível corrigi-las…
Adicionando isso aqui, apenas para visibilidade:
$ 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":[]}%
Vou atualizar nossa documentação da API. Obrigado por chamar minha atenção para isso e desculpe pelo inconveniente.
7 curtidas
Seria bom se create retornasse o link de convite existente em vez de lançar um erro, caso ele seja do mesmo usuário. A resposta de erro 422 é bastante genérica; levei uma eternidade para descobrir por que meus testes estavam falhando.
1 curtida
Adicionei um PR para recuperar um convite existente por endereço de e-mail: FEATURE: Retrieve an existing link only invite by jessicah · Pull Request #12575 · discourse/discourse · GitHub
1 curtida
Encontrei um flag não documentado skip_email que impede o envio do e-mail, permitindo que você apenas obtenha o link. Passe-o no corpo junto com o e-mail e você estará pronto!
{
"email": "someone@test.com",
"skip_email": "true"
}
Fiz alguns testes rápidos e vale ressaltar que, se você usá-lo para gerar um link de e-mail, não poderá voltar e usá-lo para enviar um e-mail automaticamente — emailed sempre retorna falso após o uso de skip_email.
1 curtida
Existe algum motivo pelo qual invites/retrieve não está na documentação em Discourse API Docs? Ou estou perdendo alguma coisa.
Eu quero convidar endereços de e-mail que existem em um banco de dados externo, somente se a) eles ainda não tiverem uma conta, e b) se eles ainda não foram convidados (este processo será executado periodicamente e eu não quero sobrecarregar as pessoas que não responderam ao convite rápido o suficiente). invites/retrieve.json parece ser a maneira certa de descobrir b) pelo que parece estar no commit.
2 curtidas
É provável que seja apenas uma omissão que está faltando na documentação da API, vou trabalhar para adicioná-la.
3 curtidas
Seria ótimo se eles fossem gerados por, ou pelo menos testados contra, o discourse core atual.
Pareceria que haveria uma maneira razoavelmente simples (o que provavelmente significa 2 dias de trabalho e não a 1 hora que eu gostaria de acreditar!) de fazer com que as especificações fossem executadas para testá-los. Ah, ou talvez seja para isso que serve https://redocly.com/?
O que seria realmente bom para o meu caso de uso é uma maneira de recuperar todos os convites convidados por todos os usuários. Se “por todos os usuários” for o ponto de interrupção, seria bom para o meu caso de uso recuperar todos os convites (independentemente do estado).
Com este método, sou forçado a sondar cada possibilidade, o que pode ser 1000 endereços de e-mail quando provavelmente há apenas alguns na tabela.
How to get a password from database? - #3 by pfaffman indica que o banco de dados não é exposto por padrão, então usar código para acessar o banco de dados a partir de um processo externo não é viável diretamente, pelo menos não com minha implementação atual – e talvez não fosse uma boa ideia expor a porta do banco de dados em qualquer caso.
Estou tentando automatizar convites e associação de grupos para endereços de e-mail em um banco de dados externo.
E duas vezes referiu-se ao plugin data explorer (explorador de dados), que também é a resposta aqui, mas talvez você precise saber que pode Run Data Explorer queries with the Discourse API
ah sim, esse era o ponto chave que eu estava perdendo – obrigado pela dica
1 curtida