この特集のトップページへ
＞ Chapter 7：プレゼンテーション層の構築

7.4.1　顧客管理用のフォーム
●権限による操作の制限
　Fig.7-16に示したように，顧客情報フォームには，［新規］［編集］［削除］［復帰］［印刷］［最新の情報に更新］［検索］［表示項目］という8個のボタンがある。しかし，すべてのボタンをユーザーが使えるとは限らない。なぜならば，ビジネスロジックでは，Salesロール，SalesManagerロール，SalesAdminロール，AllAdminロールのいずれにも属さないユーザーは，顧客の新規作成や編集はできないようにし，また，Accountingロール，AccountingAdminロール，AllAdminロールのいずれにも属さないユーザーは，顧客の締め日を設定できないようにしたためである。

　そういった意味で，［新規］［編集］［削除］［復帰］の4つのボタンについては，次のロールに属するユーザーしか利用できないということになる。

  • ［新規］ボタン
    　Salesロール，SalesManagerロール，SalesAdminロール，AllAdminロールのいずれかに属するユーザーのみ。

  • ［編集］ボタン
    　Salesロール，SalesManagerロール，SalesAdminロール，AllAdminロール，Accountingロール，AccountingAdminロールのいずれかに属するユーザーのみ。AccountingロールとAccountingAdminロールを含むのは，締め日の設定があるため。

  • ［削除］ボタン
    　Salesロール，SalesManagerロール，SalesAdminロール，AllAdminロールのいずれかに属するユーザーのみ。

  • ［復帰］ボタン
    　SalesAdminロール，AllAdminロールのいずれかに属するユーザーのみ。

　利用権限を有するロールに属さないユーザーがボタンを押したときには，「その機能は使えません」などとメッセージを表示して処理を拒否するような設計も考えられるが，どうせ使えないのであれば，ボタンを淡色（グレー）表示にして押せないようにしたり，ボタンそのものを表示しないようにしたりするほうが，ユーザーの混乱がなくてよい。 そこで，ここでは顧客情報フォームがロードされたときにユーザーの権限を調べ，権限がなければボタンを表示しないように実装することにしよう。

　フォームがロードされるときには，Loadイベントが発生するので，そのなかでユーザーが属するロールを調べてボタンの表示と非表示を切り替えれば，目的の機能を実現できる。ユーザーが属するロールを調べるには，Chapter 6で実装したBusiness.UtilityコンポーネントのGetUserInRoleメソッド（List 6-199）を使えばよい。実際のプログラムは，List 7-6のようになる。

　List 7-6の10行目では，まずBusiness.Utilityコンポーネントを実体化し，13行目でそのGetUserInRoleメソッドを呼び出すことで，ユーザーが所属しているロールを取得している。なお，13行目では，GetUserInRoleメソッドの戻り値を1行目で宣言したグローバル変数g_uRoleに格納している。グローバル変数としたのは，あとでどこからでも参照できるようにするためである。

　15〜24行目の処理が，［新規］ボタン（BTN_NEW）と［削除］ボタン（BTN_DELETE）の状態を設定している部分である。15行目でユーザーがAllAdmin，Sales，SalesAdmin，SalesManager，Accounting，AccountingAdminのいずれかのロールに属するかどうかを調べ，属するようであれば，［新規］ボタンと［削除］ボタンのVisibleプロパティをTrueに設定する。そうでなければFalseに設定する。Vislbleプロパティは可視であるか否かを設定するプロパティであり，Trueであれば可視，Falseであれば不可視を示す。15〜24行目の処理が実行される結果として，AllAdmin，Sales，SalesAdmin，SalesManager，Accounting，AccountingAdminのいずれかのロールに属していなければ［新規］ボタンと［削除］ボタンがユーザーから見えなくなる（見えないということはもちろん押すこともできない）。

　26〜32行目の部分は，［編集］ボタン（BTN_EDIT）をどのようにして表示するかを決めるものである。本来，［編集］ボタンは顧客の編集をするためのものであるから，AllAdmin，Sales，SalesAdmin，SalesManager，Accounting，AccountingAdminのいずれかのロールに属さなければ押すことができないようにしたい（経理部であるAccountingロールとAccountingAdminロールには顧客の編集権限はないが締め日の設定権限がある）。しかし，後述の「7.4.4　顧客の編集」において［編集］ボタンが押されたときには，Fig.7-21のようなウィンドウを表示させる予定である。

Fig.7-21　顧客の編集画面
fig7_21

　Fig.7-21の画面は，顧客の編集はもちろんのこと，顧客の詳細情報を表示するという役割も担っている。そのため，編集時にしか使わないというのは少々惜しい。そこで，いかなるロールに属するユーザーでも［編集］ボタンを押してFig.7-21のウィンドウは表示できるものとし，AllAdmin，Sales，SalesAdmin，SalesManager，Accounting，AccountingAdminのいずれかのロールに属していなければ，Fig.7-21では参照のみができ，更新はできないという仕組みを持たせることにする（その実装は，「7.4.4　顧客の編集」で説明する）。そこで，List 7-6の26〜32行目では，［編集］ボタンを不可視にするのではなく，AllAdmin，Sales，SalesAdmin，SalesManager，Accounting，AccountingAdminのいずれかのロールに属さないときには，ボタンのラベルを「詳細」に変更する――つまり，［編集］ボタンではなく［詳細］ボタンとして表示する――という実装にした。

　34〜42行目は，［復帰］ボタン（BTN_UNDELETE）の可視と不可視を設定するための処理である。34行目にあるように，ユーザーがAllAdminロールかSalesAdminロールに属する場合には可視，そうでなければ不可視としている。

　なお，List 7-6では，8行目でエラーハンドラを設定している点に注目してほしい。「4.4　リモートの呼び出し機能」でも説明したが，リモートのCOMコンポーネントを実体化したり，実体化したCOMオブジェクトのメソッドを呼び出したりする際には，ネットワークの切断などにより，通信エラーが発生することがあり得る。そのため，必ずエラーのハンドリングが必要になってくる。

　以上のようにList 7-6を実装することにより，アプリケーションを起動したユーザーがどのロールに属するかによって，Fig.7-22に示すようにボタンの表示状態が変わってくることになる。

Fig.7-22　ロールによるボタンの表示状態の違い
【AllAdmin，SalesAdminのいずれかのロールに属する場合
fig7_22a
【AllAdmin，Sales，SalesAdmin，SalesManager，Accounting，AccountingAdminのいずれかのロールに属する場合】
fig7_22b
【それ以外の場合】
fig7_22c

One Point! 今回は，ユーザーの権限によってボタンを表示しないという方式をとったわけだが，この方法はあまり好ましくない場合もある。まず第一に，表示されていないボタンが抜けるので，見栄えが悪くなってしまうという点がある。第二に，使用説明書などドキュメント類を書くときに，ユーザーによって見えるボタンと見えないボタンがあるので，操作説明がしづらく混乱を引き起こすという点である。そのため，ボタンそのものを見えなくするのではなく，ボタンを淡色（グレー）表示にして，表示されていても押せない状態にする，という実装のほうが好ましいこともある。
prevpg.gif Chapter 7　10/65 nextpg.gif