最初は、要件が反発され、後に提案された最初のものがありました。
- アプリケーションシステムに参加しないが、その循環統計を記録する必要がある2000人を少し超えるユーザー
- 約30人のスタッフが3〜4つの部門に分かれており、上司と全員がヘルプデスクにアクセスできます。
- 企業内でのみ使用するシステム
- メール/ SMS通知
- レポートと統計
- ユーザーベース（少なくとも部分的にActiveDirectoryに理想的）
開発者としての私の立場は、phpとmysqlをサポートするオープンソースのオープンソース製品のセグメントに基づいていました。 最初は、それらは考慮されていました： OsTicketは非常にシンプルですが、同時に多くの機能があり、それはマイナスです（多くの「切り取りと非表示」があり、追加する必要があるもの）。 また、より深刻なソリューション-OTRSには、LDAPを操作するための組み込みツールがあります。 彼は、クライアントIDを入力すると、彼に関するすべての情報が収集されるアプリケーション作成フォームが特に好きでした。 そして、私は「中間」を望んでいました。 一般的な結論は、特定の要件に適切なものはありませんが、後者はインターフェースのために、少なくとも一部の要件を無視できるということです。 php / jqueryプロジェクトの開発経験がほとんどないため、独自のシステムを作成することにしました。
主なタスクは、すべてのアプリケーションのアカウンティング、管理者によるレポートと制御、この段階またはそのタスクの段階です。 たとえば、部長が夕方に部下の翌日のタスクを決定し、部下の優先順位を選択できます。 そして部下は、仕事に来てすぐにタスクのリストを見て、特定の時間内にそれらを完了することができました。
そのため、明確な技術的なタスクはありませんでした。 したがって、システムとそのモジュールの構造を大まかに決定しました。
モデルからわかるように、ユーザーの「個人的なメッセージ」のシステムも使用したいと思いました。 しかし、将来このベンチャー企業は姿を消したが、代わりに以下を追加することにした。
- アプリケーションについて議論したり、その実装をサブスクライブしたりできるように、アプリケーションページに関するコメント
- アプリケーションを3つのカテゴリに分割します：受信トレイ、送信トレイ、アーカイブ（しばらくするとアプリケーションは自動的に分類され、ステータスは「完了」になります）
- ナレッジセンター（関心のある質問への回答を見つけ、アプリケーションを作成せずに問題を解決できるセクション。指示、マニュアル、ドキュメントがある場合があります）
- メモ帳（個人のメモやメモを保存し、それらへのリンクを共有できます）
- すべてのユーザーアクションのログ
多くの時間と作業がアプリケーションの作成プロセスに費やされました。 上で書いたように、私はOTRSのアプローチが好きでした。 したがって、クライアントが電話をかけたときに、以前のアプリケーションと電話の回数を知って、顧客を特定できるように、顧客ベースを満たす必要がありました。 私たちでは、顧客情報の一部はActive Directoryに保存され、別の部分はdoc形式の電話帳に保存されていました。 ADでは、名前、ログイン、電子メール、およびグループ（ユニット）のみがありました。 docディレクトリには、名前、電話番号、キャビネットがありました。 一緒になって互いに補完し合った。 これら2つのソースでは、情報の単位が一致しない場合があります。 たとえば、LDAPには約2,000のエントリがあり、ディレクトリには1,200のエントリがあり、そのうち約1,000が一致しました。 まあ、それで十分でした。
顧客ベースを満たす
プロセスはいくつかの段階で決定されました。
- ADからのインポートはPHPを介して行われました。 標準的にLDAPに接続し、必要な情報を引き出します。
- docディレクトリからのインポートは、はるかに興味深いものでした。 まず、必要なテーブルデータをxlsに転送し、フォーマットしてCSVで保存しました。
- 次に、MySQLテーブルへのインポートはphpスクリプトによって行われました。このスクリプトは、LDAPレコードとsqlレコードをループし、名前を比較しました（これが共通していた唯一のものです）。
その結果、会社の顧客に関する情報の1000以上のレコードを含むコレクションテーブルがあります。 アプリケーションを作成するときに、電話番号、氏名、またはログインを入力して、クライアント、彼の通話数、最近のアプリケーションに関する情報を見つけることができます。
コーディング
これは、このようなファイル編成を選択した最初のプロジェクトではありません。 おそらくこれは「デザインパターン」と呼ばれ、私が間違っていれば正しいでしょう。
私にとって、このような「コミュニケーション」ファイルの編成は、より論理的でシンプルに思えました。 すべてが属する場所にあります。 actions.phpファイルは、主に「リクエストの作成」、「リクエストのブロック」、「クライアントの追加」などのアクションブロックで構成されています。 特定の名前のPOST要求がそれに送信され、コードの必要な部分が呼び出されます。 ページ上のイベントの説明に関しては、 core.jsがこれを担当します。
アプリケーションの動き
アプリケーション自体の動きについて詳しく説明する必要があります。 原則として、申し込みを受け入れるすべての人員からオペレーターまたはアテンダントである1-2人がいます。電話で80％、その場で20％です。 私たちは、アプリケーションを作成する前であっても問題を解決することが重要であると常に考えてきました。 そして、この問題/タスクが従業員の能力にない場合、彼はそれを関連部門または特定の人に送ります。 アプリケーションの受信者が部門を選択している場合、この部門（そしてもちろん部門長）の一部である全員にそのようなアプリケーションが表示されます。 特定の人物が選択された場合、その人物と上司はそのようなアプリケーションを見ることになります。 アプリケーションは、部門の他のユーザーには表示されません。
アイデアは、アプリケーションに注意を払わずに放置するのではなく、そのフルフィルメントのステータスを常に部門の責任者が監視できるというものです。
開発プロセスでは、ユーザー権利の3層システムを作成することが決定されました。
一番下の行は、メイン管理者がすべての部門とすべてのユーザーのアプリケーションを見るということです。 コーディネーターは特定の部門に属し、この特定の部門のすべてのユーザーのアプリケーションを確認します。 ユーザーには、自分の部門（全員）に送信されるアプリケーション、または特に彼に送信されるアプリケーションのみが表示されます。 彼は、彼の部署の他のユーザーへのアプリケーションを見ません。
しばらくして、衝突に直面しました。ユーザーは物理的に1つの部門に入りましたが、実際には作業は他の部門に隣接していました。 また、他の部門からのアプリケーションを見る必要がありましたが、権限は異なります。 そのため、アクセス権の「垂直-水平」方向の考え方が生まれました。 垂直-これらはユーザー権限でした：管理者/コーディネーター/ユーザー。 そして水平に-これは、彼が一般的な権利で入ることができる部門のリストです。 これらの行が交差する論理的なポイントは、システムへの一般的なアクセス権でした。
テストを行ったところ、新しいアプリケーションが登場したときにあまり目立たないことがわかりました。 たとえば、あるモニターのユーザーはブラウザーでヘルプデスクを開くことができますが、新しいアプリケーションが表示されても何も表示されません。 良くない。 そして、人気のあるソーシャルネットワークでポップアップメッセージを作成することにしました。 これらは、次のようなさまざまなアクションで動作します。
ポップアップメッセージを処理するには、特定のページで2秒ごとに208バイトのajaxリクエストを送信し、サーバー上のスクリプトに「ユーザーに何か新しいものがありますか？」と尋ねます。 もちろん、完全な「美」のために、これはソケットを通して行われます。 しかし、今のところ私たちはこれに至っていません。 また、タイトルページのちらつきの効果を追加し、タブのタイトルがはっきりと叫んだ：「ここで何かが更新されました。注意してください」。
ごく最近、私たちはjabberメッセンジャーを実装しました。 そのため、すぐにヘルプデスクを接続し、新しいアプリケーションの通知がジャバーになりました。 一部の従業員は職場にいませんが、クライアントと協力しています（ソフトウェアのインストール、サービス機器）。 したがって、彼らは新しいアプリケーションの通知に特別な注意を払っています。 最も最適で簡単な方法はSMS通知です。 便利なサービスを見つけ、APIを使用してシステムを統合しました。
統合
重要なポイントは、IT部門の既存のユーザーであるアプリケーションシステムへのアクセスを得ることでした。 ログイン/メールのホワイトリストを作成しました。 その本質は次のとおりでした。Web経由でログインするときに「最初のログイン」リンクをクリックし、LDAPログインのみを入力します。 作成されたパスワードと彼がシステムへの完全なアクセスを取得するためのリンクが記載された電子メールが彼のドメインメールに届きます。 したがって、タスクはシステム管理者から各課題アカウントに削除されました。
何を得たの？
- マルチレベルのユーザー権利システム
- JQuery指向のインターフェース構造
- 電子メールアドレスの「ホワイトリスト」からシステムに登録する機能
- 電子メール、SMS、およびその他のシステムによる新しいアプリケーションの通知
- ユーザー設定
- 言語サポート：ウクライナ語、ロシア語、英語
- アプリケーションイベントポップアップメッセージ（VKなど）
- ナレッジセンター-権利構造を持つドキュメントファイル、手順、ヘルプファイルのセクション
- メモ帳-リンクを共有する機能を持つユーザーの個人用ノート
- アプリケーション統計
- 番号、名前、クライアントログインによるアプリケーションの「スマートな」作成
- アプリケーションの優先順位
- アプリケーションでのコメントとチャット
- アプリケーションのすべてのユーザーによるすべてのアクションの完全なログ
- そして別の...
おわりに
このようなシステム時間を記述することがいかに便利で正当であったかがわかります。 それまでは、「モンスター」に変えないようにしますが、同時にいくつかの機能を追加します。アプリケーションへのファイルのアップロード、統計などを追加します。 私の個人的な批判的な意見は、システムは非常に機能しているが、まだコードを操作する必要があるということです。 あなたの批判とコメントを聞いて、プロジェクトの開発へのあなたの貢献を見ることができてとてもうれしいです。
Github： リンク