アクティビティサマリーが他のメール送信で送信されない

特徴
, ,
1

Admin|Emails|Sent でダイジェストメールがユーザーに送信されなかったことに気づきましたが、ユーザーは全員 user_watching_first_post のメールを受け取っていました（プリセットのデフォルトによる）。

これらのユーザーが最近アクセスしていない、“suppress digest email after days” 設定を過ぎている、またはメール設定を変更したわけではないことを確認しました。

この古い投稿のコメントで、他のメールが送信された場合にダイジェストが抑制されると示唆されています。
Need to confirm that digest mails are being sent - support - Discourse Meta

通知メールはユーザーのアクティビティとして扱われ、ダイジェストがスキップされるというのは正しいですか？もしそうなら、それは私が期待していた動作ではありません…

特定のタグに対して「最初の投稿を監視」を使用しており、ユーザーに優先度の高いトピックを通知したいのですが、他のフォーラムアクティビティの通常のダイジェストも引き続き受け取ってほしいと考えています。

これは私たちのビジョンの中核をなすものです。どのようにすれば実現できるか、ご意見をいただけると幸いです。

「いいね！」 2
2

その通りです。私もあなたの懸念に同意し、以前にこれを設定可能にするよう依頼しました。

現状では、プリセットのウォッチ設定はダイジェスト/サマリーの効果的な使用をある程度妨げています。そして、それはそうである必要はありません。

「いいね！」 1
3

つまり、トピックに関するメール通知を受け取ると、そのトピックが要約に表示されなくなるということですか？すでに別の方法でメールで受け取ったメッセージを要約で受け取りたくないというのは理にかなっています。

4

それはそれ以上にすぎません。電子メール通知を受け取ると、カウントが完全にリセットされるようで、通知よりも古いトピックはサマリーに含まれなくなります。これは常に私を悩ませていました。

基本的に、電子メールで通知されたパンターがサイトを訪問しない場合、前回のサマリーと最後の電子メール通知の間にトピックがまったく表示されません。そして、サマリーがようやく表示されたときに、実際よりもサイトが静かに見えます。

あなたが提案するように、電子メール通知を受け取ったがサイトを訪問しなかったユーザーのサマリーでは、通知されたトピックのみが抑制されるようにしたいと思います。これは、デフォルトで多くの監視を行っているサイトにとっては大きな改善となるでしょう!!

「いいね！」 4
5

確認ありがとうございます、ネイサン。はい、他の新しい対象トピックがあったにもかかわらず、ダイジェストは送信されませんでした。

もしダイジェストが、通知済みのトピックの重複を避けるためだけに機能していたのであれば、それは理にかなっています。しかし、現在行われていることは、見落とし、あるいは非常に逆効果なバグのように思えます。

@pfaffman - これは、何らかの方法でハッキングできるルールでしょうか？それとも開発者の注意が必要なものでしょうか？

「いいね！」 3
6

プラグインが必要になります。以前、私は「要約/ダイジェストメールに新しい投稿の数を3番目の位置（通常は新規ユーザーがいる場所）に追加する」というプラグインを書いたことがあります。そのため、ページ上部のそのヘッダーだけが変更されます。

そのテンプレート全体を上書きするので、それが潜在的な解決策になります。

https://staging.community.pianogroove.com/admin/email/preview-digest

そのようなものが必要な場合は、私または#marketplaceに依頼できます。

「いいね！」 1
8

さらに検討した結果、これはプラグインで無理やり修正するのではなく、バグのように思えます。この動作は意図されたものではないと確信しています。

Site_settings にはダイジェストを抑制するオプションが含まれていますが、他のメール通知に関連するものはありません。

  • ダイジェストメールを日数後に抑制する
  • ダイジェスト抑制カテゴリ
  • ダイジェスト抑制タグ

さらに重要なのは、Emails|Activity Summary のユーザー設定は、「「ここにアクセスしない場合、人気のトピックや返信のメール概要を送信してください。」」であり、はいかいいえのみです。トラッキングメールとの関係は示されていません。

image
image550×461 21.5 KB

これらの設定に基づき、ユーザーはアクティビティ概要設定が説明どおりに、独立して適用されることを期待するはずです。

通知されたトピックをサマリーダイジェストから除外できれば素晴らしいですが、それは贅沢だと考えます。ダイジェストがトラッキングメール通知を認識しないようにするだけで、期待どおりの動作になります。

「いいね！」 2
9

GitHub のコードを興味本位で見ていますが、手に負えない状態です。

app/mailers/user_notifications.rb のダイジェストセクションでは、user.last_emailed_at を考慮した min_date に基づいて topics_for_digest が検索されます。

227行目:

    min_date = opts[:since] || user.last_emailed_at || user.last_seen_at || 1.month.ago

    # Fetch some topics and posts to show
    digest_opts = {
      limit: SiteSetting.digest_topics + SiteSetting.digest_other_topics,
      top_order: true,
    }
    topics_for_digest = Topic.for_digest(user, min_date, digest_opts).to_a
    if topics_for_digest.empty? && !user.user_option.try(:include_tl0_in_digests)
      # Find some topics from new users that are at least 24 hours old
      topics_for_digest =
        Topic
          .for_digest(user, min_date, digest_opts.merge(include_tl0: true))
          .where("topics.created_at < ?", 24.hours.ago)
          .to_a
    end

(編集: last_emailed_at は app/jobs/scheduled/enqueue_digest_emails.rb や spec/jobs/enqueue_digest_emails_spec.rb などでも参照されていることに気づきました。)

これにより、user.last_emailed_at が最近すぎるユーザーのダイジェストは単純に生成されないのではないかと考えられます。

last_emailed_at にカウントされるメールが何であるかを判断できませんでした。明らかにトラッキング設定に基づく通知が含まれますが、プライベートメッセージなどはどうでしょうか…?

ダイジェストは user.last_seen_at のみに関係すべきではないでしょうか？

「いいね！」 3
10

はい、これは私たちが書いた内容からするとバグのように思えます。

image
image714×231 17.8 KB

ここでエンドユーザーがどの程度の詳細度を持つべきか疑問に思います。

私にダイジェストをメールで送信する：無条件 | 圏外にいるとき | 今月あなたから届く唯一のメールである限り
エッジケースは意図的なものであり、人々がメーリングリストとしてDiscourseを使用することに関連している必要があります。

ここで機能を慎重に定義する必要があると思います。機能に移動し、メンバーエクスペリエンスを付与します。

「いいね！」 2
11

サム、ありがとう！

現在、メーリングリストモードが有効になっている場合（少なくともユーザー設定レベルで（次の投稿を参照））、インターフェースはダイジェスト設定が無効になっていることを明確に示しています。

したがって、追加できるのは「常に送信」だけかもしれません。たとえば次のようになります。

アクティビティ概要:
メールダイジェストを常に送信する
ここを訪問しない場合にのみメールダイジェストを送信する
（ドロップダウン）：30分ごと | 毎時 | 毎日 | 毎週 | 毎月 | 半年ごと

しかし、「常に送信」オプションは「あれば嬉しい」機能と見なすでしょう。ダイジェストを他のメールから独立させるだけで、期待どおりに機能するようになるはずです。

（余談ですが、大規模なフォーラムがある場合、利用可能な時間枠を管理者が設定できるようにしたいと思うかもしれません。「常に送信…30分ごと」を選択する人が多すぎると、メール料金が高くなる可能性があります。）

12

これは私が報告した問題の二次的なものですが、メーリングリストモードとアクティビティサマリーに関するサムの懸念に関連しています…

興味深いことに、管理者が「デフォルトのメールメーリングリストモード」と「メーリングリストモードを無効にする」の両方を有効にした場合（シナリオA）、何が起こるかは明確ではありません。ユーザーはメーリングリストモードに関する何も表示されず、アクティビティサマリーやその他のメールを有効にできるようです。

2つの管理者設定は独立しているように見えますが、依存関係があるのかもしれません。「ユーザーがメーリングリストモードを有効にすることを許可しない」は、「デフォルトのメーリングリストモード」をオーバーライドするのでしょうか？

シナリオA

管理者設定、「メーリングリスト」：

image
image648×209 7.75 KB

ユーザー設定|メール：

image
image532×537 11.6 KB

しかし、管理者が「メーリングリストモードを無効にする」オプションのチェックを外さない場合、ユーザーは「メーリングリストモードが有効になっています」とデフォルトで表示されます。これは十分明確なようです。

シナリオB

管理者設定、「メーリングリスト」：

image
image649×208 7.73 KB

ユーザー設定|メール：

image
image555×743 21.5 KB

したがって、メーリングリストモードが実際にアクティブであるかどうかを示すために、シナリオAでは何かが欠けているようです。（私がそれを見落としている場合を除きます。）

13

こんにちは、メンバーエクスペリエンスチームです。これはさらに対応が必要なキューに入りましたでしょうか？

15

レーダーに乗っているか確認しているだけです…

16

この件はすでに@lindseyに伝えましたが、残念ながら彼女はまだロードマップに組み込む時間を確保できていません。

現在、私たちは「まず試してみて、その後で含めるかどうかを検討する」という#pr-welcomeの世界にいると思います。

17

サム、アップデートありがとうございます。私もPRを開発して提供するスキルがあればよかったのですが。

リリースノートには多くの修正と機能強化が含まれていることから、バックログがどのようなものになるか想像するしかありません。しかし、これが注目に値することを願っています。ユーザーは、サマリーが確実に最新情報を提供してくれると疑う理由がありません。

18

@ToddZ 様 — こちらからの連絡が遅くなり申し訳ありません。すべてご指摘いただきありがとうございます。

@sam が申した通り、通知を受け取ったことが訪問とみなされ、アクティビティサマリーメールが届かなくなるのは避けるべきだと私も思います。チームと協力してこの問題を修正し、対応が完了したら改めてご報告いたしますが、現時点ではETA（完了予定時期）をお伝えできません。

「いいね！」 2
20

ありがとうございます、@lindsey！ETAが難しいことは承知しています。作業が進んでいることを知り、アップデートを楽しみにしています。:smiley:

「いいね！」 1
21

ご報告ありがとうございます @ToddZ :+1:

こちらは以下で修正されます。

「いいね！」 3
22

このトピックは44時間後に自動的に閉じられました。新しい返信は許可されていません。

25

@ToddZ さん、このトピックの更新を忘れていたことを思い出させてくれてありがとう。

そのコミットはリバートされましたが、このPRで完全に修正されました。

「いいね！」 4