権限は、システム利用において適切なユーザーに適切なシステムリソースを提供する上で重要な概念です。ですが、一口に権限といっても、実際は幅広い目的・場面に応じて必要な権限管理は異なります。NuAppでも、権限に関する設定や機能は各所に配置されています。このページではNuAppでの権限に関する機能の全体像をご紹介しますので、ニーズに応じた権限設定をしたり、アプリ開発・利用をスムーズに進めたりする上でお役立て下さい。
ユーザー権限
アプリ開発の話に入る前に、ログインユーザーに割り当てられる一番上位レベルの権限についてご紹介します。この設定は管理者ポータルのユーザー管理で、ユーザー追加・編集を行う際に、「ユーザー権限」として設定するものです。それぞれの意味は以下の通りです。
権限 | 意味・できること |
---|---|
管理者 | 最初にNuAppのアカウントを作成した際に、同時に作成されます。管理者ポータルにアクセスし、管理者作業を行うことができます。管理者ユーザーを削除したり、管理者権限を引き渡したりはできないため、引き継ぎが必要な場合は、ユーザーアカウントそのものを引き渡し、パスワードを変更する等の対応を行って下さい。 |
パワーユーザー | 基本的に管理者と同等の権限を持っており、管理者ポータルにアクセスし、管理者作業を行うことができます。 |
一般ユーザー | アプリを利用する側のユーザー全般に付与する一般的な権限のユーザーです。 ①管理者ポータルにアクセスできない ②設定等によって管理者のみに許可した操作(データ削除等)が行えない という以外は、全ての権限を持っています。 |
ゲストユーザー | 一般ユーザーよりさらに1段階権限を落としたユーザーです。具体的には、 ①グローバル検索が行えない ②メッセージの送信が行えない ③ファイル共有で全体共有のフォルダにアクセスできない といった違いがあります。活用方法としては、例えば、取引先との情報共有といった目的で活用頂くことを想定しています。一方、権限を落としているとはいえ、あくまでも組織内のユーザーの一つですので、このユーザーに割り当てるアプリについては慎重に設計・テストを行った上で公開することを推奨します。 |
アプリ利用権
ライセンスの考え方にある通り、ユーザーが存在しているだけではNuAppで開発したアプリは利用できません。管理者ポータルのホームで、利用中アプリのNuAppについて、割当ページを開き、有効無効を切り替えて利用状況を「利用中」にすることで、アプリ利用権が割り当てられ、NuAppで開発したアプリが使える前提条件が整います。このNuAppの利用権があること+開発した個別のアプリが割り当てられていること、の両方の条件が揃った時にアプリにアクセスできます。
更に、アプリ内権限を「アプリ管理者」に変更すると、アプリのメニューに「アプリ管理」が表示されるようになり、アプリ開発を行うためのアプリ管理機能にアクセスできるようになります。
アプリ開発者への権限
初期状態では、アプリ管理者は全員同等の開発権限を持ち、全てのモデル、アプリについて自由に作成・更新ができます。しかし、様々な部署でアプリ開発したり、現場の担当者がアプリ開発をするエンドユーザー開発(開発の民主化)といった取り組みを行う際には、権限が制限されないままでは混乱を引き起こす可能性が高いです。これに制限を加えるための権限管理機能もあります。
管理者ポータルのカスタマイズで、アプリ管理の権限制御タブで、機能の有効化をONにし、全権ユーザー(権限そのものを管理するユーザー)を指定することで、アプリ管理についても権限管理を行うことができるようになります。この機能を有効化すると、アプリ管理のトップページに「権限」メニューが表示されるようになり、権限管理が行えます。
この機能では「タグ」の単位で、権限グループを作成し、作成可能なモデル数、アプリ数や、具体的に誰がどこまでの操作を可能かといった権限分けを行います。具体的な運用例としてはタグを部署別に作成し、その部署で管理できるモデル・アプリ数やユーザー別の役割による権限管理を行う流れです。
例えば、全社的に使われるものについては、IT部門のみが管理でき、現場のIT担当者は、更新はできないけど、機能に取り込むことはできる、といったイメージです。

閲覧・編集に関する権限
一言で「閲覧・編集の権限」と言っても、実体は様々な設定から成り立っています。これは、どのデータ/項目を閲覧/編集できるべきかを、状況に応じてロジカルに決定するためです。一つ一つの設定要素はこの後紹介しますが、全体を図示化すると以下の通りです。

アプリ割当による権限付与
NuAppでは、1つのモデルを複数のアプリで使うことができます。もちろんモデルの設定も保存されるデータも共有されます。つまり大きくは一連の業務でも、ユースケース別(役割別)にアプリを分けて、それぞれに適切な機能のみを提供できる、ということです。
権限管理の観点から考えると、より高い権限を付与するユーザーにはデータ全体を閲覧できるアプリを作って割り当て、権限を制限するユーザーには直接関係のあるデータのみを閲覧できるアプリを作って割り当てる、といった形で権限レベルに応じてアプリを分けることで権限管理を実現することが可能です。

閲覧権限
アプリ設定
アプリ内で、データを閲覧するための各種コンポーネント(リストや検索、カレンダー等)は、データを絞り込むための「抽出条件」の設定が可能です。この設定で自身に関係するデータのみに絞り込む条件を追加することで、データ範囲を制限できます。
代表的なやり方としては、ユーザー項目に対して「me」ボタンを使ってログインユーザーを指定したり、組織項目に対して所属組織を指定する方法があります。
こうしたアプローチは柔軟に閲覧可能な範囲を絞り込めるというメリットがあります。注意点としては、アプリ全体を通して意図した閲覧制限が統一されるように確認が必要ということです。あるコンポーネントは制限されていても、別のコンポーネントで見えるようになっていた、とならないようにテストを通して検証しましょう。
モデルにおけるデータのアクセス制限
モデルを作成する段階でアクセス制限を掛ける方法もあります。適用できるルールも少なく、例外を許さず閲覧できないようにしてしまいます。より厳密に、意図しない閲覧が問題になるようなケースでは採用を検討することもできます。
具体的には、モデル編集画面のデータ設定で、「アクセス制限なし」となっているフィールドを変更することで設定できます。設定の意味は以下の通りです。
設定 | 意味 |
---|---|
アクセス制限なし | アクセス制限がかかりません |
組織でアクセス制限 | 管理者ポータルの組織で設定した組織図に基づいてアクセス制限を行います。組織図はツリー構造の組織に所属ユーザーを割り当てていくことが可能です。 データの所有者の所属組織に基づき、データが紐づく組織を割り当てて、アクセス制限については、ログインユーザーの所属組織とその下位組織に紐づくデータのみが閲覧可能となります。 |
ゲストのみ組織でアクセス制限 | 基本的な動作としては「組織でアクセス制限」と同じですが、ゲストのみに適用されます。それ以外の権限のユーザーにはアクセス制限なしと同じ挙動になります。 |
編集権限
ユーザーが登録を行うと、データだけでなく、プロセスの進捗管理も始まります。このようにデータとプロセスの実体が作られるため、ここでは実体化されると表現します。この実体にはアクティブな状態/終了済みの状態があり、終了後は編集できなくなります。
また、データを編集する際は全て、モデルのプロセス内におけるタスクを通して行うことになります。そのため、編集権限とタスクは切っても切れない関係にあります。このタスクについてもプロセスの中で開始されてアクティブになれば編集可能な状態になりますし、終了したらそのタスクについては編集できなくなります。
さらに、タスクがアクティブだったとしても、誰でも編集可能とは限りません。プロセスの設定次第では、タスクの担当として割り当てられているユーザーしか編集が許可されないこともあります。
こうした幾重もの条件をクリアしないと編集できないのは、難解に感じるかもしれません。しかし現実の業務でも、何人かの担当者で受け渡して進めていくような場合には、適切なタイミングで適切な人が、担当範囲の業務を行うようになっているはずです。アプリ上でこうした様々な業務プロセスを実現するためにNuAppの編集権限の管理も考慮されているという点をご理解頂ければと思います。
まとめると
「データがアクティブである」→「タスクがアクティブである」→「タスクの担当である」
という3ステップで編集権限が決定します
タスクの担当者の割り当てについては、以下のような種類が準備されています。
担当割り当てのルール | 意味や使い方 |
---|---|
アサインは不要で、全ユーザーが更新可能 | 文字通り誰でも編集できます。厳密に編集する人を制限する必要を感じなければ、柔軟な運用ができるメリットがあります。 |
アサインされたユーザーがタスクを担当 | データ毎に担当としてユーザーを指定します。あるタスクの担当者が別のタスクの担当者を指定したり、プロセスの自動処理で割り当てることもできます。例えば、作業指示者が作業担当者をアサインするといった使い方です。 |
予め設定されたユーザーが常にタスクを担当 | モデルのプロセス設定で固定の担当ユーザーを指定します。そのため、データ毎に担当を割り当てる必要はなく、常に同じ人(グループ)が担当します。例えば、ある業務は常に購買部の特定の担当が受け持つ、といったユースケースに対応します |
組織の設定に基づいて、タスクを担当するユーザーを自動設定 | 組織図の設定に基づいて自動的にタスク担当者を割り当てます。例えば、所属組織の上長に自動的に申請がいくようにする、といった使い方です。 |
項目レベルの権限
項目レベルの権限制御が必要なケースもあります。担当によって役割が違えば編集すべき項目も異なってきます。例えば、ワークフローにおいて承認者が結果を入力すべき項目を、申請者が直接編集できてしまっては問題です。
このように担当別に、どの項目を編集してよいかを決定するのが、タスクの編集権限設定です。この設定では、タスク別に、どの項目が表示されるか、編集できるか、または必須かといった設定ができるので、項目別の権限制御の意味合いで活用することも可能です。