Когда новый пользователь присоединяется по ссылке-приглашению, мне всё ещё приходится вручную одобрять его регистрацию.
Это сводит на нет саму суть приглашений; в таком случае я мог бы просто отправить им прямую ссылку на форум.
Я проверял это в различных ситуациях (новая ссылка, старая ссылка, один человек, несколько) на более чем одном экземпляре, и результат всегда одинаковый.
Для этих экземпляров у меня установлено значение TRUE в настройке /admin/site_settings/category/all_results?filter=must_approve_users. Похоже, система воспринимает это слишком буквально! Я хочу одобрять только тех, кто присоединяется без приглашения, как это работало раньше.
Если вы установили параметр must approve users (необходимо утверждать пользователей), вы явно указали, что каждый пользователь должен быть одобрен вручную.
Мы были вынуждены внести это изменение из-за проблем с безопасностью, о которых сообщили пользователи Discourse.
Попробуйте изменить настройки форума на «только по приглашениям» или «требуется вход в систему»? А затем ограничьте круг лиц, имеющих право отправлять приглашения.
Мне казалось, что приглашение от сотрудника уже является явным одобрением — особенно если в нём указан адрес электронной почты пользователя!
При открытом приглашении, конечно, есть много возможностей для злоупотребления ссылкой. Но сотрудник должен намеренно настроить ссылку так, чтобы это стало возможным, и может довольно легко взять на себя ответственность за этот риск (и ограничить его).
Это также означает, что люди, случайно зашедшие на мой сайт, не смогут в него вступить и будут исключены, если не найдут того, кто их пригласит. Это ужасно.
Предложение
Как насчёт добавления двух опций в /admin/site_settings/category/all_results?filter=must_approve_users?
Сотрудники должны одобрять ВСЕХ пользователей
Если пользователь не приглашён сотрудником, его одобрение обязательно
Только публичные регистрации требуют одобрения сотрудниками
Так и было, однако поведение было изменено примерно месяц назад:
У нас есть экземпляр, используемый благотворительной организацией/профсоюзом для обучения навыкам, который также пострадал.
До этого изменения сотрудники приглашали пользователей, чтобы обойти необходимость одобрения; теперь им нужно делать и то, и другое. Из-за необходимости возвращаться и проверять каждое одобрение по спискам членов это значительно увеличило их административную нагрузку.
Да… Долгосрочное решение, полагаю, — добавить настройку сайта, которая позволяет включить режим ослабленного утверждения по желанию.
Однако я беспокоюсь, потому что обеспечить здесь безопасность крайне сложно. Чем больше исключений мы допускаем, тем выше сложность и потенциальные уязвимости в безопасности.
Мне интересно, не сводится ли основной частный случай к тому, чтобы разрешать переопределять настройку «требовать одобрения пользователя», если в приглашении указан конкретный адрес электронной почты, но при этом сохранять эту настройку для анонимных ссылок-приглашений. Однако реализация этого на бэкенде может оказаться сложнее, чем я предполагаю.
Для меня это имеет смысл, особенно если приглашение было направлено на конкретный адрес электронной почты И отправлено сотрудником. В таком сценарии, я полагаю, не потребуется дополнительного уровня утверждения.
Как насчет того, чтобы разрешить администраторам устанавливать флаг «автоодобрение» и при желании ограничивать его условиями «без изменений email» или «только один раз» или что-то в этом роде? В моём случае мне подошёл бы даже приглашатель через командную строку, способный создавать такие специальные заранее одобренные приглашения. Есть ли что-то подобное?
В качестве неуклюжего обходного пути я сделал так, как предложил Сэм:
Я довольно широко распространил приглашения на наш форум, и это работает отлично.
Проблема возникает с «случайными посетителями», которые попадают на сайт через поиск в Google или аналогичные сервисы. Им приходится писать по электронной почте, чтобы получить ссылку для присоединения, что является настоящей головной болью для администратора.
Предложение Армана довольно простое, и я не думаю, что его будет сложно реализовать (или что оно создаст уязвимости):
На данный момент это просто не так, если must_approve_users установлено в TRUE:
Каждый раз, когда у нас есть группа людей для приглашения, мы либо сталкиваемся с большим количеством трений (шаг утверждения), либо должны временно перенастроить сайт (и закрыть его для публичной регистрации), что довольно болезненно.
Есть ли какие-либо мысли о том, что это когда-нибудь произойдет?
Здравствуйте! Хотел бы также запросить функцию, позволяющую сотрудникам создавать приглашения, которые обходят шаг утверждения. Возможно, для этого можно добавить опциональное булево значение в диалоговое окно генерации приглашений.
В настоящее время утверждение «Поделитесь этой ссылкой, чтобы мгновенно предоставить доступ к сайту» совершенно неверно для сайтов с включённой настройкой must_approve_users.
Кратко: данный запрос направлен на то, чтобы сотрудники на сайтах с настройкой must_approve_users могли создавать ссылки приглашений, которые обходят шаг утверждения. Хотя мой сайт требует утверждения участников, нам иногда хотелось бы иметь возможность «предварительно утверждать» пользователей через ссылку приглашения, если мы знаем, что она будет распространяться конфиденциально среди доверенных лиц, или если мы делимся ссылкой на физическом мероприятии, связанном с сообществом форума. (Мы не всегда знаем предпочитаемые адреса электронной почты таких приглашённых, поэтому не можем использовать массовое приглашение).
На наших довольно крупных сайтах с включённой настройкой must_approve_users это по-прежнему остаётся большой проблемой при проведении офлайн-мероприятий.
Суть в том, что мы не можем просто предоставить участникам красивый QR-код, приглашение или ссылку для мгновенного входа на наш инстанс. По крайней мере, без применения довольно неуклюжего обходного пути.
Обходной путь и связанные с ним проблемы
Отключение must_approve_users и переключение сайта в режим invite_only не является удовлетворительным решением, так как:
Многие пользователи путаются в процессе приглашения и пытаются войти через «переднюю дверь» (которая теперь закрыта).
Ажиотаж, созданный мероприятием, обычно распространяется и на тех, кто не получил приглашений, но они тоже не могут подать заявку на вступление.
Ситуация после изменений явно усложнилась. Благотворительная организация по профессиональной подготовке, с которой я работал и которая пострадала больше всего, решила закрыть своё сообщество несколько недель спустя.
Это слишком большая дополнительная административная нагрузка, когда каждую неделю приходят и уходят сотни людей.
Спасибо, что подняли этот вопрос снова. Я считаю, что здесь действует правило трёх: необходимо внести исправления, чтобы процесс приглашения стал проще и плавнее. Система приглашений оказалась сложной для изменений, поскольку каждый использует её по-разному. Нам нужны чёткие указания, и мы постараемся не нарушать рабочий процесс пользователей.
Я уточню у команды и посмотрю, что мы можем сделать.
Для меня это новость, давайте рассмотрим это отдельно.
Наше беспокойство связано с тем, что сайты могут быть настроены множеством разных способов, и тогда система приглашений должна работать по-разному в каждом случае. Вопросы безопасности здесь очень важны. Поэтому мы будем действовать осторожно при внесении любых дальнейших изменений в систему приглашений.
Лично я считаю, что лучшим будет следующий подход, поскольку он не зависит от настройки администратора и делает поведение системы абсолютно понятным прямо в модальном окне приглашения. Даже новичку в Discourse будет сложно случайно создать и распространить ссылку для приглашения, которая приведёт к непредвиденным последствиям. Что вы об этом думаете?
Когда включена настройка администратора «Требовать одобрения пользователей»
В модальном окне создания приглашения для сотрудников отображается переключатель, позволяющий создать приглашение, обходящее требование одобрения. Например: « Не требовать одобрения сотрудниками»
Приглашения, использованные при включении переключателя из пункта (2), позволяют пользователю войти на сайт без необходимости одобрения
Предполагается, что доступ к этому переключателю должны иметь только сотрудники, поскольку цель настройки «Требовать одобрения пользователей» — предоставить сотрудникам контроль над тем, кто может присоединиться к сообществу.
Если возникнет достаточный спрос, мы позже сможем рассмотреть возможность добавления настройки администратора для определения доступа к этой функции по группам.
Сэм даже назвал это изменение «удивительно сложным». Я не сомневаюсь в нём.
Совокупные усилия, затраченные на первоначальное изменение и это дополнение, очевидно, окажутся больше, чем если бы это было учтено с самого начала. Мы отмечали тогда, что хотя одно сообщество сочло текущее поведение по умолчанию неприемлемым, несколько других сообществ зависели от этого поведения. Например, профсоюз, который отказался от своего сайта для обучения навыкам на базе Discourse, принял это решение не легко, но для них стало невозможным продолжать работу, поскольку стажёры, приглашённые сотрудниками, терялись в общем пуле заявок на одобрение.
Если проблема здесь заключается в недостаточном ясном понимании, то, вероятно, необходим промежуточный шаг между настройкой «необходимо одобрять пользователей» и модальным окном приглашений, который предлагал бы опцию для приглашений сотрудников с обходом одобрения. В противном случае первоначальная жалоба, приведшая к этому изменению, может возникнуть снова.
Так что скорее так:
Когда включена административная настройка «необходимо одобрять пользователей» и новое значение «приглашения сотрудников обходят одобрение» изменено с его значения по умолчанию «никогда»:
Если выбрано «всегда», то вступит в силу старое поведение.
Если выбрано «по желанию», то в модальном окне отображается переключатель, дающий возможность обходить последующее одобрение.
Без этого промежуточного шага администраторы не до конца осознают последствия настройки «необходимо одобрять», а небольшая детализация решит другую проблему, возникающую при случайном забывании использовать этот переключатель.
Я считаю, что это будет работать очень хорошо (возможно, с учётом правки от @Stephen) — и мне нравится, что это персонализированный подход, который ничего не сломает, так как оставит все механизмы по умолчанию полностью нетронутыми.
Однако для меня крайне важен один крайний случай: автоматические приглашения по электронной почте, связанные с приглашениями в группы. Это позволяет добавлять людей в группу или отправлять им приглашение в зависимости от того, зарегистрированы ли они уже, одним действием администратора. Лично мне очень важно, чтобы это тоже было каким-то образом покрыто.
