Nuova funzione di richiesta 'accetta invito' causa problemi con i link di invito

Stiamo utilizzando link di invito per aiutare i nostri utenti a spostarsi tra le piattaforme e in discourse; tuttavia, il nuovo prompt che ha iniziato ad apparire con l’ultimo aggiornamento di discourse sta causando ritardi e confusione.

Gli utenti che utilizzano un link di invito che reindirizza a un post di argomento non solo sono in grado di utilizzare il link una sola volta, il che è un problema importante se ci aspettiamo che utilizzino il link ogni volta che desiderano visitare il post di argomento. È importante che siamo in grado di reindirizzare gli utenti utilizzando lo stesso link di invito quante volte l’utente desidera rivisitare l’argomento e avere questa funzionalità bloccata dal nuovo prompt sta causando un problema.

Sono apparsi anche altri problemi tecnici. Innanzitutto, sono necessari almeno cinque secondi affinché “accetta invito” risponda al clic, e poi ci vuole del tempo per reindirizzare l’utente all’argomento. In secondo luogo, con questa nuova aggiunta, ci vuole più tempo per caricare prima il prompt. In terzo luogo, anche se avessi cliccato sul link di invito in precedenza e accettato l’invito, ti verrà chiesto ogni volta che clicchi sul link!

Per riprodurre questo problema, crea un link di invito che reindirizzi gli utenti a un post di argomento e/o li aggiunga a un gruppo. Clicca sul link di reindirizzamento mentre sei loggato all’account discourse.

Per favore, c’è un modo per disabilitare questo prompt dalle impostazioni? Questo è sia urgente che importante perché per noi influenzerà l’esperienza dell’utente.

Potrebbe anche passare inosservato ad altri che potrebbero fare affidamento sui link di invito ma non sono consapevoli di questa nuova modifica perché non c’è stata alcuna notifica riguardo a questa modifica, grazie!

2 Mi Piace

Vorrei aggiungere che c’è anche un bug qui e nel nostro caso d’uso non abbiamo bisogno del prompt in primo luogo, quindi sarebbe possibile rimuoverlo? o avere l’opzione nelle impostazioni di amministrazione per disabilitarlo?

Il bug è che se si fa clic su “Accetta invito” per la seconda volta, la pagina rimarrà statica e non mostrerà alcun messaggio. Questo non è affatto utile. Blocca l’utente dall’utilizzare il contesto precedente per essere reindirizzato nuovamente all’argomento. Questo è un problema importante. Se inserisco un link di invito in un documento e mi aspetto che il lettore possa utilizzare lo stesso link più e più volte per essere reindirizzato all’argomento, il link di invito non funzionerà più. :sob:

Utilizziamo i link di invito perché il partecipante deve prima essere aggiunto a una categoria privata per poter leggere l’argomento. Se l’utente ha bisogno di ritrovare l’argomento, dovrebbe essere in grado di utilizzare lo stesso link di invito. In questo caso, dovrebbe accettare automaticamente l’invito se l’utente è connesso perché l’invito è destinato a quell’utente e, poiché in precedenza funzionava correttamente, dovrebbe reindirizzare l’utente al post dell’argomento desiderato.

I link di invito funzionavano perfettamente prima. Spero che possiate dare un’altra occhiata a questo e dare all’amministratore l’opzione di disabilitare questo prompt/messaggio del pulsante “Accetta invito”. Grazie!

4 Mi Piace

Grazie per la tua segnalazione @gassim.

Non riesco a riprodurre questo ritardo di 5 secondi. Testato qui su meta con più inviti sia con che senza aggiunta a un gruppo. Se vedi questo ritardo ogni volta, puoi provare la prossima volta con gli strumenti per sviluppatori aperti nella scheda console e vedere se ci sono errori segnalati lì?

Posso riprodurre questo, sembra che ci sia una regressione qui, la risolveremo a breve.

5 Mi Piace

Ecco la prova del ritardo di 5 secondi nella console di Firefox.

Non riesco a vedere errori nella console di Firefox, ma quando provo su Chrome, a volte ottengo questi errori.

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 Mi Piace

Grazie per l’aiuto @pmusaraj!

Per favore, il messaggio di prompt non è utile nel nostro caso d’uso, c’è un modo per gli amministratori di creare link di invito senza questo tipo di prompt?

I link di invito vengono utilizzati in un corso in cui i partecipanti sono invitati a unirsi ai forum di discussione. Tutto ciò che vogliamo che il link di invito faccia è aggiungere l’utente a un gruppo e reindirizzare l’utente a un argomento in una categoria privata (senza dover fare clic su “accetta invito” ogni volta che utilizzano un link), e dopo il primo clic gli utenti dovrebbero essere in grado di tornare all’argomento utilizzando lo stesso link di invito. Questo ha funzionato senza intoppi e perfettamente fino a quando il messaggio di prompt non è stato imposto durante la notte.

Ho spiegato come stiamo utilizzando i link di invito in un altro argomento

@tobiaseigen @dan @JammyDodger, per favore, aiutatemi in questo. Dobbiamo essere in grado di eliminare il messaggio di prompt nel nostro caso d’uso.

Grazie @yanokwa! (:

Ciao @gassim, ne abbiamo discusso internamente. Mi dispiace, ma il comportamento di accettare lo stesso invito più volte come stesso utente per agire come segnalibro è inaspettato e lo risolveremo nascondendo il pulsante “Accetta invito” se l’utente connesso ha già accettato l’invito. Al suo posto visualizzeremo un messaggio che informa l’utente che ha già riscattato il link dell’invito.

L’accettazione automatica di un invito all’apertura della pagina era un problema di sicurezza, motivo per cui abbiamo cambiato per avere invece la pagina intermedia “Accetta invito”.

Se è necessario che l’utente torni continuamente allo stesso argomento, suggeriamo di aggiungerlo ai segnalibri. Oppure, se hai un documento interno in cui inserisci il link dell’invito, aggiungi un link all’argomento nello stesso posto per comodità.

4 Mi Piace

Ciao @martin, grazie a te e al team di Discourse per la considerazione. Stiamo discutendo soluzioni alternative al momento.

Sì, per favore e saremmo felici di sapere quando questo bug sarà risolto.

Capito… Speravo che agli amministratori fosse data la possibilità durante la creazione del link di invito di scegliere se utilizzare o meno il messaggio di prompt (magari con un avviso su cosa potrebbe accadere se non utilizzano il messaggio di prompt). Siamo consapevoli che senza il messaggio di prompt, chiunque potrebbe accedere al gruppo/categoria privato, ma nel nostro caso non è un problema perché non sono gruppi/categorie “segreti”, sono privati per essere tenuti separati come spazi dedicati alla discussione di argomenti di corso.

Non è facile chiedere ai partecipanti al corso di segnalare l’argomento, ma quest’ultima suggerimento sembra essere la nostra unica opzione ora e l’azione immediata che potremmo intraprendere per risolvere il problema.

E sembra che stiamo affrontando anche questo problema ora: No 'sign in' option in the accept invitation page, only the signup form is shown, grazie!


Ancora, grazie a te e al tuo team per tutto il lavoro e il supporto. :+1:

2 Mi Piace

Oh, questo è un vincolo interessante. Quindi hai un Discourse con 1000 stanze a cui chiunque può accedere, ma vuoi che i membri del corso abbiano una forte affinità con la stanza particolare.

Alcune domande:

  • Qual è il valore nel non usare la sicurezza qui? latest è solo una grande quantità di rumore per l’utente tipico? Abbiamo anche un’impostazione “per impostazione predefinita tutte le categorie sono soppresse da latest” che potrebbe essere interessante.

  • La barra laterale può alleviare un po’ il problema? Se hai la categoria nella barra laterale, almeno la evidenzia. Forse l’invito dovrebbe anche consentire l’aggiunta alla barra laterale? Non sono sicuro.

  • Aiuterebbe scrivere le cose meglio nell’argomento di benvenuto? Per trovare la tua casa, aggiungi ai preferiti quanto segue e aggiungi alla barra laterale, ecco i passaggi

cc @mcwumbly

3 Mi Piace

Perché non impostare la loro home in base al loro gruppo principale?

2 Mi Piace

Penso che entrambi dobbiamo accettare i vincoli reciproci nel breve termine.

Dato che sembra che @gassim avesse un sistema in atto che funzionava bene per loro, penso che fornire alcune indicazioni qui che rimangano il più vicino possibile a quello sia probabilmente la cosa migliore. Continua a usare i gruppi per limitare l’accesso a categorie specifiche e ridurre il rumore da altre parti.

Siamo interessati a ripulire alcuni aspetti grezzi del nostro sistema di inviti per renderlo più manutenibile e comprensibile, e mi aspetto che ci imbatteremo in problemi come questo lungo la strada mentre lo facciamo. In questo caso, insistiamo sul non fare affidamento sui link di invito come link di argomenti riutilizzabili.

Avendo letto l’argomento precedente, penso che ciò che potrebbe avere più senso sia fare qualcosa di simile a quanto segue:

  1. Sostituire i link di invito per ogni corso con link diretti all’argomento.
  2. Vicino a quei link, includere un link di invito generico. “Non hai ancora un account? Clicca qui per creare un account e unirti al gruppo”.
  3. Fare in modo che il link di invito rimandi a un argomento più generico e istruisca l’utente a tornare al proprio corso e a unirsi all’argomento specifico del corso da lì.
5 Mi Piace

Ho appena unito questa correzione, dovrebbe essere presto disponibile per aggiornare il tuo sito Discourse:

Grazie per la tua comprensione.

5 Mi Piace

Grazie per il tuo interesse!

Le stanze che vengono mantenute private sono per i partecipanti al corso. Fondamentalmente vogliamo che queste stanze siano uno spazio dedicato senza influenzare il resto dell’attività del forum (latest, top… ecc.). Avere i forum di discussione del corso in categorie private non è perché sono “segreti”, ma perché solo coloro che scelgono di iscriversi al corso devono vedere gli argomenti e le discussioni, mentre coloro che non lo fanno possono continuare a utilizzare il resto del sito come al solito.

Grazie per il suggerimento! Non ho ancora sperimentato con la barra laterale, ma ecco una scrittura libera sul motivo per cui non ho ancora promosso la barra laterale:

  1. La homepage visualizza già due colonne: Categorie in una colonna e latest nell’altra; avere la barra laterale sembra una ripetizione sulla homepage (non c’è modo di tenerla disattivata sulla homepage?)
  2. La barra laterale sembra dare un’attenzione eccessiva ai Messaggi Privati e noi non incoraggiamo molto l’uso dei PM.
  3. Contrariamente all’idea che ciò allevierà il dolore, la barra laterale sembrerà una distrazione per i partecipanti al corso che si uniscono alla categoria privata perché non vogliamo che le altre categorie appaiano durante la loro partecipazione. (non c’è un’opzione per disabilitare la barra laterale in alcune categorie?)
  4. Se ci fosse un’opzione per l’amministratore di personalizzare la barra laterale per ‘gruppo’ in modo che i partecipanti del gruppo A vedano cose rilevanti per il gruppo A mentre il gruppo B vedrà cose rilevanti per il gruppo B, allora aiuterebbe ad alleviare il dolore. Il motivo è che non ci aspettiamo che tutti gli utenti trattino il sito come se fosse il loro account email e passino del tempo ad imparare a personalizzarlo; d’altra parte, dobbiamo accoglierli dove si sentiranno già a proprio agio e beneficeranno direttamente dall’esperienza senza dover passare del tempo ad imparare a personalizzare… ecc. Quindi, se potessimo pre-personalizzarlo per ogni gruppo e poi avessero la scelta di cambiarlo, sarebbe fantastico (più l’opzione di non mostrarlo sulla homepage - per impostazione predefinita dovrebbe essere nascosto sulla homepage, probabilmente un codice CSS può risolvere questo problema ma allora che dire di certe categorie)

Non sono sicuro perché ci saranno almeno 50 argomenti per i partecipanti che si iscrivono a tutti i corsi. Tuttavia, stiamo utilizzando il suggerimento di @martin:

Grazie per il suggerimento @Stephen! Tuttavia, la homepage è per tutti i membri e noi non vogliamo cambiarla. I partecipanti al corso parteciperanno a diversi corsi, ma dopo ogni corso sono invitati a continuare a partecipare alla community.

2 Mi Piace

:100::100::100: Grazie!

Capito, ma allora questa era l’opzione dell’amministratore per far scadere il link di invito dopo un certo numero di utilizzi o dopo una certa data (oltre a limitarlo a specifici indirizzi email). Per noi, poiché non abbiamo mai voluto che il link di invito scadesse, la data di scadenza era il 2092 e il numero di utilizzi erano 1000000 (e ovviamente non abbiamo specificato l’elenco degli indirizzi email perché volevamo che il link di invito rimanesse aperto a chiunque volesse effettivamente unirsi all’argomento di discussione nella categoria privata)! Tuttavia, ora non vedo come queste opzioni saranno così utili quando il link scadrà comunque dopo il primo utilizzo per ogni singolo utente.
Personalmente, credo ancora che se questo fosse stato applicato in modo diverso aggiungendo un’opzione durante la creazione del link di invito che fosse simile ai vincoli di cui sopra (per impostazione predefinita il link di invito non sarà riutilizzabile a meno che l’amministratore non deselezioni questa opzione e una volta deselezionata ci sia un avviso sulla questione della sicurezza che preoccupa il team di discourse). Avrebbe reso tutto molto più facile dalla mia prospettiva. :blush:


:100: Grazie! Questo è esattamente l’approccio che stiamo attualmente adottando; tuttavia, dobbiamo aggiornare le linee guida con screenshot e al momento stiamo ancora aspettando la correzione che aggiunge il pulsante ‘login’ all’intestazione: No 'sign in' option in the accept invitation page, only the signup form is shown

Grazie @martin!

3 Mi Piace