ユーザーがTL2に昇進しません

サポート
1

奇妙なケースに遭遇しました。あるユーザーが自動的に TL2 に昇格しないのです。TL1 から TL2 へ手動で変更することは可能ですが、なぜ Discourse がこの特定のユーザーを見落としているのか、何が原因なのか気になります。

Discourse 側では TL2 の要件に変更はありません。ユーザーのプロファイルを確認すると、すべての要件を満たしていることがわかります。ユーザーはブロックも沈黙もされておらず、過去も同様です。このアカウントは古く、4 年前に開設されたフォーラムのほぼ最初期に作られたものです。

使用しているバージョンは 2.5.0.beta6 ですが、この「不具合」は結構前から存在しているようです。

何か見落としているかもしれないので確認できるページを探しましたが、TL3 向け（/admin/users/ID/LOGIN/tl3_requirements）のページしか存在しないようです。

質問ですが、他の信頼レベルの要件を素早く確認する方法はありますか？何が問題なのかを確認するにはどこを見ればよいでしょうか？手動での TL 変更は、正直なところ最後の手段（応急処置）です。なぜなら、他のユーザーが自分の信頼レベルが正しいかどうか疑問に思う可能性があるからです。

2

TL2 に該当するかどうかを確認するには、サイトの設定ページの検索ボックスに「tl2 requires」と入力してください。これにより、サイトの TL2 要件の一覧が表示されます。これらの設定とユーザーのアクティビティを比較するには、ユーザーの管理ページの「アクティビティ」セクションを確認してください。

昇進されないユーザーを確認する際の重要な点として、過去に信頼レベルがロックされていないか確認してください。信頼レベルがロックされているユーザーには、ユーザー管理ページの「権限」セクションに「信頼レベルのロック解除」ボタンが表示されます：

image
image1090×424 31.7 KB

3

それはすでに試しました。TL3 の要件に似たページを TL1 および/または TL2 用に作成して、管理者が Discourse の設定に頼らずに素早く確認できるようにすることを考えていました。

あっ、その情報を付け忘れました、すみません。このユーザーの TL はロックされておらず、記憶では過去にロックされたこともありませんでした。そのため、そのケースではありません。

4

設定とそのアクティビティのスクリーンショットを撮っていただけますか？

5

TL2 の設定（これがすべてですか？それとも何か見落としていますか？）

Screenshot from 2020-06-25 01-01-49
Screenshot from 2020-06-25 01-01-49634×822 55.9 KB

ユーザーのアクティビティ

Screenshot from 2020-06-25 00-59-26
Screenshot from 2020-06-25 00-59-26376×617 17.4 KB

ユーザーの権限

Screenshot from 2020-06-25 01-03-27
Screenshot from 2020-06-25 01-03-271125×461 30.1 KB

6

私も全く同じ問題に直面しています。ユーザーは TL3 の要件（TL2 に欠けている要件レポートによると）をほぼ満たしていますが、まだ TL2 に自動昇格されていません。

@Aylin さん、あなたのインスタンスで原因は見つかりましたか？

私の状況も yours と似ており、そのユーザーの信頼レベルはロックされておらず、統計を視覚的に比較すると、すべての要件（デフォルトのもの）が満たされているように見えます。

ただし、私のインスタンスでは、すべてのユーザーが SSO 経由で作成されており、分析の参考としてこのユーザーを使っています。彼が自動昇格されるはずだと確信しているからです。しかし、私のコミュニティには TL2 のユーザーが 2 人しかおらず、TL1 のユーザーが 996 人います。これは非常に不自然な比率だと思います。

7

確かに不審ですね！

/logs にアクセスすると、非常に頻繁に発生するエラーはありますか？

8

素早い返信ありがとうございます :slight_smile:

記録されたエラーは 1 つだけです：

Log

Message

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’

Backtrace

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’

Env

HTTP HOSTS: forum.comparajogos.com.br

これが関連するかどうかはわかりません。

この 2 人の TL2 ユーザーは、私（管理者）と別のユーザーです。つまり、TL2 の自動昇格は私たち両方で機能しており、私が信頼レベルを手動で変更したことはありません。

自動昇格されなかったユーザーの最低ステータスは、必要な件数であるトピックの返信数が 3 ですが、最後の返信は 9 月 18 日に行われました。

9

Discourse に、ユーザーの信頼レベルを変更するロジックのドライラン機能（何らかのフィードバック付き）があれば素晴らしいと思います。これにより、ユーザーは自身のアクションを実行し、どの要件を満たしているか、満たしていないかを確認できます（バグがある場合でも、すべての要件が満たされているかどうかを確認できます）。

10

いいえ、記憶が正しければログで気になる点は見つかりませんでした。最終的に、その特定のユーザーの TL を手動で変更し、TL2 をブロックしました。そうすることで、フォーラムが TL1 に戻そうとしようとしても試さないようにしました。

11

それらのアカウントは数年前など非常に昔に作成されたものですか？それとも、例えば1ヶ月前など最近作成されたばかりのものですか？
移行時の問題、Discourse の初期バージョン、またはブートストラップモードのサイトが原因ではないかと推測しています。

TL3 については、すでに同様の機能が存在します。
記憶が正しければ、これはスタッフのみが利用可能です。
個人的な意見ですが、TL1〜TL3 の要件チェックリストは透明性のため、すべてのユーザーに公開されるべきです。
これにより、スタッフの作業量が減り、ユーザーから残りの要件について問い合わせるケースも減るでしょう。
一般的に、セルフサービスの方がスケーラビリティが高いです。

12

私も同じ問題に直面しています。私の場合は、TL0 から TL1 への昇格です。主に新規ユーザーでこの現象が確認され、自分でも新規アカウントでテストしました。

image
image752×952 34.2 KB

これは今すぐ作成したテストアカウントですが、確認したほぼすべての実際のアカウントでも同様の現象が起きています。

この投稿を読みました：https://meta.discourse.org/t/when-does-user-trust-level-promotion-occur/29845
以前から自動昇格に問題があったようですが、今回のケースもそれと同じでしょうか？

私の場合は設定が少し変更されていますが、次の投稿で記載します。というのも、私の信頼レベルでは投稿あたりの画像アップロードが 1 枚までしか許されていないためです :grin:

–編集：別の返信を投稿できないため
最小読了時間を 0 に設定したところ、新しいテストユーザーは必要な投稿数を読了した後、正常に昇格しました。しかし、同様の条件を満たす既存のユーザーは現在も TL0 のままです。

13

TL1 の設定を少し変更しました：

image
image911×299 24.3 KB

14

また：
image