実践 権限管理の基本 (3) 権限レベルと部署/ユーザー

前回に引き続き、セキュリティロールである。

今回は権限レベルに関して記載する。

エンティティに対する権限レベルとしては以下の5つが存在する。

①[選択なし] 権限なし

②[ユーザー] 自分にだけ権限あり

③[部署] 同じ部署の範囲で権限あり

④[部署配下] 同じ部署及び配下の部署の範囲で権限あり

⑤[組織全体] すべてのデータに対して権限あり

横には簡易な説明を記載した。

これはあくまで簡易であり、ポイントは主語である。

主語は「レコードの所有者が」である。所有者が何であるかがポイントである。

※例えば、これを意識しないと[作成]の[ユーザー]権限の意味合いが捉え難いと思われる。

これはレコード初回保存時は自分が所有者であるレコードしか作成できないという意味である。

また、部署は「部署エンティティ」と「ユーザーエンティティ」の関係を意味している。

以下、実際の画面で説明する。なお、①と⑤は省略する。また確認は[読み込み]だけを行う。

まず、検証するためのデータ構造を説明する。

部署構造は以下のとおりである。

ルート部署の配下に[営業本部]-「営業1部]-[営業1課]と[営業2]が同列である構造を作成した。

20140926_001

次にユーザーであるが、[crmuser1]と[crmuser2]が同じ[営業1課]に所属するよう設定を行った。

20140926_002

検証するデータ前回作成したカスタムエンティティを利用する。

データは以下で作成している。3つのユーザーがそれぞれ1つずつ所有者となっている。

20140926_003

この状態で、crmuser1に以下のようにユーザー権限を付与する。

20140926_007

実際のレコードは以下のように表示される。

20140926_008

説明のとおり、自分が所有者であるレコードのみが表示される。

この状態からセキュリティロールを以下のように部署に変更する。

20140926_009

実際のレコードは以下のように表示される。

20140926_010

 

crmuser1とcrmuser2は同じ営業1課の部署に所属している。

権限を部署にすることによって同一部署のユーザーが所有者となっているレコードが表示された。

次はさらにこの状態から、crmuser1が上位の部署である、営業1部に変更となった場合を確認してみる。

※部署変更後はセキュリティーロールが外れるため、再度適用することに注意する必要がある

20140926_011

実際のレコードは以下のように表示される。

20140926_012

移動したことにより、同一部署のユーザーはcrmuser1のみになったためである。

次はさらにこの状態から、セキュリティロールを以下のように部署配下に変更する。

20140926_013

実際のレコードは以下のように表示される。

20140926_014

crmuser1が所属している営業1部の配下には営業1課が存在し、

営業1課のユーザーとしてcrmuser2が存在し、レコードを所有している。

配下のレコードが表示された。

次はさらにこの状態から、crmuser1がさらに上位の部署である、営業本部に変更となった場合を確認してみる。

20140926_015

実際のレコードは以下のように表示される。

20140926_016

部署の階層において配下であれば、直下でなくても権限は及ぶということが分かる。

以上。セキュリティロールに関して説明をした。

まずはこの仕様がベースである。

実際の案件では、この仕様でどこまで実現できて、どこが実現できないかを明確にしつつ、

その他の標準機能やPlugin開発にて制御を行うべきだと私は考える。

※余談ではあるが、本テストを行っている際に製品不具合とも考えられる現象を確認した。

原因が分かり次第、Tipsとして投稿を行う予定である。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中