Новая функция запроса «принять приглашение» вызывает проблемы с ссылками на приглашения

Поддержка
1

Мы использовали ссылки-приглашения, чтобы помочь нашим пользователям переходить между платформами и в Discourse; однако новое уведомление, появившееся с последним обновлением Discourse, вызывает задержки и путаницу.

Пользователи, использующие ссылку-приглашение, которая перенаправляет на пост темы, могут воспользоваться ею только один раз. Это серьёзная проблема, если мы ожидаем, что они будут использовать ссылку каждый раз, когда хотят посетить пост темы. Важно, чтобы мы могли перенаправлять пользователей с помощью одной и той же ссылки-приглашения столько раз, сколько пользователь захочет вернуться к теме, и то, что эта функция заблокирована новым уведомлением, создаёт проблемы.

Появились и другие технические проблемы. Во-первых, кнопка «Принять приглашение» реагирует на клик не менее чем через пять секунд, а затем требуется дополнительное время для перенаправления пользователя на тему. Во-вторых, с этим новым дополнением сначала дольше загружается само уведомление. В-третьих, даже если вы уже нажали на ссылку-приглашение и приняли приглашение ранее, система будет спрашивать об этом каждый раз при клике на ссылку!

Чтобы воспроизвести эту проблему, создайте ссылку-приглашение, которая перенаправляет пользователей на пост темы и/или добавляет их в группу. Нажмите на ссылку-перенаправление, будучи авторизованным в учётной записи Discourse.

Пожалуйста, есть ли способ отключить это уведомление через настройки? Это срочно и важно, так как для нас это повлияет на пользовательский опыт.

Возможно, это также останется незамеченным другими, кто полагается на ссылки-приглашения, но не знает об этом новом изменении, поскольку не было никакого уведомления об этом изменении. Спасибо!

3

Хочу также отметить, что здесь есть ошибка. В нашем случае подсказка вообще не нужна, поэтому возможно ли её удалить? Или хотя бы добавить в настройках администратора возможность её отключить?

Суть ошибки: если нажать «Принять приглашение» во второй раз, страница остаётся статичной и не отображает никаких сообщений. Это совершенно не помогает. Это блокирует возможность пользователя использовать предыдущий контекст для повторного перехода к теме. Это серьёзная проблема. Если я вставлю ссылку-приглашение в документ и ожидаю, что читатель сможет использовать эту же ссылку многократно для перехода к теме, то после первого использования ссылка перестанет работать. :sob:

Мы используем ссылки-приглашения, потому что участника сначала нужно добавить в приватную категорию, чтобы он мог прочитать тему. Если пользователю нужно снова найти тему, он должен иметь возможность использовать ту же ссылку-приглашение. В таком случае, если пользователь уже авторизован, приглашение должно автоматически приниматься, так как оно предназначено именно для него. Как и раньше, система должна перенаправлять пользователя на соответствующий пост темы.

Ранее ссылки-приглашения работали безупречно. Надеюсь, вы ещё раз рассмотрите эту проблему и предоставите администраторам возможность отключать это сообщение/кнопку «Принять приглашение». Спасибо!

image
image1778×454 135 KB

4

Спасибо за ваш отчет, @gassim.

Мне не удалось воспроизвести эту задержку в 5 секунд. Я тестировал здесь на meta с несколькими приглашениями — как с добавлением в группу, так и без. Если вы наблюдаете эту задержку каждый раз, попробуйте в следующий раз открыть инструменты разработчика во вкладке консоли и посмотрите, не сообщается ли там об ошибках.

Мне удалось воспроизвести эту проблему. Похоже, здесь имеет место регрессия, мы исправим это в ближайшее время.

5

Вот подтверждение задержки в 5 секунд в консоли Firefox.

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

В консоли Firefox я не вижу никаких ошибок, но при попытке в Chrome иногда возникают следующие ошибки.

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)
6

Спасибо за помощь, @pmusaraj!

Пожалуйста, сообщение приглашения не подходит для нашего сценария использования. Есть ли способ для администратора создавать ссылки-приглашения без такого сообщения?

Ссылки-приглашения используются в курсе, где участников приглашают присоединиться к форумам обсуждения. Всё, что мы хотим от ссылки-приглашения, — это добавить пользователя в группу и перенаправить его на тему в закрытой категории (без необходимости каждый раз нажимать «Принять приглашение» при использовании ссылки). После первого клика пользователи должны иметь возможность возвращаться к теме, используя ту же ссылку-приглашение. До вчерашнего вечера это работало безупречно и гладко, пока не было введено принудительное сообщение.

Я уже объяснил, как мы используем ссылки-приглашения, в другой теме:

@tobiaseigen @dan @JammyDodger, пожалуйста, помогите нам. Мы должны иметь возможность убрать это сообщение в нашем сценарии использования.

7

Спасибо, @yanokwa! (:

9

Привет, @gassim, мы обсудили это внутри команды. Извините, но поведение, при котором один и тот же пользователь может несколько раз принимать одно и то же приглашение в качестве закладки, является неожиданным. Мы исправим это, скрывая кнопку «Принять приглашение», если вошедший в систему пользователь уже принял приглашение. Вместо этого мы будем отображать сообщение, информирующее пользователя о том, что он уже активировал ссылку приглашения.

Автоматическое принятие приглашения при открытии страницы было проблемой безопасности, поэтому мы перешли к использованию промежуточной страницы «Принять приглашение».

Если пользователю необходимо постоянно возвращаться к одной и той же теме, мы рекомендуем ему добавить её в закладки. Или, если у вас есть внутренний документ, в который вы вставляете ссылку-приглашение, добавьте в том же месте ссылку на тему для удобства.

10

Привет @martin, спасибо вам и команде Discourse за внимание. В данный момент мы обсуждаем альтернативные решения.

Да, пожалуйста, и мы будем рады узнать, когда эта ошибка будет исправлена.

Понятно… Я надеялся, что администраторам при создании ссылки приглашения будет предоставлена возможность выбрать, использовать ли сообщение-подсказку или нет (возможно, с предупреждением о том, что может произойти, если они не будут использовать подсказку). Мы понимаем, что без сообщения-подсказки любой сможет получить доступ к приватной группе/категории, но в нашем случае это не проблема, так как эти группы/категории не являются «секретными»; они приватны, чтобы быть отдельными пространствами для обсуждения тем курса.

Требовать от участников курса добавлять тему в закладки непросто, но последнее предложение звучит как наш единственный вариант сейчас и как немедленное действие, которое мы можем предпринять для решения проблемы.

Кажется, мы также столкнулись с этой проблемой сейчас: No 'sign in' option in the accept invitation page, only the signup form is shown, спасибо!

Ещё раз спасибо вам и вашей команде за всю работу и поддержку. :+1:

11

О, это интересное ограничение. Значит, у вас есть Discourse с 1000 комнатами, к которым может получить доступ любой, но вы хотите, чтобы участники курса чувствовали сильную привязанность к конкретной комнате.

Несколько вопросов:

  • В чём ценность отказа от использования безопасности здесь? Является ли latest просто огромным количеством шума для типичного пользователя? У нас также есть настройка «по умолчанию все категории скрыты из ленты latest», которая может быть интересна.

  • Может ли боковая панель немного облегчить ситуацию? Если категория есть в вашей боковой панели, это хотя бы привлекает к ней внимание. Возможно, приглашение также должно позволять добавлять категорию в боковую панель? Не уверен.

  • Помогло бы ли более подробное разъяснение в приветственной теме? Например: «Чтобы найти свой дом, добавьте следующую ссылку в закладки и добавьте категорию в боковую панель. Вот шаги».

cc @mcwumbly

12

Почему бы не установить их домашнюю страницу на основе их основной группы?

13

Я думаю, что нам обоим в краткосрочной перспективе необходимо принять ограничения друг друга.

Поскольку, судя по всему, у @gassim уже была налаженная система, которая хорошо работала,我认为, что предоставление рекомендаций, максимально близких к её текущему состоянию, вероятно, будет лучшим решением. Продолжайте использовать группы для ограничения доступа к определённым категориям и минимизации лишнего шума из других разделов.

Мы заинтересованы в устранении некоторых несовершенств нашей системы приглашений, чтобы сделать её более поддерживаемой и понятной, и, как я ожидаю, в процессе мы столкнёмся с подобными проблемами. В данном случае мы настаиваем на том, чтобы не использовать ссылки для приглашений как многоразовые ссылки на темы.

Прочитав предыдущую тему, я думаю, что наиболее логичным решением может быть следующее:

  1. Заменить ссылки для приглашений на каждый курс прямыми ссылками на соответствующую тему.
  2. Рядом с этими ссылками разместить общую ссылку для приглашения: «У вас ещё нет аккаунта? Нажмите здесь, чтобы создать аккаунт и присоединиться к группе».
  3. Настроить общую ссылку для приглашения так, чтобы она вела на более общую тему с обзором, где пользователю будет предложено вернуться к своему курсу и присоединиться к теме, специфичной для этого курса.
14

Я только что применил это исправление, и оно скоро станет доступно для обновления вашего сайта Discourse:

Спасибо за понимание.

15

Спасибо за ваш интерес!

Комнаты, которые остаются приватными, предназначены для участников курсов. По сути, мы хотим, чтобы эти комнаты были выделенным пространством, не влияющим на остальную активность форума (разделы «Последнее», «Топ» и т. д.). Размещение форумов обсуждения курсов в приватных категориях связано не с тем, что они «секретны», а с тем, что темы и обсуждения должны видеть только те, кто решил записаться на курс, в то время как остальные пользователи могут продолжать использовать остальную часть сайта как обычно.

Спасибо за предложение! Я ещё не экспериментировал с боковой панелью, но вот мои размышления о том, почему я пока не продвигаю её:

  1. На главной странице уже отображаются два столбца: в одном — категории, в другом — «Последнее». Наличие боковой панели кажется повторением на главной странице (есть ли способ отключить её на главной странице?).
  2. Боковая панель, кажется, уделяет чрезмерное внимание личным сообщениям, а мы не рекомендуем активно использовать ЛС.
  3. Вопреки мнению, что это облегчит ситуацию, боковая панель может показаться отвлекающим фактором для участников курсов, которые присоединяются к приватной категории, поскольку мы не хотим, чтобы во время их участия отображались другие категории (есть ли опция отключения боковой панели в отдельных категориях?).
  4. Если бы была возможность для администратора настраивать боковую панель для каждой «группы» так, чтобы участники группы A видели только релевантное для группы A, а участники группы B — релевантное для группы B, это помогло бы облегчить ситуацию. Причина в том, что мы не ожидаем, что все пользователи будут относиться к сайту как к своей электронной почте и тратить время на изучение его настройки. С другой стороны, нам нужно welcoming их там, где они сразу почувствуют себя комфортно и получат прямую пользу от опыта, не тратя время на изучение настройки и т. д. Поэтому, если мы сможем заранее настроить боковую панель для каждой группы, а затем предоставить им возможность изменить её, это было бы отлично (плюс опция скрыть её на главной странице — по умолчанию она должна быть скрыта на главной странице; возможно, это можно исправить с помощью CSS-кода, но что насчёт определённых категорий?).

Я не уверен, так как для участников, записавшихся на все курсы, будет как минимум 50 тем. Однако мы используем предложение от @martin:

Спасибо за предложение, @Stephen! Однако главная страница предназначена для всех участников, и мы не хотим этого менять. Участники курсов будут участвовать в нескольких курсах, но после завершения каждого курса их приглашают продолжать участие в сообществе.

16

:100::100::100: Спасибо!

Понял, но тогда у администратора была возможность установить срок действия ссылки-приглашения после определенного количества использований или после определенной даты (в дополнение к ограничению списком конкретных адресов электронной почты). В нашем случае, поскольку мы никогда не хотели, чтобы ссылка-приглашение истекала, дата истечения была установлена на 2092 год, а количество использований — на 1 000 000 (и, конечно же, мы не указывали список адресов электронной почты, так как хотели, чтобы ссылка-приглашение оставалась открытой для любого, кто действительно хочет присоединиться к обсуждению темы в закрытой категории)! Однако теперь я не вижу, как эти опции будут так же полезны, если ссылка будет истекать после первого использования для каждого отдельного пользователя.
Лично я все еще считаю, что если бы это было реализовано иначе — путем добавления опции при создании ссылки-приглашения, аналогичной вышеупомянутым ограничениям (по умолчанию ссылка-приглашение не будет повторяемой, если администратор не снимет этот флажок; после снятия флажка должно появляться предупреждение о проблеме безопасности, которая беспокоит команду Discourse). Это сделало бы всё намного проще с моей точки зрения. :blush:

:100: Спасибо! Это именно тот подход, который мы сейчас используем; однако нам необходимо обновить руководство, добавив скриншоты, и в данный момент мы всё ещё ждем исправления, которое добавит кнопку «Войти» в заголовок: No 'sign in' option in the accept invitation page, only the signup form is shown

Спасибо, @martin!