ユーザー一覧エリアでは、ユーザー ID や名前、メールアドレス、ステータスなどの詳細と最終ログイン日時が表示されます。特定のユーザーを検索するオプションもあり、これは入力すると表示が自動的に更新されます。また、新たなユーザーを作成したり、特定のユーザーを編集するオプションもあります。新たなユーザーの詳細は、ユーザー編集エリアで確認できます。

一覧ビューからユーザーを削除することもできます。実際に削除する前に、確認が必要になります。ユーザーの削除が可能なのは、そのユーザーが作成したアプリが Studio にない場合のみです。アプリを所有するユーザーを削除しようとすると、エラーが返されます。

新規ユーザーを作成するには、ユーザー ID を指定する必要があります。ユーザー ID はユーザーの一意の識別子で、ドメイン内で一意である必要があり、変更はできません。既存のユーザー ID と重なる場合は、エラーメッセージが出ます。オプションでメールアドレス、名前、パスワードも指定することができます。ユーザーに招待メールを送信する場合は、そのユーザーのメールアドレスを指定する必要があります。「招待メールを送信します」にチェックを入れると、そのユーザーは自分のパスワードを指定できるようになります。

新規ユーザーにロールを割り当てることもできます。ユーザーのロールに関する詳細は、下記で説明します。

「認証ポリシー」セクションでは、ユーザーを認証ポリシーに関連付けることができます。

名前やメールアドレス、パスワードといったユーザーのフィールドは更新が可能です。ユーザーのパスワードは表示できませんが、異なるものに変更することは可能です。

また、ユーザーが メンバー となっている チーム を表示することも可能です。ある チーム の メンバー としてユーザーを追加するには、チームのボックスをクリックし、追加先となるチームを選択します。

このビューでは、ユーザーを有効または無効にすることができます。ユーザーを無効にすると、そのユーザーは $fh.auth API での認証ができなくなります。API が特別な値を返して、ユーザーが無効になっていることを知らせます。

ここには「ユーザーでーを完全削除」するオプションもあります。これを選択した場合は、以下のことが実行されます。

詳細は、$fh.auth API を参照してください。

招待メールには一意のリンクが含まれており、これを開けるとユーザーはパスワードを入力することでアカウントのアクティベーションができます。このメールのメッセージは通常、以下のようになります。

Hello User,

Your account has been created and is awaiting activation.

To activate your account, please click on the link below where you can also set your password.

  https://[your-studio-domain].feedhenry.com/studio/activate.html?t=123456789012345678901234

Regards

新規ユーザーの作成時には、招待メールを自動送信するオプションがあります。別の方法では、ユーザーの更新エリアに招待メールを再送信するオプションもあります。

認証ポリシー一覧エリアでは、ポリシー ID や認証タイプなどの詳細が表示されます。新規ポリシーを作成するオプションや既存ポリシーを編集するオプションがあります。

認証ポリシーを作成する際には、ポリシー ID と認証タイプの特定情報を指定する必要があります。

OAuth 認証では、ユーザーがあるサービスにアクセスするためにユーザー名やパスワードを知らせることなく、アプリケーション開発者はそのユーザー固有の情報にアクセスできます。基本的な流れは以下のようになります。

以下の LDAP 認証方法がプラットフォームではサポートされています。

以下は、Active Directory (AD) サーバーに対してユーザーを認証する指示の例です。

プラットフォーム認証は、ユーザーの認証方法として使用することができます。この方法を使用する場合は、ユーザーはプラットフォームを終了する必要があります。プラットフォームユーザーの運営方法については、ユーザーセクションを参照してください。

FeedHenry 認証ポリシータイプを選択した場合は、特に追加の設定オプションは必要ありません。認証タイプで「FEEDHENRY」を指定するだけです。

このタイプでは、mBaaS Services からのユーザー認証がサポートされます。コアプラットフォームでサポートされていない認証タイプをアプリケーションが必要とする場合は、これをサポートするために新たな mBaaS サービスを簡単に作成できます。

ユーザー認証に加えて、承認方法も指定することができます。

App Store では、エンドユーザーが iOS、Android、および Windows 用のモバイルアプリをモバイルデバイスに直接インストールできます。

App Store のアプリ (以前の Store アイテム) は、App Store からの配信用に追加することができます。新規および既存の Android、iOS (ユニバーサル)、iPhone & iPad アプリ用にネイティブバイナリーをアップロードすることができます。また、App Store に表示されることになるアイコンを App Store アプリに割り当てたり、アプリに名前と説明を加えることもできます。

以下は、App Store のアプリで実行可能なアクションです。

個別のモバイルアプリケーション管理 (MAM) およびモバイルデバイス管理 (MDM) プロバイダーとの統合を有効または無効にできます。統合を有効にしてもすべてのバイナリーが自動的に公開されるわけではありません。公開を有効にする方法については、Publishing App Binaries to Third-party MAM and MDM providers を参照してください。

検索ボックスを使用すると監査ログを検索できます。タブ上部のオプションを使用すると、監査ログを以下でフィルタリングできます。

フィルターオプションを選択したら、「フィルター」ボタンをクリックして一致する監査ログを表示します。「リセット」ボタンをクリックすると、デフォルトの監査ログが表示されます。

ユーザーと App Store のアプリを作成します。App Store のアプリの作成時に、これをグループに制限するようマークを付けることができます。ただし、この段階ではグループが作成されていない場合もあるので、選択する必要はありません。

ユーザーと App Store のアプリを作成したら、アプリグループを作成することができます。作成するグループは組織内の部門に対応させたりします。販売部門用のアプリを含む販売グループや、エンジニアリング部門用のアプリを含むエンジニアリンググループなどです。グループを作成したら、App Store のアプリとユーザーをグループに割り当てられます。

例えば、販売ユーザーと販売 App Store アプリを販売グループに割り当てると、販売ユーザーの 1 人が App Store にログインした場合、販売 App Store アプリを見ることができます。ユーザーと App Store アプリは複数のグループに割り当てることができるので、販売とエンジニアリングのマネージャーが両方のグループに属し、両部門の App Store アプリにアクセスするということが可能になります。もちろん App Store アプリをグループに制限せず、App Store にログインした全ユーザーに表示されるようにすることもできます。

新規のアプリグループを作成するには、メニューのモバイルアプリの管理セクションでグループオプションをクリックし、「グループの作成」ボタンをクリックします。2 つの入力フィールドがあるフォームが表示されます。

必要な情報をこれらのフィールドに入力したら、「グループの作成」ボタンをクリックします。

グループは編集して説明のテキストを変更したり、ユーザーもしくはアプリをグループに割り当てることができます。アプリグループを編集するには、メニューのモバイルアプリの管理セクションでグループオプションをクリックし、編集するグループの「編集」ボタンをクリックします。

デバイス一覧表示では、$fh.auth を使用してアプリにアクセスした全デバイスが表示されます。一覧では、デバイスラベル、デバイス ID、デバイスのステータス、最新のアクセス日時が表示されます。いずれかの制御ボタンをクリックすると、デバイスの更新ビューが表示されます。

デバイス ID はデバイスの一意の識別子で、変更はできません。これはデバイスから送信され、同一デバイス (ハイブリッドまたはネイティブアプリ) 上の異なるアプリで同じものになります。唯一の例外は、ウェブブラウザーで読み込まれたウェブアプリです。この場合、デバイス ID は生成された値で、クッキーに保存されます。クッキーが削除されると、新たな値が生成されます。

このビューでは、デバイスにフレンドリー名を割り当てたり、認証を無効にしたり、データの完全削除をマークしたりできます。また、プラットフォーム上のどのユーザーがデバイスを使用しているか、およびそのデバイスからアクセスしているアプリを確認できます。

デバイスの認証を無効にすると、$fh.auth を使用して認証しているデバイス上の全アプリが失敗するようになり、デバイスが無効になっていることを示す特別な値が返されます。これは、デバイスを紛失したり盗難にあった場合などに便利です。

「デバイスデータを完全削除しますか?」のオプションが選択されると、以下のことが実行されます。

$fh.auth がデバイス上のアプリから呼び出されるたびに、認証プロセスが成功してユーザーがプラットフォームユーザーであれば、アクセスログエントリーが作成されます。このため、デバイス表示エリアでは、どのユーザーがどのデバイスからアクセスしたかを確認することができます。

ユーザーセクションでは、そのデバイスを使用してアクセスしたユーザーの ID 一覧が表示されます。ユーザー ID にカーソルを移動させるとユーザーについての詳細が示され、クリックするとそのユーザーの管理画面に移動します。

ユーザーアクセスの場合と同様に、$fh.auth を呼び出すたびにアプリ情報もキャプチャーされます。アプリ一覧は、デバイス表示エリアの "App" セクションに表示されます。各アプリエントリーにカーソルを移動させると、アプリの概要が表示され、クリックするとそのアプリの管理画面に移動します。

これは、選択した 31 日間の期間中にクラウドリクエストを行ったデバイス数です。一意のデバイス識別子 で特定されるデバイスは、この期間に少なくとも 1 回のクラウドリクエストを ($fh.act または $fh.cloud で) 行うと、アクティブとみなされます。

デバイスインストールでは、特定の期間にアプリがインストールされた数が表示されます。デバイスインストールは、アプリが新規デバイスで最初に起動し、クラウドにコールバックをすると追跡されます。デバイスインストールは App Stores が以下の方法で追跡するユーザーインストールとは異なることに注意してください。

アプリの起動は、インターネット接続でこれまでに見られたデバイス上でアプリが起動されると追跡されます。アプリ起動は、コールドスタートで起動したアプリのみが追跡されることに注意してください。つまり、バックグラウンドで実行されているアプリがフォアグラウンドに持ち込まれても「アプリ起動」として追跡されません。

クラウドリクエストのレポートでは、クライアントアプリが ($fh.cloud を使って) クラウドアプリにリクエストを要求した回数が表示されます。

アクティブデバイスのレポートは、選択した期間であるアプリに対してアクティブだったデバイス数の中央値を示します。一意のデバイス識別子 で特定されるデバイスは、この期間に少なくとも 1 回のクラウドリクエストを ($fh.act または $fh.cloud で) 24 時間の期間 (GMT タイムゾーンの午前 0 時から) の間に行うと、アクティブとみなされます。

レポートタブの集計レポートは、全レポートの高度なビューを日付、デバイス、場所ごとなどに提供します。各アナリティクスタイプで「詳細を表示」をクリックすると、簡単に特定のレポートをドリルダウンすることができます。

レポートタブのアプリ別レポートでは、左側のリストからアプリを選択して、個別アプリについてのレポートを表示することができます。多数のアプリがある場合は、検索することも可能です。アプリを選択したら、このアプリについての概要レポートが表示されます。特定のメトリクスについて知りたい場合は、「詳細を表示」ボタンをクリックします。

個別アプリの画面では、特定タイプのアナリティクス (起動、インストールなど) についての概要レポートが表示されます。レポートのタイトルをクリックするか、ナビゲーションで表示を切り替えると個別の図表が表示されます。

このタイプの図表では、時間経過による値の推移が分かります。Y 軸にはインストールなどの値が表示され、X 軸では日付が示されます。各プラットフォーム (Android、iPhone など) の値は、個別の線で示されます。

プラットフォーム別の集計値が円グラフで確認できます。集計値は、選択された期間のものです。

ユーザーの場所をベースにした特定期間の集計値が地理的グラフで表示されます。国の上にカーソルを移動すると、国ごとの値や、最小から最大値の基準におけるその値の位置が表示されます。

この画面では、現在利用可能なチームが一覧表示されます。以下が実行可能です。

パーミッションに関連する主な用語は以下の通りです。

パーミッションはすべて、ビジネスオブジェクトに対して設定されます。

ビジネスオブジェクトはプラットフォームの機能エリアに関連し、その構造を示す階層に体系化されます。

例えば、リセラー に下にある 管理者 要素にパーミッションを設定すると、この リセラー の管理者機能に対するパーミッションを設定することになります。

ビジネスオブジェクトには、以下の 3 つのアクセスレベルを適用できます。

ビジネスオブジェクトは階層に体系化されます。ビジネスオブジェクトは、プラットフォームの大きな機能エリアを参照することができます (例: ドメイン 全体)。サブビジネスオブジェクトは、プラットフォームのより特定の機能エリアを参照します (例: ドメイン 内の プロジェクト)。

この構造を使用すると、サブビジネスオブジェクトの パーミッション をその親から継承できます。これは、パーミッションを継承 の選択肢で決定します。パーミッションを継承 を オン にすると、サブビジネスオブジェクトはその親のパーミッションを継承します。パーミッションを継承 を オフ にすると、特定の アクセスレベル をサブビジネスオブジェクトに設定する必要があります。

パーミッション の優先順位は、ビジネスオブジェクトに設定された アクセスレベル で決定されます。

ビジネスオブジェクトに アクセスレベル を設定する順番は、以下のようになります。

ユーザーは、複数の チーム の メンバー となることができます。この場合、ビジネスオブジェクトに適用される アクセスレベル は、上記の優先順位となります。

以下の例を見てみましょう。

このシナリオでは、ビジネスオブジェクト A には 表示 の アクセスレベル があることになります。

ビジネスオブジェクトには、複数のインスタンスがあるものもあります。例えば、プロジェクト ビジネスオブジェクトは、ドメイン上で利用可能なすべての プロジェクト に関係します。ドメインでは複数のプロジェクトが存在する場合があるので、特定のプロジェクトにパーミッションを適用できる必要があります。

フィルタリング可能なビジネスオブジェクトは、以下の 2 つの方法でフィルターをかけられます。

ユーザーが作成したビジネスオブジェクトのインスタンスはすべて、そのユーザーには表示されます。ただし、そのビジネスオブジェクトに割り当てられているパーミッションが適用されます。

以下の例を見てみましょう。

このシナリオでは、Studio のプロジェクトセクションで ユーザー A に表示されるのは、プロジェクト A のみになります。