RGJ
2022 年 1 月 17 日午後 11:10
1
しばらく考えていたのですが、ここにアイデアを投げかけて、皆さんの意見を聞いてみたいと思います。
ここ数ヶ月、多くの人と話をしてきました。彼らは、既存の（公開されている）コミュニティサポートフォーラムに加えて、サポートチームが（機密性の高い）クライアント固有の問題を解決する、直接的なクライアントサポートを立ち上げようとしています。
#1 ：クライアントごとに個別のカテゴリ/グループを作成するこれは、クライアントの数が比較的少ない場合にのみ機能し、数百いる場合には機能しません。
ここでの主な欠点は、「（…）専用のチケット発行プラットフォームを作成している、または少なくとも Discourse Web インターフェイスのユーザーとサポートチケットをリクエストするユーザーの間には重複がないということです。」
しかし、このトピックは主要な問題の1つに対処しています：「セキュリティ/権限システムを確認しましたが、望むものが見つかりません。基本的に、純粋な作成および作成/返信の権限は存在しません 。」これは後で詳しく説明します。
#3 ：グループ受信トレイ。サムの元のアイデア「Discourse をプライベートメールサポートポータルとして使用する 」がグループ受信トレイになりました。グループ受信トレイを設定し、サポートチームに割り当てると、誰でも受信トレイにメッセージを送信またはメールで送信できます。
しかし 、私はそれをあまり好きではありません。
私の意見では（！）、このアプローチにはいくつかの欠点があり、そのうちの3つは次のとおりです。
サポートグループに送信されたメッセージは見つけにくい（実際、通知をクリックしない限り、IMHO すべてのメッセージは見つけにくい）です。サポートスタッフは良い概要を持っていますが、ユーザーは持っていません。チケットに取り組んでいるスタッフユーザーは個別のグループ受信トレイを見ますが、チケットを作成したユーザーは、通常のPMの間にそれらを見つけることしかできません。
PMでのタグ付けサポートの欠如：スタッフのみがPMにタグを付けることができ、ユーザーはタグを表示またはフィルタリングできません。
メッセージを送信できる「場所」がありません。サポートチームにメッセージを送信する可能性は、どこかで明示的に宣伝する必要があります（そして、論理的な場所を見つけるのが難しいと感じています。ほとんどの場合、何らかのバナーに落ち着きます）。
全体として、私にとっては 、カテゴリトピックとPMの間の妥協であり、少し「付け足し」のように感じられます。
#4 プライベートトピックこのアイデア は数回提案されており（ここ 、ここ 、ここ でも）、上記で「作成」および「作成/返信」の権限について言及しました。
「ドロップボックス」のようなカテゴリがあり、人々がトピックを開始してサポートスタッフ（基本的にグループ）とやり取りでき、そのトピックは彼らとグループのメンバーだけが見ることができるとしたらどうでしょうか？
これは、このユースケースにとって特効薬となるでしょう。すべてのユーザーが自分の（そして自分のだけ の）サポートチケットを見ることができる、明確に定義された「サポート」カテゴリがあります。すべてが1か所にあり、タグなどをすべて使用できます。
しかし、@codinghorror と @sam の両方から、トピック固有の権限は実現しないと何度も言われています（多くの複雑さが加わるため、完全に理解できます）。
前進するには2つの方法があると思います。グループ受信トレイを使用し、それらの欠点が解決されることを期待するか、プライベートトピックのアイデアに再度挑戦するかです。
その間、トピックごとの権限を「いじる」または実装するいくつかのプラグインが登場しました。Restricted Replies （カテゴリでの返信を特定のグループのみに許可する）や Discourse Private Replies （返信をトピックの開始者（およびスタッフ）以外には誰も見えなくする）などがあり、実現可能に見えるため、プラグインで再度試してみることを検討していました。
しかし。
これに進む前に、興味があります。
グループ受信トレイに関する私の意見を他の人も共有しているかどうか。これらの認識されている欠点は非常に主観的である可能性があることを認識しています。
プライベートトピックプラグインのアイデアに関する（あらゆる）フィードバック。
「いいね！」 24
Heliosurge
2022 年 1 月 18 日午後 7:54
4
これは確かに非常に良い議論のトピックです。
プライベート返信は、あなたのアイデアに沿ったものを考案するために、おそらくフォークできるでしょう。しかし、それには、プラグインの作者と協力して、スポンサー付きのプラグインフォークのようなものを行うことができる、知識のある誰かが必要になります。スポンサーシップがあれば、クラウドファンディングのコンセプトを探求する素晴らしい方法になるでしょう。
Github: GitHub - communiteq/discourse-private-replies
This plugin hides topic replies for everyone but the topic starter and the post author.
グループメールボックスは素晴らしいアイデアですが、私の意見では、PMシステムには使いやすい検索オプション、またはフォルダオプションを使用したグループブックマークが必要です。たとえば、クライアントA 2020年10月のリクエストなどです。
「いいね！」 7
元の文脈を知らずに言うと、トピック固有の権限は、#4
私がこれを機能させると想像する方法は、カテゴリ権限を拡張して「自分のものを見る」を含めることです。現在の権限と同様に、「見る」または「自分のものを見る」のいずれかが、追加されたグループに対して許可されなければなりません。
作成を許可すると自動的に返信が許可されるため、作成のみを許可するカテゴリは、トピックを作成できない場合、意味がないでしょう。
これは、権限の領域で「わずか」2つの追加の変更しか必要としないと思います。現在のユーザーが属するグループが「自分のものを見る」権限しか与えない場合：
トピックリストは、現在のユーザーが作成したトピックにフィルタリングされる必要があります。
トピックは、現在のユーザーによって作成されたものでない限り、アクセスが拒否される必要があります。
実際には、最新トピックリストのようなものに対処する追加の複雑さがあると思いますが、おそらく（おそらく…）それほど多くの追加作業ではないでしょう。
RGJ:
グループ受信トレイに関する私の意見を他の人と共有する場合、これらの認識されている欠点は非常に主観的である可能性があることを認識しているため。
現在、Discourseでプライベートサポートを行っていないため、直接の経験はありませんが、私の認識はあなたの認識と一致していると思います。
サポートを求める場所を見つけることと、現在および過去のサポートクエリを確認することの両方において、発見可能性は重要です。これは、グループPMアプローチでは困難になる可能性があります。
「いいね！」 7
RGJ
2022 年 1 月 18 日午後 10:23
6
フィードバックありがとうございます！私はその特定のプラグインの作者であり、私たち（Communiteq）は、これが正しい方向であると感じられれば、これに投資する準備ができています。したがって、それらのことは問題になりません。
はい、その通りだと思います。
しかし、自分のものを見る は作成する を意味し、作成する は返信する を意味し、返信する は見る を意味するため、これが正確にどのように構造化されるかについては、まだ少し苦労しています。しかし、自分のものを見る が見る を意味するようにしたくはありません。
「いいね！」 8
ええ、これは思ったよりも複雑なようです。返信は実際には「見る」を意味するのではなく、カテゴリの権限にグループが追加されるとすべて意味するようです。
権限は列挙型であり、グループは readonly、create_post、または full のいずれか1つのみを持ちます。ユーザーが特定のカテゴリで返信/作成できるかどうかを判断するには、ユーザーが（返信のための create_post または full、またはトピック作成のための full）を持つグループのメンバーであるすべてのカテゴリのリストを取得し、関連するカテゴリがそのリストに含まれているかどうかを確認します。
トピックの作成は簡単で、列挙型に full_own のような追加の値があれば、category.rb の TOPIC_CREATION_PERMISSIONS 定数に追加するだけで機能します。ユーザーが関連するカテゴリに対して full または full_own のいずれかを持っている場合、トピックを作成できます。
返信はより複雑ですが、ユーザーが full_own を持つすべてのカテゴリを返す追加のスコープを追加するのが適切だと思います。たとえば次のようになります。
OWN_TOPIC_POST_CREATION_PERMISSIONS ||= [:full_own]
scope :own_topic_post_create_allowed, -> (guardian) { scoped_to_permissions(guardian, OWN_TOPIC_POST_CREATION_PERMISSIONS) }
次に、post_guardian.rb の can_create_post? に次のような追加条件が必要です。
(!SpamRule::AutoSilence.prevent_posting?(@user) || (!!parent.try(:private_message?) && parent.allowed_users.include?(@user))) && (
!parent ||
!parent.category ||
Category.post_create_allowed(self).where(id: parent.category.id).count == 1 ||
(parent.is_my_own? && Category.own_topic_post_create_allowed(self).where(id: parent.category.id).count == 1)
)
しかし、自分のトピックのみを見て、それが関連するカテゴリページ、最新、検索、およびその他の場所で真であることを保証することは、はるかに困難に見えます。まだ解決していません。
「いいね！」 6
ここでの最も簡単な解決策は、3番目のドア、つまり、メールでサポートを求めるユーザーだけでなく、ログインしたユーザーにもうまく機能するグループ受信トレイを改善することだと思います。
RGJ:
サポートグループに送信されたメッセージは見つけにくい（実際、通知をクリックしない限り、すべてのメッセージは見つけにくいと私は思います）し、サポートスタッフは全体像を把握できますが、ユーザーはそうではありません。チケットに取り組んでいるスタッフユーザーは個別のグループ受信トレイを見ることができますが、チケットを作成したユーザーは、それらを「通常の」PMの間で見つけることしかできません。
PMでのタグ付けサポートの欠如：スタッフのみがPMにタグを付けることができ、ユーザーはタグを表示したり、タグでフィルタリングしたりすることはできません。
メッセージを送信できる「場所」がありません。サポートチームにメッセージを送信する可能性は、どこかに明示的に宣伝される必要があります（そして、私は論理的な場所を見つけるのが難しいと感じています。ほとんどの場合、それは一種のバナーに終わります）。
グループ受信トレイに関するあなたの主な不満は、ユーザー側の機能の欠如にあるようです。これは、ユーザーがチケットを追跡するためにログインし、サイト上の他のユーザーと話すためにPMも使用している場合、正当なものです。私は、メタでサポートを提供するためにグループ受信トレイを使用する上では、これまでにあまり遭遇していません。グループ受信トレイを通じてサポートを提供しているほとんどのユーザーは、ログインすることはありません。彼らは主に自分のメールを使用しており、自分のメールを使用して、必要に応じて私たちとのやり取りを整理およびアーカイブできます。
メタで@support-teamsを通じて通信しているユーザーが数人いるので、彼らにどのように機能しているか、そして何か提案があるか尋ねます。また、これが現在どのように機能するかを自分でさらにテストします。リクエストは次のとおりです。
スタッフ以外のユーザーがメッセージタグを表示できるようにする（現在、スタッフのみがタグを表示できます。非スタッフが表示できるタグをメッセージに提供するために、タググループを使用できるかもしれませんか？
ユーザーがグループとメッセージをやり取りしているときに、グループ受信トレイへのリンクをメッセージメニューに提供して、グループとの自分のメッセージを表示できるようにする（これはスタッフには機能しますが、スタッフ以外にはどのように機能するかはわかりません。受信トレイとアーカイブには問題があり、ユーザーごとに個別に制御されていません）
グループへの新しいメッセージを開始するためのリンクを提供する（メッセージングが許可されている場合、グループページに存在すると考えられます）
グループへの新しいメッセージを開始する機能は、Discourse for Teamsのメールサポートを提供するために@support-teamsグループのメンバーである私でさえ気づいたことです。サポートチームから新しいメッセージを開始したい場合は、サポートチームと書きたい相手のメールアドレスの両方を含める必要があります。これは少し面倒です。
また、グループ受信トレイの使用方法では、トピックを解決したときにメッセージを閉じることは通常ありません。アーカイブするだけです。これにより、解決したメッセージを非表示にできますが、顧客がメールでフォローアップしてメッセージを受信トレイに戻すこともできます。
「いいね！」 5
これは、あまり考えていなかった非常に興味深い点です。メールサポートでは、顧客が新しいメールを送信するのではなく、古いメールを見つけて返信することがよくあります。トピックが閉じられている場合、メールが拒否された場合、混乱を招く可能性があります。
ドア番号4の後ろでは、それがどのように実現されるにしても、特にサポートスタッフの数が増えると、対処されていないトピックを特定することがスタッフ側にとって困難になるでしょう。顧客が古いトピックに返信した場合、さまざまなサポートスタッフが注意が必要かどうか、または他のスタッフがすでに解決したかどうかを知ることができないため、Solvedプラグインは実際には役に立ちません。
「いいね！」 6
RGJ
2022 年 1 月 19 日午後 7:48
11
full、create_post、readonly をいじるのが正しい方法かどうかはわかりません。なぜなら、full と create_post は多くの場所で「すべて表示」を意味するからです。その方法では、保守しやすいプラグインを作成するのは簡単ではありません。さらに、あまり直感的ではないと思います。
また、トピックの作成者が、たとえばメンションすることによって、追加の人（たとえば同僚）をトピックに追加できるとクールですが、このメカニズムでは不十分です。
現時点での私の考えは、権限はそのままにして、セキュリティグループの下にセクションを追加することです。
[x support staff] [x sales support]
プライベート返信プラグインで同様のことを行いましたが、その場合はカテゴリ内のトピックではなく、トピック内の投稿に対して行いました。TopicGuardian のいくつかのパッチでかなりのところまで進むと思います。
はい、それは非常に簡単な解決策になる可能性があります。私のリクエストの要約は正確であり、メッセージをトピックと同等にするための追加の 2 つの点を見つけました。
フォーラムを検索すると、検索クエリに in:private を明示的に追加してメッセージを検索する必要があります。時々、それが（多かれ少なかれ公開の）トピックだったのか、グループへのプライベートメッセージだったのか、本当に覚えていません。デフォルトで含めるのはどうでしょうか？
さらに、ハンバーガーメニューの右側のタブにメッセージへの簡単なリンクがあると良いと思います。はい、封筒のアイコンがありますが、それはメッセージのリストであり、/my/messages へのリンクではありません。その画面は隠されているように感じます。
ドロップダウンの項目は、次の画面のタブの一部と同じですが、Messages と Badges を除きます。そのため、メッセージに移動する必要があるときは、常に Summary をクリックしてから Messages をクリックします。
ドロップダウンの項目を比較してください
プロフィール画面のタブと比較してください
Summary、Activity、Invites、Preferences は両方にありますが、Drafts は一方に、Notifications、Messages、Badges はもう一方にあります。そのため、「Messages」は私にとっては非常に隠されているように感じます（Notifications と Badges も同様ですが、それほど頻繁には使用しません）。
「いいね！」 7
RGJ:
フォーラムを検索するとき、メッセージを検索するには、検索クエリに明示的に in:private を追加する必要があります。時々、それが（多かれ少なかれ公開の）トピックだったのか、グループへのPMだったのか、本当に思い出せません。デフォルトで含めるのはなぜですか？
良い点ですね。この障壁の背後にある考えが何なのか分かりません。メッセージ内にいるとき、デフォルトで in:personal が追加されることにも気づきましたが、それは良いことです！しかし、グループの受信トレイのメッセージのみを検索するために in:support-teams のようなものが追加されるわけではありません。これは良いアイデアだと思います。高度な検索にも、私が知る限り、グループの受信トレイでフィルタリングする簡単な方法はありません。（cc @pmusaraj ）
これは良いアイデアですが、そのプルダウンのスペースの問題があると思います。そのリストには7項目以上置きたくないでしょう。また、ほとんどのコミュニティでは、メッセージングを宣伝したくないと思います。人々には公開で話してほしいのです！メッセージで話している人にとっては、通知プルダウンやメール通知などが、注意が必要なメッセージへの十分なジャストインタイムアクセスを提供します。
とはいえ、メニューシステム（キーワード：sideburger）の改善に積極的に取り組んでおり、この問題を考慮に入れます。Discourse for Teams のサイドバーは、すでにグループの受信トレイや監視タグへの簡単なアクセスを提供しており、sideburger プロジェクトとともにコアの Discourse にも取り込むことができます。
これは、Discourse for Teams サイトの Kabissa グループ受信トレイにいるときに表示されるものです。
「いいね！」 5
tobiaseigen:
グループへの新規メッセージ作成リンクを提供する（メッセージ送信が許可されていれば、グループページに存在すると思います）
グループをサポートグループとして指定し、それに基づいてハンバーガーメニューのエントリを作成することについて考えています。状態は以下のようになります。
サポート指定グループが0件の場合、メニューエントリなし
サポート指定グループが1件の場合、「サポートにメッセージを送信」というエントリが表示され、グループへのメッセージ作成を開始します。
サポート指定グループが2件以上の場合、「サポート」というエントリが表示され、メッセージボタンを備えた指定グループすべてを表示するグループページのようなページにリンクします。
おそらく、追加のメニューエントリとページはやりすぎかもしれません。Aboutページに追加の生成セクションを設けるのはどうでしょうか？
RGJ:
さらに、ハンバーガーメニューの右タブにメッセージへのシンプルなリンクがあると良いと思います。はい、封筒のアイコンがありますが、それはメッセージのリストであり、/my/messagesへのリンクではありません。その画面は隠れているように感じます。
完全に明白ではありませんが、これはメッセージタブにあります。メッセージリストの一番下にある下向き矢印をクリックすると、/my/messages画面に移動します。Summary、then Messagesよりもクリック数が少ないわけではありませんが、ページロードは1回少なくなります。
もし私がKabissaにメッセージを送信するユーザーだったら、そのトピックはグループと主な関連付けを持つのでしょうか、それともトピックは私とKabissaグループのみがアクセスを許可されているという以上のものにはならないのでしょうか？
もしグループと主な関連付けを持つ場合、私のメッセージページに、アクセス可能なメッセージのみを含める形になりますが、同様にKabissa受信トレイを表示することは可能でしょうか？
「いいね！」 6
metaでtl0ユーザーを作成してテストしたところ、サポートチームのグループページに移動して「メッセージ」ボタンを選択し、グループにメッセージを送信することができました。メッセージを投稿すると、送信済みメッセージフォルダに届きました。これは機能していますが、場合によっては少し埋もれすぎているかもしれません。必要に応じて、ハンバーガーメニューにリンクを追加したり、ホームページのバナーに追加したりできます。したがって、これ以上行うべきことはあまりないと思います。
スクリーンショットのKabissaの受信トレイは、Kabissaグループのユーザーにのみ表示されます。Kabissaにメッセージを送信するユーザーは、自分のメッセージにメッセージが表示されます。
「いいね！」 5
jomaxro
2022 年 1 月 19 日午後 9:00
15
RGJ:
フォーラムを検索するとき、メッセージを検索するには、検索クエリに明示的に in:private を追加する必要があります。時々、それが（多かれ少なかれ公開の）トピックだったのか、グループへのPMだったのか、本当に思い出せません。デフォルトでそれらを含めるのはなぜですか？
in:all が存在することに注意してください。これにより、公開と個人メッセージの両方が1つの検索に表示されます。
私の記憶が正しければ、アイデアは個人メッセージと公開トピックの分離を強制することでした。何が公開で何が個人なのかについての混乱を最小限に抑えるためです。とはいえ、グループ受信トレイはその分離をかなり曖昧にします。
「いいね！」 8
サポート固有のグループの発見可能性を高めることを考えていました。ハンバーガーメニューにリンクを追加することは、単一のサポートグループを持つコミュニティ（実際、私の目的には理想的です）には確かに適していますが、多くのサポートグループを持つコミュニティでは、指定されたグループ用に生成された「概要」ページまたはセクションからメリットを得られる可能性があります。
今思えば、コミュニティが必要とする場合は、これはプラグインに適している可能性が高いです。
私が（おそらく下手な）質問をしようとしていたのは、このモデルが、現在やり取りしているが所属していないグループのフィルタリングされた受信トレイをユーザーに表示できるようにするのに十分な情報を持っているかどうかということです。これは、@RGJ の、グループに送信されたメッセージが見つけにくいという懸念に関連しています。
たとえば、Discourse for Teams サイトの通常のユーザーである私が、Kabissa グループに送信したすべてのメッセージを表示する Kabissa 受信トレイをメッセージで確認できることです。（または、おそらく私が参加しているメッセージ）。
私の疑念は、そうではないということです。おそらく、参加しているユーザーやグループのいずれかである参加者しかいないでしょう。
「いいね！」 7
schungx
2022 年 2 月 1 日午後 2:59
17
これが広まっているのは素晴らしいことです！なぜなら、Discourseはプライベートサポートチケットにとって素晴らしいシステムであり、うまくいけば、それは実に素晴らしいからです。
Discourseがそのために設計されていないこと、そしてDiscourseに本来の目的とは異なることをさせようとしていることは十分に承知していますが、プライベートインボックスとメイントピックの完全な機能と特徴の間では、後者を選ぶでしょうし、無理やり押し込もうとし続けるでしょう…
「いいね！」 4
これは私たちが（比喩的にも文字通りにも）サポートしたいと考えていることですが、「サポートツール」という枠に押し込められたいわけではありません。
私たちは常に耳を傾けています
「いいね！」 8
jrgong
2022 年 2 月 2 日午前 7:30
19
素晴らしいアイデアです！コミュニティ内でも、ユーザーの受信トレイとは別にサポートチケットを求める声があります。ユーザーが自分のチケットのみを見ることができるこのようなカテゴリは非常に役立つでしょう。
「いいね！」 4
jerry0
2022 年 4 月 6 日午後 12:39
20
ありがとうございます！
プライベートサポートにはPMグループを使用しています。これはうまく機能しています。サポートシステムのヘビーユーザーからの主な不満は、メッセージを検索できないことです。
検索クエリにコードin:personalを追加する必要があることを彼らに教えようとしましたが、直感的ではなく、率直に言って、ユーザーが実際にこれを実行できているのを一度も見たことがありません。彼らは単に諦めて、メッセージを検索できないと不平を言うだけです。
検索ボックスの下にあるこの「提案」が何のためのものなのかさえ理解していません。
そして、高度な検索に移動した場合、おそらく「メッセージを検索」ラジオボタンをチェックするほど高度かもしれませんが、それがin:personalという単語を追加すると、すべて奇妙に見え始め、その時点で彼らは諦めてしまいます。
検索ボックスにコードを追加せずにメッセージを検索する、より直感的な方法があれば、それは大幅な改善になるでしょう。
そうでなければ、単にコード「in:messages」のように、より直感的な言語を使用するだけでもわずかな改善になります。
「いいね！」 6
pfaffman
2022 年 4 月 6 日午後 12:45
21
それか、デフォルトで検索にPMSを含めるのはどうでしょうか？
「いいね！」 4
jerry0
2022 年 4 月 6 日午後 3:04
22
確かに、それは素晴らしいでしょう！
「デフォルトでPMを検索」という設定（通常はオフ）があれば、理想的です。
そうすれば、通常のトピックとPMのトピック（私にはありません）の検索結果が混同されることへの懸念は、PMのトピックをまったく検索できないこと（私にはあります）とバランスが取れるでしょう。
「いいね！」 3
）
この役割においてDiscourseをより良くするための具体的なフィードバックがあれば、ぜひお知らせください。
