Пользователь не повышен до TL2

У меня возник странный случай: пользователь автоматически не повышен до уровня TL2. Я знаю, что мог бы вручную изменить уровень с TL1 на TL2, но меня интересует, что пошло не так, из-за чего Discourse пропустил именно этого пользователя. В требованиях к уровню TL2 в Discourse изменений не было. Просматривая профиль пользователя, я вижу, что все требования выполнены. Пользователь не заблокирован и не замолчан, никогда не был таковым; аккаунт довольно старый и был создан почти в самом начале существования форума, которому уже четыре года. Я использую версию 2.5.0.beta6, но эта «ошибка», похоже, существует уже довольно давно. Я искал страницу, которая показала бы мне, возможно, что-то упускаю, но такая страница доступна только для TL3 (/admin/users/ID/LOGIN/tl3_requirements). Мой вопрос: есть ли быстрый способ проверить требования для других уровней доверия? Где мне следует искать, чтобы понять, что не так? Изменение уровня доверия вручную — это, честно говоря, последняя мера, «костыль», потому что это вызовет вопросы у других пользователей относительно правильности их уровня доверия.

Чтобы проверить, соответствует ли пользователь требованиям для уровня доверия TL2, введите «tl2 requires» в поле поиска на странице настроек вашего сайта. Это отобразит список требований вашего сайта для уровня доверия TL2. Вы можете сравнить эти настройки с активностью пользователя, просмотрев раздел «Активность» на странице администратора пользователя.

Один из моментов, который стоит проверить для пользователей, которые не повышаются в уровне доверия, — убедиться, что их уровень доверия не был заблокирован в прошлом. У пользователей с заблокированным уровнем доверия в разделе «Разрешения» на странице администратора пользователя будет кнопка «Разблокировать уровень доверия»:

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

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

Можете ли вы сделать скриншот ваших настроек и их активности?

Настройки для TL2 (это всё или я что-то упустил?)

Активность пользователя

Права доступа пользователя

У меня возникла точно такая же проблема. Пользователь почти соответствует требованиям для уровня TL3 (согласно отчёту о требованиях, которого не хватает для TL2), но до сих пор не был автоматически повышен до TL2.

@Aylin, вы нашли причину на вашем экземпляре?

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

Однако в моём экземпляре все пользователи создаются через SSO, и я использую этого пользователя как эталон для анализа, так как уверен, что он должен быть автоматически повышен. Но в моём сообществе всего 2 пользователя уровня TL2, тогда как 996 пользователей имеют уровень TL1, что кажется очень странной пропорцией.

Это, безусловно, кажется подозрительным!

Если вы перейдете в /logs, есть ли там какие-либо сильно повторяющиеся ошибки?

Спасибо за такой быстрый ответ :slight_smile:

Зафиксирована только одна ошибка:

Log

Сообщение

ActiveRecord::StatementInvalid (PG::SyntaxError: ERROR: syntax error in tsquery: “‘Melhorias gerais no Compara Jogos’:*A & ‘’:*B”
)
lib/freedom_patches/fast_pluck.rb:41:in select_raw' lib/freedom_patches/fast_pluck.rb:61:in pluck’
app/models/topic.rb:621:in similar_to' app/controllers/similar_topics_controller.rb:25:in index’
app/controllers/application_controller.rb:340:in block in with_resolved_locale' app/controllers/application_controller.rb:340:in with_resolved_locale’
lib/middleware/omniauth_bypass_middleware.rb:68:in call' lib/content_security_policy/middleware.rb:12:in call’
lib/middleware/anonymous_cache.rb:336:in call' config/initializers/008-rack-cors.rb:25:in call’
config/initializers/100-quiet_logger.rb:19:in call' config/initializers/100-silence_logger.rb:31:in call’
lib/middleware/enforce_hostname.rb:22:in call' lib/middleware/request_tracker.rb:176:in call’

Обратная трассировка

rack-mini-profiler (2.0.4) lib/patches/db/pg.rb:72:in exec_params' rack-mini-profiler (2.0.4) lib/patches/db/pg.rb:72:in exec_params’
activerecord (6.0.3.2) lib/active_record/connection_adapters/postgresql_adapter.rb:675:in block (2 levels) in exec_no_cache' activesupport (6.0.3.2) lib/active_support/dependencies/interlock.rb:48:in block in permit_concurrent_loads’
activesupport (6.0.3.2) lib/active_support/concurrency/share_lock.rb:187:in yield_shares' activesupport (6.0.3.2) lib/active_support/dependencies/interlock.rb:47:in permit_concurrent_loads’
activerecord (6.0.3.2) lib/active_record/connection_adapters/postgresql_adapter.rb:674:in block in exec_no_cache' activerecord (6.0.3.2) lib/active_record/connection_adapters/abstract_adapter.rb:722:in block (2 levels) in log’
activesupport (6.0.3.2) lib/active_support/concurrency/load_interlock_aware_monitor.rb:26:in block (2 levels) in synchronize' activesupport (6.0.3.2) lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in handle_interrupt’

Окружение

HTTP HOSTS: forum.comparajogos.com.br

Не знаю, может ли это быть связано.

Эти два пользователя с уровнем доверия TL2 — это я (администратор) и ещё один пользователь. Это означает, что автоматическое повышение до TL2 сработало для обоих, так как я никогда вручную не менял уровни доверия.

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

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

Нет, и если я правильно помню, в логах я тоже ничего интересного не обнаружил. В итоге я вручную изменил TL для этого конкретного пользователя и заблокировал TL2, чтобы форум даже не пытался вернуть его обратно на TL1.

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

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

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

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

Читая этот пост: https://meta.discourse.org/t/when-does-user-trust-level-promotion-occur/29845, вижу, что ранее уже возникали проблемы с автоматическим повышением. Возможно, здесь дело в том же?

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

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

Я немного изменил настройки TL1:

и также:
image