PR

[OTRS] 簡単なカスタマイズ

システム上の設定変更

Frontend::Customer

CustomerHeadline

Example Company Support

CASEY.jp Support

CustomerLogo

ロゴを変更したいときは差し替えるか、別のアドレスを指定する。

skins/Customer/default/img/logo.png

CustomerPanelSubjectLostPasswordToken

New OTRS password request

新しいパスワードのリクエスト(Password request)

CustomerPanelBodyLostPasswordToken

「Hi <OTRS_USERFIRSTNAME>,
You or someone impersonating you has requested to change your OTRS
password.
If you want to do this, click on this link. You will receive another email containing the password.
<OTRS_CONFIG_HttpType>://<OTRS_CONFIG_FQDN>/<OTRS_CONFIG_ScriptAlias>customer.pl?Action=CustomerLostPassword;Token=<OTRS_TOKEN>
If you did not request a new password, please ignore this email.」

「こんにちは <OTRS_USERFIRSTNAME> さん
パスワード変更リクエストがありました。
もし、パスワードの変更を行うなら以下のリンクをクリックしてください。
パスワードを含む別のメールが届きます。
<OTRS_CONFIG_HttpType>://<OTRS_CONFIG_FQDN>/<OTRS_CONFIG_ScriptAlias>customer.pl?Action=CustomerLostPassword;Token=<OTRS_TOKEN>
あなたが新しいパスワードを要求していない場合は、このメールを無視してください。」

スポンサードリンク

CustomerPanelSubjectLostPassword

New OTRS password

新しいパスワード

CustomerPanelBodyLostPassword

「Hi <OTRS_USERFIRSTNAME>,
New password: <OTRS_NEWPW>
<OTRS_CONFIG_HttpType>://<OTRS_CONFIG_FQDN>/<OTRS_CONFIG_ScriptAlias>customer.pl」

「こんにちは <OTRS_USERFIRSTNAME> さん
新しいパスワードをお知らせします。
New password: <OTRS_NEWPW>
<OTRS_CONFIG_HttpType>://<OTRS_CONFIG_FQDN>/<OTRS_CONFIG_ScriptAlias>customer.pl」

CustomerPanelSubjectNewAccount

New OTRS Account!


新しいアカウント

CustomerPanelBodyNewAccount

「Hi <OTRS_USERFIRSTNAME>,
You or someone impersonating you has created a new OTRS account for you.
Full name: <OTRS_USERFIRSTNAME> <OTRS_USERLASTNAME>
User name: <OTRS_USERLOGIN>
Password : <OTRS_USERPASSWORD>
You can log in via the following URL. We encourage you to change your password via the Preferences button after logging in.
<OTRS_CONFIG_HttpType>://<OTRS_CONFIG_FQDN>/<OTRS_CONFIG_ScriptAlias>customer.pl」

「こんにちは <OTRS_USERFIRSTNAME> さん
新しいアカウントを作成しました。
氏名(Full name)      :<OTRS_USERFIRSTNAME><OTRS_USERLASTNAME>
ユーザー名(User name):<OTRS_USERLOGIN>
パスワード(Password) :<OTRS_USERPASSWORD>
ログインするには以下のリンクをクリックしてください。
<OTRS_CONFIG_HttpType>://<OTRS_CONFIG_FQDN>/<OTRS_CONFIG_ScriptAlias>customer.pl」

ユーザ画面を姑息にカスタマイズする

優先度を選択させない

優先度を選択できるのだが、ユーザによっては混乱する原因にもなってしまうので、姑息な手段で隠しておく。

CustomerTicketMessage.dtl


<!-- dtl:block:Priority -->
 <div>
 <label for="PriorityID">$Text{"Priority"}:</label>
 $Data{"PriorityStrg"}
 <div></div>
 </div>
<!-- dtl:block:Priority -->



<!-- dtl:block:Priority -->
 <div style="display:none">
 <label for="PriorityID">$Text{"Priority"}:</label>
 $Data{"PriorityStrg"}
 <div></div>
 </div>
 <!-- dtl:block:Priority -->


リッチテキストを使うかどうか

システム上で Core::Web 内のFrontend::RichText を選択することでリッチテキストを使用するかどうか選択できる。しかし、これらは共通になっていて(オペレータではなく)ユーザーには使わせないなどの細かな設定ができない。もちろんソースを見ながら修正を行えば期待した結果を得られるだろうが、以下のように逃げることもできる。

CustomerRichTextEditor.dtl


Core.Config.Set('RichText.ToolbarFull', [
 ['Bold', 'Italic', 'Underline', 'Strike', '-', 'NumberedList', 'BulletedList', '-', 'Outdent', 'Indent', '-', 'JustifyLeft', 'JustifyCenter', 'JustifyRight', 'JustifyBlock', '-', 'Link', 'Unlink', '-', 'Image', 'HorizontalRule', '-', 'Undo', 'Redo', '-', 'Find', 'SpellCheck'],
 '/',
 ['Format', 'Font', 'FontSize', '-', 'TextColor', 'BGColor', 'RemoveFormat', '-']
 ]);
 Core.Config.Set('RichText.ToolbarSimple', [
 ['Bold', 'Italic', 'Underline', 'Strike', '-', 'NumberedList', 'BulletedList', '-', 'Outdent', 'Indent', '-', 'JustifyLeft', 'JustifyCenter', 'JustifyRight', 'JustifyBlock', '-', 'Link', 'Unlink', '-', 'HorizontalRule', '-', 'Undo', 'Redo', '-', 'Find', 'SpellCheck'],
 '/',
 ['Format', 'Font', 'FontSize', '-', 'TextColor', 'BGColor', 'RemoveFormat', '-']
 ]);
 Core.Config.Set('RichText.ToolbarFull', []);
 Core.Config.Set('RichText.ToolbarSimple', []);

検索をシンプルにする

細かく検索ができるようになっているが、シンプルにしてしまう。こちらも姑息な手段で見せたくないものをコメントアウトするだけ。

CustomerTicketSearch.dtl

<!--
 <fieldset>
 <h2>$Text{"Search-Profile as Template?"}</h2>
 <div>
 <label for="SaveProfile">$Text{"Save as Template?"}</label>
 <input title="Save as Template" type="checkbox" id="SaveProfile" name="SaveProfile" />
 </div>
 <div>
 <label for="Profil">$Text{"Template Name"}</label>
 <input title="Pick a profil name" type="text" id="Profil" name="Profile" size="30" value="$QData{"Profile"}" />
 </div>
 </fieldset>
-->


チケット関連設定

Core::Ticket にチケット関連設定項目がある。以下は主な物。

Ticket::Hook

チケット接頭語

Ticket::NumberGenerator

チケット番号の生成方法

データベースに項目を追加する

データベースに項目を追加するなどはマニュアルの110ページくらいに詳しく記載されている。対応ファイルは Defaults.pm など。

コメント

  1. zuckey より:

    管理者様

    業務でトラブルチケットシステムを役立てようとあがいている田舎の中年サラリーマンです。
    当方もRTとOTRSの二択で検討し、RTが良かれと思って取り組んだのですが、RTのメール設定(Postfix)辺りで挫折してしまい、結局ものにならず、時間がないこともあって設定が簡単そうなOTRSに行き着き、管理者様のWEBサイトに行き当たりました。

    OTRSに関する日本語情報がほとんどないので、内容、とても参考になります。この記事を最後にOTRSの新規情報がないのがとても残念です。

    今後は自分で掘り下げていくとして、1つ教えて下さい。

    この手のシステムで当方が絶対に欲しい機能として、ナレッジベース機能があります。

    いろいろな案件を対応し、その対応をシステム上に蓄積していった時、後になって以前のと同様の案件を抱えると言うことが多々あります。
    その際、前はどう対処したんだっけか?となります。

    そうした際にナレッジベース機能があると非常に有用だと思いました。RTにはその機能がありようです。

    OTRSには同様の機能が備わっているでしょうか?

    自分なりに調べてみて、ITSMというのがその機能を持っているのかなぁ?と思っているのですが確証がありません。

    もしご存じでしたらお願いします。

  2. admin より:

    コメントありがとうございます。
    駄記事ですが、少しでもお役に立てたなら嬉しく思います。

    OTRS はチケット型のサポートシステムで、寄せられた内容をナレッジベースにする機能があったと思います。
    OTRS::FAQか、おっしゃるOTRS::ITSM かがそれに該当したように記憶しています。

    すべて単一のシステムで行えるメリットもあるのですが、それに特化した使いやすいナレッジベースシステムを使うのも選択肢ではないかと思います。
    多言語型FAQシステム「phpMyFAQ」を利用する方法もありますし、WordPress を利用してしまう手段もあります。

    前者はFAQ用に開発されていますが多少クセがある印象でした。

    WordPressは、WordPressそのものをFAQとして利用するほか、FAQ用プラグインなども用意されています。
    豊富なテーマを利用できるメリットや、プラグインを使い容易に多数の画像を挿入することもできますし、一部または全部を会員にだけ見せる事もできます。

    どのように利用されるかにもよりますが、サポートシステムに問題があったときに(FAQへの)外部接続を切ったとしても、OTRSを利用してのサポートは継続できますし、OTRSと関連しないFAQシステムにしておけば全体のダウンを防ぐこともできます。
    (利便性とセキュリティー、負荷調整などの両立は難しいのでリスクマネジメントです)

    ただOTRSでFAQも運用すると、FAQへのリンク挿入が簡単にできたような気がします。
    (OTRS については現在も試行錯誤していますが、記事にできるまでの成果が出ていません(;・∀・))

    //質問に対する直接の回答にならず、すいません

  3. zuckey より:

    管理者様

    zuckeyです。当方の質問に対し、迅速かつご丁寧なレスを下さり誠にありがとうございます。
    phpMyFAQのことは名前だけ存じておりました。
    「へぇー、最近こんなのもあるんだ」程度ですが。

    FAQとナレッジベース機能との関連性が字面だけからだと判りづらいような気がするので教えて下さい。

    (1)FAQというのは「良くある質問とその答え」と思います。
    (2)ナレッジベースというのは、過去の記事蓄積から検索語を元に関連記事なり語句なりを抽出するといったイメージを個人的に思い浮かべます。

    (1)と(2)は似てるけど別のものなのかも、と思ってますが、内容的(できること)にはほぼ同じものと考えて良いのでしょうか?

    私がしたいのは、過去にある案件に対処したとして、それから時間が経って同様の案件を抱えた時、過去の対応を簡単に検索し内容を見たい、と言ったものです。
    年とるとどうしても記憶力がなくなり、結果として過去の対応がどうであったか忘れてしまうので、必要性を富に感じます。

    phpMySQLで同じことができるならそれでも良いような気もするのですが、OTRS機能にFAQが内包され、連携が良いようならそちらを使った方が良いように思います。

    ただ管理者様がご助言して下さったチケットシステムとFAQを別にする、と言う視点は持てていなかったので参考になりました。ありがとうございます。

    質問ついでにOTRSについてもう1つ質問させて下さい。

    OTRSの設計思想に関することなのかも知れないのですが、顧客なり職場関係者が問題を抱えた時、OTRSの公開Postmasterメールアドレスに内容をメールしてもらってチケットのスタートとすれば良いのかと思いますが、それとは別に顧客専用のWEBアドレスが用意されているというのは、どういう使うわけを想定しているのでしょうかねぇ?
    トラブルについて、メールでもWEBでも、電話でも受け付けますよ、ということでしょうか?

    当方のOTRSの使い方としては職場内に限定されています。
    相手は職場関係者ばかりなので顧客はおらず、チケット受付の案内をするとしたらPostmasterメールアドレス公開か、従前通り電話対応で事足りるだろうし、WEBに入力しろ、とか言ったら反発を浴びそうです。

    WEB入力による方法もメリットがあるのだろうか?

    お手数ですが、再度お願いします。

  4. admin より:

    コメントありがとうございます。
    厳密に言えば、FAQとナレッジベースは異なるとは思いますが、「何を使うか」の他に「どのように使えるか」も検討すると良い場合があります。
    zuckey さんは少なくとも”蓄積された過去の案件に対する検索”と”以前どのように対応したかを忘れることがある”という要求定義があるように思います。

    「案件の蓄積」は、どのようなシステムでも可能だと思います。単なるテキストファイルでもよく、ブログ型CMS でも、グループウェアでもナレッジベースでも良いわけです。自分か利用者の多くが利用しやすいシステムを採用すると良いと思います。

    おそらく最も重要なのは「検索」です。
    単純に検索するなら、どのシステムにもたいてい付いています。テキストファイルならgrep などで検索してもよいでしょう。
    しかしこれでは該当する案件が多くなればなるほど「検索結果から検索する」時間が増えてしまいます。
    将来の検索に備えて、例えばこのサイトならタイトルに[Windows7] など幾つかのルールを予め決めておくことも良いと思います。
    その他に、検索後の重要性を評価する「重み付け」に対応した検索システム(Namazuなど)で検索可能にする方法もあると思います。
    さらに、検索については評価の高いGoogle のエンジンを利用してしまう方法もあります。

    また、今あるシステムが唯一絶対ではなく、将来よりよりシステムが登場する可能性もあります。
    もし長く利用するのであれば、データの移行が可能かなども検討すると良いと思います。

    たくさん検索してコレだと思うシステムに出会い、構築した直ぐ後に、より優れたシステムに出会うこともあります。
    場合によっては、今回の要求に応えてくれるシステムを作成またはカスタマイズしてくれる業者と接触することも有益かもしれません。

    限られた時間や予算の中で、よりよい結果をシームレスに得るには、あらゆる可能性と情報を得ることが有益だと思います。

    OTRS がウェブアクセスに対応していることで最も私が感じているメリットは、「メッセージの不達がなくなる」ことです。

    今回のzuckey さんの場合はおそらくあてはまらないと思いますが、一般ユーザと連絡を取りたい場合に、迷惑メールになってしまったり、ケータイ電話メールへメールが送信できなかったりと様々な問題に直面します。
    これらの対応をを多くのユーザに求めることは、本来の要求に応えるまでのハードルが高くなってしまいます。

    しかし、ウェブアクセスが残されていれば、仮にメール送信が可能なシステムがすべて失われたとしても、ウェブにアクセスできる端末が残されていれば連絡手段が確保されます。
    また、ユーザ側の問題によりメッセージの不達が問題になったとしても、ウェブアクセスがあることで対応履歴が残されおり、トラブルを最小限に留めることができるかもしれません。
    ユーザによっては頻繁にメールアドレスを変更するものもあれば、多くのメールアドレスを持っているものもおり、必ずしもこれらを使い分ける能力持ち合わせていないこともあります。

    とはいえ、最低限のメールマナーさえ守って貰えないことも多くあります。
    この場合、OTRS の標準で良いされた機能では少し対応に弱いように思います。
    おそらく対応手段はあると思いますので、現在はその辺を勉強しようと思っています。

    # チケットシステムは、まだまだ日本では馴染みが薄いですね・・

  5. zuckey より:

    管理者様

    ご質問しましたzuckeyです。
    大変有益なご助言を長文で頂戴しまして恐縮です。ありがとうございました。
    また返信が遅くなりすみませんでした。

    情報の蓄積より検索の方が大事だし、そのためのツールは色々ある、というご指摘、参考に致します。

    OTRSですが、あの後色々あれこれいじっているのですが、どうも私的にRTに較べて使いづらいような印象を持ちました。
    例えばTicketを「担当する」という操作1つとっても、OTRSではどうやれば良いのか判りません(未だに。)

    直感的に操作しづらいのはどうもなじめない。
    そんなもんですから、今さらまたRTをいじっています。

    RTとOTRSの間を行ったり来たり、で、我ながら情けない状況ですが、チケットシステムの運用実用化だけは何としてもものにしたいと思っています。
    でも、RTもOTRSも日本語情報が少なくて、当方のような未熟者にはなかなかハードルが高い作業です。

    また質問させて下さい。

    どうもありがとうございました。