Значки и закрытые сообщества

Я понимаю из предыдущих обсуждений в начале 2017 года, что значки не работают для групп с ограничениями доступа.

Мы ищем способ обойти это ограничение. Немного предыстории.

Наша группа на 99,9% доступна только пользователям с ролью «Участники». У нас есть несколько групп, открытых для всех для публичных обсуждений или помощи/поддержки. Как платная группа участников, было бы замечательно иметь возможность отмечать активность внутри этих частных групп, так как из наших 1,3+ миллионов сообщений большинство находится именно в этих группах.

Есть ли обходной путь или конфигурация, которые могли бы это позволить?

4 лайка

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

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

7 лайков

Честно говоря, для наших целей это, я думаю, вполне приемлемо.

Это что-то простое? Или это может создать проблемы в долгосрочной перспективе?

1 лайк

Изменение запросов для значков на вашем сайте так, чтобы они использовали таблицу posts вместо таблицы badge_posts, было бы довольно простым. Однако правильное решение проблемы может потребовать более существенных изменений. Например, вам не нужно, чтобы значки присваивались за посты в вашей категории для сотрудников или в любой другой категории, где существует риск раскрытия заголовка темы.

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

4 лайка

Отлично, мне нравится эта теория.

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

Это было бы эпическим решением для групп с членством!

2 лайка

Давайте посмотрим, что по этому поводу думают инженеры Discourse или есть ли у них другие предложения. Это не первый случай, когда сообщается об этой проблеме. Было бы хорошо найти общее решение, но хорошее решение, подходящее для множества сайтов, может оказаться более сложным, чем то, что я предлагаю.

4 лайка

Не фанат замены вида.

Моя рекомендация здесь, @Mitchelsellers, — начать с малого. Награждайте бейджами, не привязывая их к конкретным сообщениям.

[сделал двадцать супер-лайкнутых сообщений как участник] (заголовок TBD) — хорошее место для начала.

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

Добавление проверок прав в тех местах, где мы связываем бейджи с сообщениями, — дело сложное, поэтому не рекомендую идти этим путём.

Начните с малого и простого.

5 лайков

Я думаю, что для нас это тоже будет вполне приемлемо.

Есть какие-нибудь хорошие советы по этому поводу?

1 лайк

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

3 лайка

Хорошо, мы приступим к работе над этим!

1 лайк

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

Следующие бейджи, использующие конкретные посты, не будут присуждаться за активность в приватных категориях:

  • Редактор
  • Первый флаг
  • Первый лайк
  • Первая ссылка
  • Первое цитирование
  • Первый шеринг
  • Первый эмодзи
  • Первое упоминание
  • Первая вставка (Onebox)
  • Первый ответ по электронной почте
  • Читатель
  • Редактор вики
  • Великолепный шеринг
  • Хороший шеринг
  • Служба поддержки
  • Приятный шеринг
  • Добро пожаловать
  • Знаменитая ссылка
  • Великолепный ответ
  • Великолепная тема
  • Хороший ответ
  • Хорошая тема
  • Горячая ссылка
  • Приятный ответ
  • Приятная тема
  • Популярная ссылка

Следующие бейджи не запрашивают конкретные посты и будут присуждаться за активность в приватных категориях:

  • Лицензированный
  • Автобиограф
  • Сертифицированный
  • Новый пользователь месяца
  • Прочитал правила
  • Восхищённый
  • Чемпион
  • Безумно влюблённый
  • Преданный
  • Эмпатичный
  • Афисионадо
  • Юбилей
  • Активист кампании
  • Возвращает долг
  • Высшая любовь
  • Уважаемый
  • Оценённый
  • Энтузиаст
  • Из любви
  • Промоутер
  • Спасибо
  • Лидер
  • Регулярный
  • Базовый
  • Участник
  • Персонал
  • Фото профиля

Что-то подобное уже покрыто бейджами «Оценённый» (1 лайк на 20 постах) и «Уважаемый» (2 лайка на 100 постах). Можно добавить некоторые вариации этих запросов. Например, 10 лайков на 20 постах. Также хорошей идеей мог бы стать бейдж за темы с супер-лайками — он функционировал бы как аналог бейджа «Великолепные темы». Например, его можно было бы присуждать, когда пользователь создал 10 тем, получивших по 10 лайков.

Не уверен, имеет ли смысл добавлять бейдж, присуждаемый за активность на одном посте или в одной теме, без ссылки на этот пост. Например, можно создать альтернативный бейдж «Первый лайк» со следующим SQL-запросом:

SELECT pa1.user_id, pa1.created_at granted_at
FROM (
  SELECT pa.user_id, min(pa.id) id
  FROM post_actions pa
  JOIN posts p on p.id = pa.post_id
  WHERE post_action_type_id = 2
  GROUP BY pa.user_id
) x
JOIN post_actions pa1 on pa1.id = x.id

Чтобы запрос работал, необходимо использовать триггер «Обновлять ежедневно» вместо запроса «Когда пользователь действует над постом». На странице «Бейджи» будут показаны пользователи, получившие бейдж, вместе с временем его присуждения. Ссылки на пост, за который был присуждён бейдж, не будет:

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

4 лайка

Я считаю, что это отличный шаг!

Хотел просто вернуться к этому вопросу.

Есть какие-то мысли по поводу реализации такого рода вещей?

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

2 лайка

Мы начали работу нашего форума с настройкой «требуется вход», а недавно добавили несколько публичных категорий, при этом ограничив доступ к существующим категориям для уровня доверия trust_level_0.

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

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

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

3 лайка

Ой! Хорошо, это фактически означает, что вся инфраструктура бейджей довольно бесполезна в сообществе с большим количеством приватных пространств…

Поддерживаю.

Есть ли какой-то плагин или новые настройки (за последние шесть лет), чтобы сделать бейджи жизнеспособными в сообществе, где преобладают приватные пространства?

2 лайка

Я поддерживаю улучшение того, как это работает из коробки.

Хотя эта тема уже много лет остаётся без внимания, я слышал, что люди просят аналогичные изменения и в других местах.

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

3 лайка

:flexed_biceps:

Это, кажется, связано с тем, что обсуждалось в другой теме: как помочь участникам сообщества ориентироваться между открытыми (публичными) и закрытыми (с разной степенью «приватности») пространствами, включая личные сообщения.

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

1 лайк

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

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

2 лайка

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

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

3 лайка