ウォッチ中のデフォルトカテゴリ設定をリセット

こんにちは。

すべてのユーザーの デフォルトのカテゴリの監視 をリセットしようとしていますが、うまくいきません。

設定エリアではカテゴリが選択されていないように見えますが、ユーザー設定にはいくつかのカテゴリが選択されています。

「いいね!」 2

こんにちは、@ufukayyildiz さん

この問題の進め方について、何か分かりましたか?私も同じことを試した際にいくつか問題が発生し、結局全く機能しなくなってしまいました^^ 参照: Members not receiving emails from Watched category (again)

「いいね!」 3

いいえ、まだです。

「いいね!」 2

ユーザーの選択を尊重するように設計されていると思います。そのため、ユーザーが手動でカテゴリを追加した場合、それは上書きされません。

Railsコンソールから何か魔法のようなことができるかもしれませんが、より良いアプローチはユーザーに教育することだと思います。どう思いますか?それとも、デフォルトを何が何でも変更する必要がある特定の状況がありますか?

「いいね!」 1

ご返信ありがとうございます。

ユーザー設定をコピーするための rails console コマンドがあれば大変助かります。ユーザー設定がサイト設定よりも優先されるという設計上の選択は完全に理解しています。しかし、サイトとその組織は進化していくものです。

私たちのケースでは、すべての告知が新しいトピックとして投稿される組織から、5つの専用トピック(告知の種類)を持つ組織に移行しました。これにより、フロントページに議論されていないトピック(投稿1件のみ)が大量に表示される結果となりました。この件について、私が2023年2月に調査を開始したことがわかります Unlist or archive a post when it has no reply per category

これらの告知は関連性があり、締め切りも含まれているため、フロントページから非表示にするという選択肢はありませんでした。そこで、各投稿が新しい告知となる5つの専用トピックに移行しました[^1]。それでも、これらの投稿は重要であるため、ユーザーがリアルタイムで通知されるように、カテゴリを「監視中」に設定しようとしました。

これが現在、user_mentioneddigest 以外は誰も何も受け取っていない状況につながった始まりです。ユーザー設定をすべて新しいサイトのデフォルトにリセットできれば、移行ははるかに簡単だったでしょう。あるいは、別のアイデアとして、仮想 の新規登録ユーザーの設定を他のすべてのユーザーにコピーすることも考えられます[^2]。

その間、システムが意図したとおりに機能しない場合があること、そして通知メールが未定義の期間送信されないことをユーザーに伝えました。

[^1] ここで、「トピックへの返信」のみを有効にできると非常に便利です。
[^2] 現在、これは rails を介して可能であると想像できます。

こんにちは。引き続き調査していますが、当社のケースでは、サイトの構造が変更され、メール通知の動作方法が変更されたため、ユーザー設定をリセットすることが理にかなっています。

Discourse AI から、次の Rails コマンドが提案されました。

UserOption.update_all(email_digests: true, email_level: 1, email_messages_level: 1)

これで目的を達成できると思いますか?
よろしくお願いします!

以下の手順で問題が解決したと思います!

サイト設定で、カテゴリ(31)をデフォルトで、遡って購読するように設定しました。
確認:

CategoryUser.where(category_id: 31).pluck(:user_id, :notification_level)

ほとんどのユーザーは、私のカテゴリ「31」に対して notification_level3 になっています。:+1:

これで、この変更が100%効果を発揮するには、2つのことが障害となります。

  1. ユーザーのグローバルメール設定。
  2. カテゴリ(31)の各トピックのユーザー通知設定。

:warning: 以下の行は、ユーザーの個人設定を変更します。争いにならないようにしてください。

まず、ユーザーのメールを「再アクティブ化」するために、ユーザーの email_level を 1(「不在時」)または 2(「常に」)に設定する必要があります。

UserOption.update_all(email_level: 1)

確認:

UserOption.group(:email_level).count

=> {1=>X} のような結果が得られます。ここで X はユーザー数です。

次に、トピックの notification_level は、カテゴリの notification_level(サイト設定で変更されたもの)よりも優先されます。最も簡単な方法は、トピック設定を削除することです。これを行うには、トピックごとにエントリを削除するだけです。

TopicUser.where(topic_id: <トピックID番号>).destroy_all

確認:

TopicUser.where(topic_id: <トピックID番号>).exists?

=> [ ] のような結果が得られます。これは、ユーザーがトピック設定を持っていないことを意味し、カテゴリの notification_level がすべてのユーザーのデフォルトになります。


追記:なぜか、一部のユーザーはカテゴリ(31)の通知設定がまだ設定されていませんでした(つまり、category_user テーブルにエントリがありませんでした)。 notification_level が設定されていることを確認するには、notification_level の値を持つエントリを作成する必要があります。

User.find_each do |user|
  unless CategoryUser.exists?(user_id: user.id, category_id: 31)
    CategoryUser.create!(user_id: user.id, category_id: 31, notification_level: 3)
  end
end

確認:

CategoryUser.where(category_id: 31).pluck(:id, :notification_level)