さまざまなバックグラウンド管理システムには多様なニーズがあるため、ここで共有するものは汎用的なものであり、ほとんどのバックグラウンド管理システム ロジックに十分であり、主に Web サイト管理バックグラウンド、CMS、CRM、OA などの WEB アプリケーションで使用されます。 、など待ってください。
もちろん、彼をさらに設計して、より強力なシステムを作成することもできます。
アクセス許可に関する問題は複雑な問題であることが多く、システムのアクセス許可制御に関しては、既存の事例を参考にして独自のアクセス許可制御を設計することがよくあります。最も一般的なアクセス許可制御方法を 4 つまとめました。（高忠実度プロトタイプのリンク＋全体構造図を添付：下部参照）
1. 制御システムのアカウントとログイン
1. ログインするには、まずアカウントとアカウントの定義が必要です。
基本的に、モバイル、PC、C エンド製品、B エンド製品など、すべてのインターネット製品にはログインするためのアカウントが必要です。Cエンド製品のみ、ユーザーご自身で登録が可能です。
バックグラウンド製品の場合、社内担当者がアカウントを作成する必要があります。そして、このアカウントがキーとなり、アカウントの権限を制御することで、この従業員の業務範囲を制御します。
2. 2 つのレベルのアカウント: エンタープライズ (管理者) アカウントと通常のアカウント
企業の実際の運営者は、最も中心的で最も権限のあるエンタープライズ アカウントを持っている必要があるため、「管理者アカウント」とも呼ばれ、その他は通常のアカウントです。
実際のシステムにおける主要なビジネス ステップは次のとおりです。
- 企業がシステムを購入すると、企業アカウントが作成され、この企業アカウントに関連付けられた携帯電話番号が、企業の実際のオペレーターの携帯電話番号になります。携帯電話番号は、必要に応じてバインドを解除したり変更したりできますが (会社のオペレーターが変更された場合など)、エンタープライズ アカウントを削除したり、退職したりすることはできません。
- 導入トレーニング フェーズ中に、エンタープライズ アカウント所有者は 1 つ以上の通常アカウントを作成するように指示できます (ただし、そのアカウントには管理者ロールが許可されます)。このアカウントは通常、管理ディレクターまたは人事ディレクターに許可され、その後の構成は次のようになります。管理者アカウントによって実行されます。
2 つの違いに注意してください。
- アカウントが無効になっている:システムにログインするときに間違ったパスワードを複数回入力すると、アカウントのセキュリティ上の問題により、システムはそのパスワードを一時的に無効にします。または、アカウントが盗まれた場合、または他のシナリオが関係している場合は、ただちにアカウントを無効にし、パスワードを変更するなどの操作を行う必要があります。
- アカウントの無効化:従業員は退職しましたが、勤務中のすべての操作記録情報が残っているため、アカウントが無効化されるように設定されます。(追記: 人事システムを使用すれば問題ありません。従業員が退職すると、すべてのシステム アカウントが自動的に無効になります。)
ユーザーステータスにステータス制御を追加すると、利用可能なユーザーはシステムにログインできますが、無効または無効なユーザーはログインできません。
2. 役割管理
役割は多くの場合、ビジネス管理要件に基づいてシステム内で事前に設定された固定ラベルです。各役割は明確なシステム権限に対応します。これは集合概念であり、多くの最小限の権限の要素で構成されます。アカウントの権限は、ロールに権限を付与し、次にアカウントにロールを付与することで認識され、ブリッジとして機能します。ロールの概念を導入すると、アカウントに複数のロールを持たせることができるように柔軟に拡張できます。
通常、所有するシステム権限は自由に変更されず、ユーザーが追加または削除されてもロールが変更されないため、ユーザー管理よりも安定しています。
会社が拡大するにつれて役割が増えて管理が難しくなりますが、例えば人事の役割であれば、グループに支社がある場合、上海支社：人事部長、北京支社：人事、というように分類することができます。監督。
このロールによって付与されるデータ権限は異なります。中小企業の場合は、ロールをきめ細かく管理する方が便利です。
3. 制御機能の権限
機能権限定義：閲覧・操作できる機能の範囲です。例: メニューの特定の部分、または特定のページ内のさまざまな操作。
1. メニュー管理モジュール
ディレクトリ、メニュー、ボタンの3種類があります。
- ディレクトリやメニューに権限制御を追加すると、権限を持つ人は対応するモジュールにアクセスでき、権限がない人はメニュー名すら見ることができなくなります。
- ビジネスモジュールの機能ボタンに権限制御を追加することで、ユーザーの行動を最も細かい粒度で制御することができ、例えば女将が商品入力権限を持っている場合、商品入力ボタンが表示され、ボタンをクリックすると入力することができます。そうでない場合、そのような許可はなく、店員は商品入力の操作を行うことができない。
2. 制御機能の権限管理
基礎となるメニュー管理構成は通常、開発者によって早い段階で構成され、現在、ユーザーはこれらの機能権限を使用するように割り当てられています。
機能的権限: 役割に基づいて、異なる役割の異なる機能的権限を分割し、従業員を対応する役割に追加することにより、次のような従業員の機能的権限の分割と分離を実現できます。
- オブジェクトレベルの機能：機能の入り口が見えるかどうかなど 例えば、役割が「シロナガスクジラ監視員」で、オブジェクト「人事管理」の「リスト参照」権限ポイントが解除されている場合、その配下の従業員はロールでは人事管理の機能の入り口を見ることができなくなります。
- 操作ポイント権限: 作成や編集などの業務操作など。
- フィールド権限: 情報を表示するときに権限制御を追加して、機密情報のセキュリティを確保します。オブジェクト フィールドは、読み取り/書き込み、読み取り専用、または非表示としてロールを構成できます。例: ロール「サービス担当者」の販売注文の [販売注文金額] フィールドを非表示に設定します。
従業員に対するフィールドの表示と編集可能性を制御します。たとえば、テレマーケティング担当者に顧客の電話番号を表示したくない場合や、サービス担当者に顧客の販売注文の販売注文金額を表示したくない場合は、次の操作を行うことができます。対応するフィールドを非表示にします。
- [読み取りおよび書き込み]権限: 従業員はこのフィールドに対して最大の権限を持ち、[新規] および [編集] のときに編集でき、このフィールドはリスト ページと詳細ページに表示されます。
- [読み取り専用]権限: [新規] [編集] の場合、従業員は編集できません。このフィールドはリスト ページと詳細ページに表示されます。
- [非表示]権限: フィールド (またはこのフィールドの値) は、[新規]、[編集]、[リスト]、[詳細] のインターフェイスで従業員に表示されません。
フロントエンド インターフェイスに対する関数のアクセス許可の影響:
- 従業員がオブジェクトの「リストを表示」する権限を持っていない場合、オブジェクトの関数エントリは非表示になります。
- 従業員がオブジェクトに対する操作ポイント権限を持っていない場合、対応する操作ボタンはオブジェクト ページ上で非表示になります。
- 従業員がオブジェクトの特定のフィールドに対する表示権限を持っていない場合、対応するフィールドはオブジェクト ページで非表示になります。
3. 制御フィールド許可ユーザー インターフェイス
制御フィールドの権限はページ構成ページでサポートされる必要があり、このインターフェイスは開発者によって制御されます。
設定するページをクリックすると、このページに属するフィールドを追加したり、データベースからすばやく生成したりできます。このページのフィールドからどのフィールドを選択するかは、ユーザーがフィールド権限を設定するために提供されているため、上記の図があります。フィールドの表示名と同様に、フィールドが必須かどうかも、フィールドの権限を設定するためにユーザーに提供されるインターフェイスを制御します。
4. データ権限の制御
データ権限の定義: データ権限管理は主に、特定のデータレコードがユーザーに表示されるかどうかを制御します. 機能権限と組み合わせることで、ビジネスプロセス内の各従業員の機能操作権限とデータ可視範囲をより柔軟に設定できます。企業データのセキュリティを保証します。
マトリックス リストと同様に、機能権限によって、顧客オブジェクトに表示される名前、電話番号、電子メール アドレスなどのフィールドなど、ユーザーに表示される列が決まります。データ権限により、ユーザーがどのデータを表示できるかが決まります (例: 「王氏」、「李氏」など)。
データ権限は、データを制御するために 2 つのレベルに分かれています。
- データ基本権限：データ担当者に応じて決定されます。
- データ共有:基本データ権限のデータ レコードに従って、他のユーザーと共有して表示または編集します。
基本的なデータ権限:
- プライベート: オブジェクト内のすべてのデータは、関連するチーム メンバー (担当者を含む) とその上司がデータに表示され、このデータに対して同じ権限 [読み取り専用、編集可能] を持ち、部門長も同じ権限を持っていることになります。上位部門は下位部門のすべてのデータを参照できます。
- 公開読み取り専用: オブジェクト内のすべてのデータが全社に公開され、1 つのデータの担当者とその上司、および編集権限を持つ関連チームのメンバーがデータを編集できます。
- パブリック読み取りおよび書き込み: オブジェクト内のすべてのデータは会社全体に公開されており、すべての従業員が編集できます。
備考:ここでの「上位」とは、ユーザー管理インターフェイスで編集できるユーザーのレポート オブジェクトを指します。
システムの初期化の開始時にはデフォルト設定が適切です（デフォルト設定は顧客企業の実際の運用に基づく必要があります）。ユーザーは企業の発展に応じてデフォルト設定を変更したり、デフォルト設定を復元したりできます。デフォルト設定は顧客企業のシーンの 90% をカバーするためです。
データ権限の共有:
データ共有ルールは、特定の部門/従業員(データソース)の特定のオブジェクト(顧客など)を担当するすべてのデータを、特定の部門、個人、またはユーザーグループ(共有範囲)に共有することです。データ共有ルールが設定されると、共有当事者は、共有当事者が担当するすべてのデータを表示できるようになり、共有権限に対応する操作権限を持ちます。
ビジネス構成の説明:
- データソース：共有する必要のあるデータ。従業員を選択するとその従業員が担当する記録データを参照し、部門を選択するとその部門の従業員が担当する記録データを参照します。
- 共有データ: 共有するオブジェクトを選択します。たとえば、従業員 A が担当する顧客データを従業員 B と共有します。
- データ共有先: 共有するには、従業員、部門、またはユーザー グループを選択でき、選択した従業員、部門、またはユーザー グループのメンバーは共有データを参照できます。
- 共有後の権限: データを表示または編集するための共有パーティの権限を構成します。「読み取りおよび書き込み」権限として構成されている場合、共有データに対する共有パーティの権限を、共有データに対する共有者の権限と比較できます。充電。
ビジネス シナリオの例: 営業部門は、財務部門の Zhang San に部門のすべての販売注文データを参照させ、編集できるようにしたいと考えています。
(1) 共有ルールの設定
- [データソース] は「sales one」です。
- 【共有データ】は「受注書」です
- [共有範囲]は「Zhang San」です。
- 【共有権限】は「読み書き」です。
(2) 設定完了後
設定が完了すると、Zhang San は、[Sales Order] オブジェクトと [Shared to me] シーンで、営業部門の全従業員が担当する販売注文を確認できるようになります。
要約する
バックグラウンド権限管理システムはできる限り複雑ではなく、顧客の実際のニーズを満たし、最大限の柔軟性を備え、開発コストを効果的に制御できる権限システムのみが合理的な設計となります。