アプリがユーザーの ID や設定に基づいて別のデータやプレゼンテーションを表示できることを見てきました。場合によっては、特定のクラスのユーザーに対してアプリで別の機能を提供する、または機能を制限することが必要です。考慮すべきケースは次の 3 つです。
- 少数のユーザークラスがある（一般には、たとえば通常のユーザーと管理者の 2 つだけ）。片方のクラスのユーザーに、いくつかの追加機能を利用可能にする必要がある。
- 少数のユーザークラスがあるが、それぞれが大きく異なる機能を必要としている。
- 多数のユーザークラスがあり、それぞれが大きく異なる機能を必要としている。
ケース 2 と 3 では、各クラスのユーザーのために別のアプリを構築するのが、AppSheet での解決策です。同じデータを基礎とした複数のアプリを簡単に構築できます。追加、更新、削除の操作をコントロールするに記載されているように、データ変更の権限を制御できます。しかし、それぞれ異なるアプリを管理する必要があります。
ケース 1 はごく一般的なもので、この場合はユーザークラスごとに別のタイプの機能を与えるのが適切です。アプリレベルでは、各種の方法でユーザークラスを差別化できます。例:
- ユーザーがテーブルまたはスライスのうち、どのフィールドを表示または更新できるかを制御します。テーブルの定義で、ユーザーが列を表示または更新できるかどうか（Add / Edit / Delete / ReadOnly）を静的に定義する代わりに、列のプロパティで
Show?式とEditable?式を定義します。 - どのビューをユーザー向けに表示するかを制御します。ビューの定義の一部として、
Show_If制約式を使用します。 - ユーザーがどのアクションを起動できるかを制御します。アクションの [Behavior] セクションで [Only if this condition is true] 設定を構成して、アクションを表示する行を制御します。
これらの式で、現在のユーザーのメールアドレス（USEREMAIL()）、またはユーザー設定に定義されているオプション（USERSETTINGS()）を使用して、ユーザーを適切なユーザークラスに分類します。たとえば、テーブルの更新モードを動的にコントロールするためのユーザーのメールに基づいてユーザーのアクセス権限をコントロールするサンプル式は次のようになります。SWITCH() をご確認ください。
SWITCH(USEREMAIL(),
"admin@mycompany.com", "ALL_CHANGES",
"manager@mycompany.com", "UPDATES_ONLY",
"READ_ONLY")