webixで開発したアプリをインターネット上で利用できる環境構築を支援します。（さくらのレンタルサーバ使用）No.056詳細編-2

前回の記事の継続です。レンタルサーバ上で業務アプリを構築するとき、サーバ側はPHP言語、画面（ＵＩ）は、Javascript言語で開発する手法を採用していますが、PHP言語からDBアクセス方法は、前回、説明しており、今回は、業務アプリを構築する上で検討（初期段階で検討しておく方式）しておく方式について紹介します。
まずは、要件として以下のようなことをどうするかを整理する必要があります。
（１）利用者は複数か
開発した業務アプリは、当然、開発者以外の方も使用されますし、時期によって、使用者も増減するはずです。誰が、いつ、どのような機能を操作しているかを履歴（ログ）で確認することも必要になるかもしれません。
使用者を管理する必要があり、どのように管理するかです。
一般的には、UserIDなどで識別する方法が採用されており、UserIDとしてメールアドレスを使ったり、従業員番号を使ったり、システムが自動的に払い出す方法もあります。
UserIDは、使用者の識別以外に、業務アプリにログイン（UserIDとパスワードでチェック）してから、該当者に機能提供する方式が一般です。
不特定多数の方が自由に業務アプリにアクセスできるような仕様は、情報漏えい、管理情報の予期せぬ編集操作や削除などを防止する上で重要です。
そのログイン機能で使用される情報にUserIDとパスワードなどがあり、最初にUserIDを画面から入力する必要があります。できるだけ手間をかけず、かつ入力ミスを少なくする目的で、UserIDをどのように定義するかです。
１つにはメールアドレスがありますが、メールアドレスの入力は、文字数が多く、スマホなどの場合、手間がかかります。
従業員番号を使う案もありますが、数字のみの場合、先頭が0で始まることの考慮（0を入力しても、数字と判断されると0が消える：例EXCELなど）が必要で、先頭文字は英文字にすべきです。（従業員番号に何らかの英文字を付与して使用する案もあります）
UserIDは、一度ルールを決めると、途中で変更による影響が大きくなりますので、早い段階で、どのように決めるか整理することが大事です。また、スマホでの操作を優先するなら、入力が簡単な文字列にすることの大事です。
数字と英文字を混在すると、入力に時間がかかります。先頭だけ英文字、あとは数字などが簡単です。(会社名の頭文字1文字と従業員番号など）
UserIDの付与ルールが決まれば、同時に管理する情報を決めます。
通常では、UserIDに該当するユーザの氏名、メールアドレス、所属組織ID（店舗ID）など　また、該当UserIDが有効か無効かのフラグなども定義していると、データを削除しなくても、指定UserIDでのログインを無効にすることが可能となります。さらに、ユーザによって、ログイン後の提供メニューが大きく異なるような場合は、ユーザタイプなども定義すると、管理しやすいです。（一般ユーザ、社外ユーザ、管理部門ユーザなど）
これらの情報は、社員マスタ（ユーザマスタ）としてデータベースにテーブルを定義します。システムに最初にログインする人は、テーブルに存在しないとログインができないので、管理者用のUserIDをadminなどで、固定して初期値としてテーブル上に作成しておくと、運用しやすいです。
また、新規にシステムを構築するとき、社員マスタ（ユーザマスタ）は、EXCELやCSVデータからインポートできる仕組みもあると、ユーザ登録の時間を短縮できます。
ユーザを組織や店舗で管理したい場合には、組織マスタも必要になります。
office_id(組織ID)と組織名などで、テーブルを作成し、追加、編集、削除ができる機能も必要となります。
構築した業務アプリを複数のユーザで使用する場合は、該当ユーザの所属する組織やグループをどうするかも重要な検討事項です。できるだけ初期段階で組織情報も定義しておくと、影響範囲を少なくできます。
後述する権限機能とも関係しますので、よく考えて整理が必要です。
以下は、組織情報がないユーザ（新規登録）登録画面の一例です。

（２）提供する機能、メニュー
業務アプリをサービスとして提供する場合、直接は提供しない情報（ユーザ情報や組織情報など）も管理部門では、情報の追加や編集や削除などができる機能が必要となります。１つの機能を公開するとしても、バックには、さまざまな情報を管理する機能が必要となることを理解してシステムを構築する必要があります。
その中には、提供機能名（メニュー名）の管理機能も必要です。
どのような機能を公開するか、公開しないか、その機能はどのようなURLで公開するか、また該当機能が使える端末にはパソコンだけなのか、スマホも対象にするかなども決める必要があります。さらに、メニュー操作以外に、専用のボタンでメニューを選択するような機能を実装する場合、ボタンにメニュー名以外に、アイコンを表示させるようにしたい場合やボタンの色を指定したい場合、各メニュー単位に、アイコンや色指定などの管理も必要です。ユーザの要望を考慮すると、さまざまな情報をメニューとして管理が必要となります。この辺りも初期段階で検討する事項となります。
以下の機能は、一例です。

（３）ユーザとメニュー機能
誰にどのような機能を提供するか、全てのアクセスユーザが同じ条件で機能を提供することは、まれで、一般的には、通常ユーザ、管理者ユーザなどいくつかのグループを作って、提供する機能を分類することが通常です。
ただ、経験から記述スルト、グループで管理する方針であったとしても、最後は、ユーザ個人単位に、この機能は、有効にするが、この機能は無効にする要望が発生し、管理が最終的には個人単位になるケースが多いです。
また、人事異動などで、組織を異動する場合、一定期間、両方の組織が使える機能を該当者に使えるようにするケースも多く、最終的には、人単位に、機能を選択できるようにしておかないと難しいことが多く発生しています。
紹介する方式は、個人単位に、機能を提供するしないを決める方式です。
以下、設定例です。管理者ユーザに提供する機能

一般ユーザに提供する機能

上記のように、メニュー名単位にアクセスできるかを指定するとともに、対象機能に対する権限情報も同時に指定します。
権限情報の例ですが、権限値が12862は、以下の意味となります。

ビット単位に権限を指定しており、対象ビットが1のとき、対象権限を与える意味となります。
閲覧のみ可能とするか、編集操作や削除操作を許容するかなどを指定します。
一般ユーザでは、同じメニューに対し、以下の権限のみ与えています。

削除権限がないので、新規作成した情報の編集や閲覧はできても、対象レコードの削除はできない動作となります。削除したい場合は、削除権限のあるユーザに削除操作を依頼す必要があります。項目の削除を制限することで、誤って情報を削除してしまうリスク回避にもなります。操作履歴や詳細情報をログなどで保存すれば、誤って削除したデータを復旧することも可能となるので、対象情報の重要性などを考慮してシステムの機能を検討する必要があります。
（４）その他
メニューは、プルダウンメニューや、ボタン操作メニュー、機能名をキーワードで検索してメニューを選択するなどの機能を実装できますが、ボタンを使う場合は、ボタンの色やアイコンも決める必要があり、管理情報の対象となります。
以下は表示例です。
webixでは、Material Design Iconが使えます。

ボタンの背景色も指定して確認しやすいボタンにすることも可能です。

以上記載した以外にもさまざまな業務アプリを管理するシステムでは、共通機能の実装が必要です。うまく整理して構築すれば、さまざまな要件に柔軟に対応できる仕組みを構築できるので、参考にしてください。