バグの説明を含む電子メールを解析する最良の方法は何ですか。あるクライアントは最近、ユーザーが既知のメールボックスに電子メールを送信できると便利であり、バグがバグトラッカーに登録されると判断しました (厳密にはクローズではありません)。
問題は、バグの説明に、日付、時刻、説明、コメント、損失、添付ファイルなどのフィールドがたくさんあることです。特定のメール形式を使用するようにユーザーに依存することは、最も賢明なことではありません。
問題は、電子メールを解析して必要なすべての情報を取得するにはどうすればよいかということです。形式は厳密ではありませんが、どのフィールドが何を意味するかを推測するには十分です。また、これに対する正しい解決策と最も簡単な解決策の両方を聞きたいと思います。
PS 実際、この機能は銀行からリクエストされました。クライアントが発見した問題を送信する公開メールボックスがあります。問題は、銀行員が実際に手紙を見る前に、これらの手紙からできるだけ多くの情報を取得することです。
これと似たようなことを RT でも行いますが、メールは実際には解析されません。すべての電子メールは単一のキューに入れられ、IT スタッフによって評価されます。基本的に、解析は人間が行います。人間は、電子メールから収集できる情報をできるだけ多く持つようにチケットを変更します。
ユーザーが従業員であるか、高度な訓練を受けているか、またはルールに従う何らかのインセンティブを持っている場合を除き、思いついた特別な構文やフォーマットにユーザーを (正しく) 従わせることはまずありません。
もう 1 つのオプションは、最初の電子メールにアンケート形式の電子メールを返信させることです。つまり、ユーザーが最初のバグ レポートを作成すると、すぐに (または電子メール サーバーが応答できるようになるとすぐに)、「ありがとう - 詳細情報を提供できますか?」というメッセージが返され、詳細情報のプロンプトが表示されます。次に、その電子メールを解析して、バグ追跡システムにより正確な情報を入力することができます。
幸運を！クールなアイデアですね！
FogBugzには、電子メール アドレスを監視し、そのアドレスに送信された電子メールを新しい FogBugz ケースとして追加する機能があります。
HTTP GET 引数を受け取り、それらを使用して新しいケースを送信するScoutSubmitという機能もあります。アプリケーションがフィールドからバグレポートを自動的に送信するのに非常に便利です。
自由形式のテキストに基づいてバグを分類することは難しい命題です。欠陥の提出者の名前とバグが報告された日付以外は、電子メールから簡単に拾い集められるものはほとんどありません。メールに限定している理由はありますか？Web ページを介してバグを送信するためのフォームを提供する場合、ユーザーに提示するドロップダウン メニュー項目に基づいて欠陥/バグを分類できます。さらに、ページの動的な情報部分で一般的な回答を示すことができます。Apple iTunes のサポート リクエスト ページを参照して、ユーザーに適切な情報を提供するよう強制する、少し煩わしいが効果的な方法を確認してください。バンキング アプリケーションは、あいまいさを許容するのに適したドメインではなく、複数回の通信を行うのに適したドメインでもありません。