Nous avons utilisé des liens d’invitation pour aider nos utilisateurs à passer d’une plateforme à une autre et à participer à des discussions ; cependant, la nouvelle invite qui a commencé à apparaître avec la dernière mise à jour de Discourse cause des retards et de la confusion.
Les utilisateurs qui utilisent un lien d’invitation qui redirige vers un article de sujet ne peuvent pas utiliser le lien une seule fois, ce qui est un problème majeur si nous nous attendons à ce qu’ils utilisent le lien chaque fois qu’ils souhaitent visiter l’article du sujet. Il est important que nous puissions rediriger les utilisateurs en utilisant le même lien d’invitation autant de fois que l’utilisateur souhaite revisiter le sujet, et le fait que cette fonctionnalité soit bloquée par la nouvelle invite pose un problème.
D’autres problèmes techniques sont également apparus. Tout d’abord, il faut au moins cinq secondes pour que le bouton « accepter l’invitation » réponde au clic, puis il faut un certain temps pour rediriger l’utilisateur vers le sujet. Deuxièmement, avec cette nouvelle addition, il faut plus de temps pour charger l’invite en premier lieu. Troisièmement, même si vous avez déjà cliqué sur le lien d’invitation et accepté l’invitation, il continuera à vous le demander chaque fois que vous cliquerez sur le lien !
Pour reproduire ce problème, créez un lien d’invitation qui redirige les utilisateurs vers un article de sujet et/ou les ajoute à un groupe. Cliquez sur le lien de redirection tout en étant connecté au compte Discourse.
S’il vous plaît, y a-t-il un moyen de désactiver cette invite dans les paramètres ? C’est à la fois urgent et important car cela affectera l’expérience utilisateur.
Cela pourrait également passer inaperçu par d’autres qui pourraient compter sur les liens d’invitation mais qui ne sont pas au courant de ce nouveau changement car il n’y a eu aucune notification à ce sujet, merci !
J’aimerais ajouter qu’il y a aussi un bug ici et que dans notre cas d’utilisation, nous n’avons pas besoin de l’invite en premier lieu, serait-il donc possible de la supprimer ? ou d’avoir la possibilité dans les paramètres d’administration de la désactiver ?
Le bug est que si vous cliquez sur « Accepter l’invitation » pour la deuxième fois, la page restera statique et n’affichera aucun message. Ce n’est pas du tout utile. Cela empêche l’utilisateur d’utiliser le contexte précédent pour être redirigé vers le sujet. C’est un problème majeur. Si je mets un lien d’invitation dans un document et que je m’attends à ce que le lecteur utilise le même lien encore et encore pour être redirigé vers le sujet, le lien d’invitation ne fonctionnera plus.
Nous utilisons des liens d’invitation car le participant doit d’abord être ajouté à une catégorie privée pour pouvoir lire le sujet. Si l’utilisateur a besoin de retrouver le sujet, il devrait pouvoir utiliser le même lien d’invitation. Dans ce cas, l’invitation devrait être acceptée automatiquement si l’utilisateur est connecté, car l’invitation est destinée à cet utilisateur et, comme cela fonctionnait bien auparavant, elle devrait rediriger l’utilisateur vers la publication du sujet prévue.
Les liens d’invitation fonctionnaient parfaitement auparavant. J’espère que vous pourrez y jeter un second regard et donner aux administrateurs la possibilité de désactiver cette invite/ce message de bouton « Accepter l’invitation ». Merci !
Je ne peux pas reproduire ce délai de 5 secondes. Testé ici sur meta avec plusieurs invitations, avec et sans ajout à un groupe. Si vous constatez ce délai à chaque fois, pouvez-vous essayer la prochaine fois avec les outils de développement ouverts dans l’onglet console et voir s’il y a des erreurs signalées ?
Je peux reproduire celui-ci, il semble y avoir une régression ici, nous allons corriger cela bientôt.
Je ne vois aucune erreur dans la console Firefox, mais lorsque j’essaie dans Chrome, j’obtiens parfois ces erreurs.
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)
S’il vous plaît, le message d’invite n’est pas utile dans notre cas d’utilisation. Y a-t-il un moyen pour l’administrateur de créer des liens d’invitation sans ce type d’invite ?
Les liens d’invitation sont utilisés dans un cours où les participants sont invités à rejoindre les forums de discussion. Tout ce que nous voulons que le lien d’invitation fasse est d’ajouter l’utilisateur à un groupe et de le rediriger vers un sujet dans une catégorie privée (sans avoir à cliquer sur « accepter l’invitation » à chaque fois qu’il utilise un lien), et après le premier clic, les utilisateurs devraient pouvoir revenir au sujet en utilisant le même lien d’invitation. Cela a fonctionné sans problème et parfaitement jusqu’à ce que le message d’invite soit appliqué du jour au lendemain.
J’ai expliqué comment nous utilisons les liens d’invitation dans un autre sujet
@tobiaseigen@dan@JammyDodger , s’il vous plaît, aidez-moi. Nous devons pouvoir supprimer le message d’invite dans notre cas d’utilisation.
Salut @gassim, nous en avons discuté en interne. Désolé, mais le comportement consistant à accepter la même invitation plusieurs fois par le même utilisateur pour l’utiliser comme marque-page est inattendu, et nous allons corriger cela pour masquer le bouton « Accepter l’invitation » si l’utilisateur connecté a déjà accepté l’invitation. Au lieu de cela, nous afficherons un message informant l’utilisateur qu’il a déjà utilisé le lien d’invitation.
L’acceptation automatique d’une invitation à l’ouverture de la page était un problème de sécurité, c’est pourquoi nous avons changé pour avoir la page intermédiaire « Accepter l’invitation » à la place.
S’il est nécessaire que l’utilisateur revienne sans cesse sur le même sujet, nous suggérons de le mettre en marque-page. Ou, si vous avez un document interne où vous mettez le lien d’invitation, ajoutez un lien vers le sujet au même endroit pour plus de commodité.
Bonjour @martin, merci à vous et à l’équipe Discourse pour votre considération. Nous discutons actuellement de solutions alternatives.
Oui, s’il vous plaît, et nous serions heureux de savoir quand ce bug sera corrigé.
Compris… J’espérais que les administrateurs auraient la possibilité, lors de la création du lien d’invitation, de choisir si le message d’invite est utilisé ou non (peut-être avec un avertissement sur ce qui pourrait se passer s’ils n’utilisent pas le message d’invite). Nous sommes conscients que sans le message d’invite, n’importe qui pourrait accéder au groupe/catégorie privé, mais dans notre cas d’utilisation, ce n’est pas un problème car il ne s’agit pas de groupes/catégories « secrets », ils sont privés pour être séparés en tant qu’espaces dédiés à la discussion de sujets de cours.
Il n’est pas facile d’exiger des participants au cours qu’ils marquent le sujet comme favori, mais la dernière suggestion ressemble à notre seule option maintenant et à l’action immédiate que nous pourrions entreprendre pour résoudre le problème.
Oh, c’est une contrainte intéressante. Vous avez donc un Discourse avec 1000 salles auxquelles tout le monde peut accéder, mais vous voulez que les membres du cours aient une forte affinité pour la salle particulière.
Quelques questions :
Quelle est la valeur de ne pas utiliser la sécurité ici ? Est-ce que latest n’est qu’une quantité énorme de bruit pour l’utilisateur typique ? Nous avons également un paramètre « par défaut, toutes les catégories sont supprimées de latest » qui pourrait être intéressant.
La barre latérale peut-elle atténuer un peu la douleur ? Si vous avez la catégorie dans votre barre latérale, au moins elle la met en évidence. Peut-être que l’invitation devrait également permettre d’ajouter à la barre latérale ? Je ne suis pas sûr ?
L’explication plus claire dans le sujet de bienvenue aiderait-elle ? Pour trouver votre chez-vous, veuillez mettre en favoris ce qui suit et l'ajouter à la barre latérale, voici les étapes
Je pense que nous devons tous les deux accepter les contraintes de l’autre à court terme.
Puisqu’il semble que @gassim avait un système en place qui fonctionnait bien pour eux, je pense qu’il est préférable de fournir ici des conseils qui restent aussi proches que possible de ce système. Continuez à utiliser des groupes pour restreindre l’accès à des catégories spécifiques et limiter le bruit provenant d’ailleurs.
Nous souhaitons améliorer certains aspects de notre système d’invitation afin de le rendre plus facile à maintenir et à comprendre, et je m’attends à rencontrer des problèmes comme celui-ci en cours de route. Dans ce cas, nous insistons pour ne pas nous appuyer sur des liens d’invitation comme liens de sujet réutilisables.
Après avoir lu le sujet précédent, je pense que ce qui aurait le plus de sens serait de faire quelque chose comme suit :
Remplacer les liens d’invitation pour chaque cours par des liens directs vers le sujet.
Près de ces liens, inclure un lien d’invitation générique. “Pas encore de compte ? Cliquez ici pour créer un compte et rejoindre le groupe.”
Faire en sorte que le lien d’invitation mène à un sujet plus générique et demande à l’utilisateur de retourner à son cours et de rejoindre le sujet spécifique au cours à partir de là.
Les salles qui sont gardées privées sont pour les participants au cours. Essentiellement, nous voulons que ces salles soient un espace dédié sans affecter le reste de l’activité du forum (latest, top… etc). Avoir les forums de discussion de cours dans des catégories privées n’est pas parce qu’ils sont « secrets », mais parce que seuls ceux qui choisissent de s’inscrire au cours ont besoin de voir les sujets et les discussions, tandis que ceux qui ne le font pas peuvent continuer à utiliser le reste du site comme d’habitude.
Merci pour la suggestion ! Je n’ai pas encore expérimenté la barre latérale, mais voici une réflexion libre sur les raisons pour lesquelles je n’ai pas encore promu la barre latérale :
La page d’accueil affiche déjà deux colonnes : les catégories dans une colonne et latest dans l’autre ; avoir la barre latérale semble être une répétition sur la page d’accueil (il n’y a pas moyen de la désactiver sur la page d’accueil ?)
La barre latérale semble accorder une attention excessive aux messages privés et nous n’encourageons pas beaucoup l’utilisation des MP.
Contrairement à l’idée que cela soulagera la douleur, la barre latérale semblera une distraction pour les participants au cours qui rejoignent la catégorie privée car nous ne voulons pas que les autres catégories apparaissent pendant leur participation. (n’y a-t-il pas une option pour désactiver la barre latérale dans certaines catégories ?)
S’il existe une option pour que l’administrateur personnalise la barre latérale par « groupe », de sorte que les participants du groupe A voient les choses pertinentes pour le groupe A, tandis que le groupe B voit les choses pertinentes pour le groupe B, cela aiderait à soulager la douleur. La raison en est que nous ne nous attendons pas à ce que tous les utilisateurs traitent le site comme leur compte de messagerie et passent du temps à apprendre à le personnaliser ; d’un autre côté, nous devons les accueillir là où ils se sentiront déjà à l’aise et bénéficieront directement de l’expérience sans avoir à passer du temps à apprendre à personnaliser… etc. Donc, si nous pouvons le pré-personnaliser pour chaque groupe, puis qu’ils ont le choix de le modifier, ce serait formidable (plus l’option de ne pas l’afficher sur la page d’accueil - par défaut, il devrait être masqué sur la page d’accueil, probablement qu’un code CSS peut résoudre cela, mais qu’en est-il de certaines catégories)
Je ne suis pas sûr car il y aura au moins 50 sujets pour les participants qui s’inscrivent à tous les cours. Cependant, nous utilisons la suggestion de @martin :
Merci pour la suggestion @Stephen ! Cependant, la page d’accueil est pour tous les membres et nous ne voulons pas changer cela. Les participants au cours participeront à plusieurs cours, mais après chaque cours, ils sont invités à continuer à participer à la communauté.
Compris, mais alors c’était l’option de l’administrateur de faire expirer le lien d’invitation après un certain nombre d’utilisations ou après une certaine date (en plus de le limiter à des adresses e-mail spécifiques). Pour nous, parce que nous n’avons jamais voulu que le lien d’invitation expire, la date d’expiration était 2092 et le nombre d’utilisations était de 1000000 (et bien sûr, nous n’avons pas spécifié la liste des adresses e-mail car nous voulions que le lien d’invitation reste ouvert à quiconque souhaite réellement rejoindre le sujet de discussion dans la catégorie privée) ! Cependant, je ne vois pas maintenant comment ces options seront aussi utiles lorsque le lien expirera de toute façon après la première utilisation pour chaque utilisateur individuel.
Personnellement, je pense toujours que si cela avait été appliqué différemment en ajoutant une option lors de la création du lien d’invitation qui est similaire aux contraintes ci-dessus (par défaut, le lien d’invitation ne sera pas réutilisable à moins que l’administrateur ne décoche cette option et une fois décochée, il y a un avertissement concernant le problème de sécurité qui préoccupe l’équipe de Discourse). Cela aurait tout rendu beaucoup plus facile de mon point de vue.
Merci ! C’est exactement l’approche que nous adoptons actuellement ; cependant, nous devons mettre à jour les directives avec des captures d’écran et pour le moment, nous attendons toujours le correctif qui ajoute le bouton ‘connexion’ à l’en-tête : No 'sign in' option in the accept invitation page, only the signup form is shown
