Nova funcionalidade de prompt 'aceitar convite' causando problemas com links de convite

Suporte
1

Temos usado links de convite para ajudar nossos usuários a migrar entre plataformas e para o discourse; no entanto, o novo prompt que começou a aparecer com a última atualização do discourse está causando atrasos e confusão.

Usuários que usam um link de convite que redireciona para uma postagem de tópico não conseguem usar o link apenas uma vez, o que é um grande problema se esperamos que eles usem o link toda vez que quiserem visitar a postagem de tópico. É importante que possamos redirecionar os usuários usando o mesmo link de convite quantas vezes o usuário desejar revisitar o tópico e ter esse recurso bloqueado pelo novo prompt está causando um problema.

Outros problemas técnicos também apareceram. Primeiro, leva pelo menos cinco segundos para o ‘aceitar convite’ responder ao clique e, em seguida, leva algum tempo para redirecionar o usuário ao tópico. Segundo, com essa nova adição, está levando mais tempo para carregar o prompt primeiro. Terceiro, mesmo que você tenha clicado no link de convite antes e aceitado o convite, ele continuará a perguntar toda vez que você clicar no link!

Para reproduzir este problema, crie um link de convite que redirecione os usuários para uma postagem de tópico e/ou os adicione a um grupo. Clique no link de redirecionamento enquanto estiver logado na conta do discourse.

Por favor, existe alguma maneira de desativar este prompt nas configurações? Isso é urgente e importante porque para nós afetará a experiência do usuário.

Isso também pode passar despercebido por outros que podem estar contando com links de convite, mas não estão cientes dessa nova mudança porque não houve notificação sobre essa mudança, obrigado!

2 curtidas
3

Gostaria de acrescentar que há um bug aqui também e, no nosso caso de uso, não precisamos do prompt em primeiro lugar, então seria possível removê-lo? ou ter a opção nas configurações de Administrador para desativá-lo?

O bug é que, se você clicar em ‘Aceitar convite’ pela segunda vez, a página permanecerá estática e não mostrará nenhuma mensagem. Isso não é nada útil. Bloqueia o usuário de usar o contexto anterior para ser redirecionado novamente para o tópico. Este é um problema grave. Se eu colocar um link de convite em um documento e esperar que o leitor possa usar o mesmo link repetidamente para ser redirecionado para o tópico, o link de convite não funcionará mais. :sob:

Usamos links de convite porque o participante precisa ser adicionado a uma categoria privada primeiro para poder ler o tópico. Se o usuário precisar encontrar o tópico novamente, ele deverá ser capaz de usar o mesmo link de convite. Neste caso, ele deve aceitar automaticamente o convite se o usuário estiver logado, pois o convite é destinado a esse usuário e, como funcionou bem anteriormente, deve redirecionar o usuário para a postagem do tópico pretendido.

Os links de convite funcionaram perfeitamente antes. Espero que você possa dar uma segunda olhada nisso e dar ao administrador a opção de desativar este prompt/mensagem de botão ‘Aceitar Convite’. Obrigado!

image
image1778×454 135 KB

4 curtidas
4

Obrigado pelo seu relatório @gassim.

Não consigo reproduzir este atraso de 5 segundos. Testei aqui no meta com vários convites, tanto com quanto sem adicionar a um grupo. Se você vir este atraso todas as vezes, pode tentar da próxima vez com as ferramentas de desenvolvedor abertas na aba do console e ver se há algum erro relatado lá?

Consigo reproduzir este, parece que há uma regressão aqui, corrigiremos isso em breve.

5 curtidas
5

Aqui estão as evidências do atraso de 5 segundos no console do Firefox.

Screenshot 2022-11-11 at 11.04.50
Screenshot 2022-11-11 at 11.04.501560×330 65.2 KB

Não consigo ver nenhum erro no console do Firefox, mas quando tento no Chrome, às vezes recebo estes erros.

includes.js?v=35a79b300ab5afa978cb59af0b05e059:839

PUT https://XXX/invites/show/XXX.json 502
XMLHttpRequest.send @ includes.js?v=35a79b300ab5afa978cb59af0b05e059:839
send @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:495
ajax @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:471
y @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4309
O @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4309
f @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948
submit @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:2926
B._run @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4450
B._join @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4449
B.join @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4412
p @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2577
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:725
a @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2481
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:725
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:719
_triggerAction @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:532
click @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:531
trigger @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2235
r @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2092
trigger @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:4230
r @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2092
a @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:4234

discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3940

SyntaxError: Unexpected token '<', "<html>
<h"... is not valid JSON
    at Function.parse [as parseJSON] (<anonymous>)
    at i (discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3940:167)
    at discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:2926:699
    at b (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4291:12)
    at g (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4289:128)
    at h (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4287:107)
    at p.invoke (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4377:192)
    at p.flush (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4369:141)
    at h.flush (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4384:207)
    at B._end (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4448:9)
    at B.end (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4401:240)
    at B._run (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4450:118)
    at B.run (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4410:13)
    at d (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2577:23)
    at u.error (discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948:44)
    at l (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:200:118)
    at Object.fireWith [as rejectWith] (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:201:698)
    at E (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:483:468)
    at XMLHttpRequest.<anonymous> (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:494:206)
2 curtidas
6

Obrigado pela ajuda @pmusaraj!

Por favor, a mensagem de prompt não é útil em nosso caso de uso. Existe uma maneira para o administrador criar links de convite sem esse tipo de prompt?

Os links de convite são usados em um curso onde os participantes são convidados a participar dos fóruns de discussão. Tudo o que queremos que o link de convite faça é adicionar o usuário a um grupo e redirecionar o usuário para um tópico em uma categoria privada (sem ter que clicar em ‘aceitar convite’ toda vez que eles usam um link), e após o primeiro clique, espera-se que os usuários possam retornar ao tópico usando o mesmo link de convite. Isso tem funcionado de forma suave e perfeita até que a mensagem de prompt foi imposta durante a noite.

Expliquei como estamos usando os links de convite em outro tópico

@tobiaseigen @dan @JammyDodger, por favor, me ajudem com isso. Precisamos ser capazes de nos livrar da mensagem de prompt em nosso caso de uso.

7

Obrigado @yanokwa! (:

9

Olá @gassim, discutimos isso internamente. Desculpe, mas o comportamento de aceitar o mesmo convite várias vezes como o mesmo usuário para atuar como um marcador é inesperado, e corrigiremos isso para ocultar o botão “Aceitar Convite” se o usuário logado já tiver aceitado o convite. Em vez disso, exibiremos uma mensagem informando ao usuário que ele já reivindicou o link do convite.

A aceitação automática de um convite ao abrir a página era um problema de segurança, por isso mudamos para ter a página intermediária “Aceitar Convite” em vez disso.

Se for necessário que o usuário retorne ao mesmo tópico, sugerimos que ele o marque. Ou, se você tiver algum documento interno onde colocou o link do convite, adicione um link para o tópico no mesmo local para conveniência.

4 curtidas
10

Olá @martin, obrigado a você e à equipe do Discourse pela consideração. Estamos discutindo soluções alternativas no momento.

Sim, por favor, e ficaremos felizes em saber quando este bug for corrigido.

Entendido… Eu esperava que os administradores tivessem a opção durante a criação do link do convite de escolher se a mensagem de prompt seria usada ou não (talvez com um aviso do que poderia acontecer se eles não usassem a mensagem de prompt). Estamos cientes de que, sem a mensagem de prompt, qualquer pessoa poderia acessar o grupo/categoria privada, mas em nosso caso de uso isso não é um problema, pois não são grupos/categorias ‘secretos’, são privados para serem mantidos separados como espaços dedicados para discussão de tópicos de cursos.

Não é fácil exigir que os participantes do curso marquem o tópico, mas a última sugestão parece ser nossa única opção agora e a ação imediata que poderíamos tomar para corrigir o problema.

E parece que também estamos enfrentando este problema agora: No 'sign in' option in the accept invitation page, only the signup form is shown, obrigado!

Mais uma vez, obrigado a você e à sua equipe por todo o trabalho e suporte. :+1:

2 curtidas
11

Ah, essa é uma restrição interessante. Então você tem um Discourse com 1000 salas que qualquer um pode acessar, mas você quer que os membros do curso tenham uma forte afinidade com a sala em particular.

Algumas perguntas:

  • Qual o valor em não usar segurança aqui? O latest é apenas uma quantidade enorme de ruído para o usuário típico? Também temos uma configuração “por padrão, todas as categorias são suprimidas do latest” que pode ser interessante.

  • A barra lateral pode aliviar um pouco a dor? Se você tiver a categoria na sua barra lateral, pelo menos ela a destaca. Talvez o convite também deva permitir adicionar à barra lateral? Não tenho certeza.

  • Soletrar as coisas melhor no tópico de boas-vindas ajudaria? Para encontrar sua casa, por favor, marque o seguinte e adicione à barra lateral, aqui estão os passos

cc @mcwumbly

3 curtidas
12

Por que não definir a página inicial deles com base no grupo principal?

2 curtidas
13

Acho que ambos temos que aceitar as restrições um do outro no curto prazo.

Como parece que o @gassim tinha um sistema em vigor que funcionava bem para eles, acho que fornecer alguma orientação aqui que se mantenha o mais próximo possível disso é provavelmente o melhor. Continue a usar grupos para controlar o acesso a categorias específicas e limitar o ruído de outros lugares.

Estamos interessados em limpar algumas arestas em nosso sistema de convites para torná-lo mais fácil de manter e entender, e espero que encontremos problemas como este ao longo do caminho. Neste caso, estamos insistindo em não depender de links de convite como links de tópico reutilizáveis.

Tendo lido o tópico anterior, estou pensando que o que pode fazer mais sentido é fazer algo como o seguinte:

  1. Substitua os links de convite para cada curso por links diretos para o tópico.
  2. Perto desses links, inclua um link de convite genérico. “Ainda não tem conta? Clique aqui para criar uma conta e ingressar no grupo”.
  3. Faça com que o link de convite direcione para um tópico que seja uma visão geral mais genérica e instrua o usuário a voltar ao seu curso e ingressar no tópico específico do curso a partir daí.
5 curtidas
14

Acabei de mesclar este patch, ele deve estar disponível para atualizar seu site Discourse em breve:

Obrigado pela sua compreensão.

5 curtidas
15

Obrigado pelo seu interesse!

As salas que são mantidas privadas são para os participantes do curso. Basicamente, queremos que essas salas sejam um espaço dedicado sem afetar o resto da atividade do fórum (latest, top… etc.). Ter os fóruns de discussão do curso em categorias privadas não é porque eles são ‘secretos’, mas porque apenas aqueles que optam por se inscrever no curso precisam ver os tópicos e discussões, enquanto aqueles que não o fazem podem continuar a usar o resto do site como de costume.

Obrigado pela sugestão! Ainda não experimentei a barra lateral, mas aqui está uma escrita livre sobre por que ainda não promovi a barra lateral:

  1. A página inicial já exibe duas colunas: Categorias em uma coluna e latest na outra; ter a barra lateral parece uma repetição na página inicial (não há como mantê-la desativada na página inicial?)
  2. A barra lateral parece dar mais atenção do que o necessário às Mensagens Privadas e não incentivamos muito o uso de PM.
  3. Contrariamente à ideia de que isso aliviará a dor, a barra lateral parecerá uma distração para os participantes do curso que entram na categoria privada porque não queremos que as outras categorias apareçam durante a participação deles. (não há opção para desativar a barra lateral em algumas categorias?)
  4. Se houver uma opção para o Admin personalizar a barra lateral por ‘grupo’, para que os participantes do grupo A vejam coisas relevantes para o grupo A, enquanto o grupo B verá coisas relevantes para o grupo B, isso ajudará a aliviar a dor. O motivo é que não esperamos que todos os usuários tratem o site como sua conta de e-mail e passem tempo aprendendo a personalizá-lo; por outro lado, precisamos recebê-los onde eles já se sentirão confortáveis e se beneficiarão diretamente da experiência sem precisar gastar tempo aprendendo a personalizar… etc. Portanto, se pudermos pré-personalizá-lo para cada grupo e, em seguida, eles terão a opção de alterá-lo, seria ótimo (além da opção de não mostrá-lo na página inicial - por padrão, ele deve ser oculto na página inicial, provavelmente um código CSS pode resolver isso, mas e quanto a certas categorias)

Não tenho certeza, pois haverá pelo menos 50 tópicos para os participantes que se inscreverem em todos os cursos. No entanto, estamos usando a sugestão de @martin:

Obrigado pela sugestão @Stephen! No entanto, a página inicial é para todos os membros e não queremos mudar isso. Os participantes do curso participarão de vários cursos, mas após cada curso, eles são convidados a continuar participando da comunidade.

2 curtidas
16

:100::100::100: Obrigado!

Entendido, mas então esta era a opção do administrador para fazer o link de convite expirar após um certo número de usos ou após uma certa data (além de limitá-lo a endereços de e-mail específicos). Para nós, como nunca queríamos que o link de convite expirasse, a data de expiração era 2092 e o número de usos era 1000000 (e, claro, não especificamos a lista de endereços de e-mail porque queríamos que o link de convite permanecesse aberto para quem quisesse participar do tópico de discussão na categoria privada)! No entanto, agora não consigo ver como essas opções serão tão úteis quando o link expirará de qualquer maneira após o primeiro uso para cada usuário individual.
Pessoalmente, ainda acredito que se isso fosse aplicado de forma diferente, adicionando uma opção durante a criação do link de convite que fosse semelhante às restrições acima (por padrão, o link de convite não será reutilizável, a menos que o Administrador desmarque esta opção e, uma vez desmarcada, haja um aviso sobre a questão de segurança que preocupa a equipe do Discourse). Teria tornado tudo muito mais fácil da minha percepção. :blush:

:100: Obrigado! Esta é exatamente a abordagem que estamos tomando atualmente; no entanto, precisamos atualizar as diretrizes com capturas de tela e, neste momento, ainda estamos aguardando o conserto que adiciona o botão ‘login’ ao cabeçalho: No 'sign in' option in the accept invitation page, only the signup form is shown

Obrigado @martin!

3 curtidas