Chapter 4. Administration and Management

4.1. Account

Overview

The Account Settings Section has a number of functions. Users can view account overview information such as the account type, and associated email. Users can also manage their account password settings from here. API and SSH Keys can also be managed from the Account section.

Requirements

There are no special requirements to be able to view user account information.

Related Resources

4.1.1. Manage Account

This section of the Account area shows your account details such as Name, e-mail address and your account type. Account Preferences, such as re-enabling the Welcome introduction or always showing the context help, can be modified here. Your password can be changed on this page too.

4.1.2. SSH Key Management

Accessing your App repos via Git requires you to upload an SSH Public key. This section of the Account area helps you do just that. You can upload multiple keys if you have a different key on various machines, or want to allow someone access. Keys can also be searched, based on the label you gave it, or deleted.

Your SSH key is typically located in:

~/.ssh/id_rsa.pub

Or, to generate a new key use:

ssh-keygen -t rsa -C "your_email@example.com"
Warning

Any SSH key added here will have push & pull access to the Git repositories of every Project/App you can see in the Projects tab.

Warning

An SSH key can only be uploaded once. If you attempt to uploaded an already existing key, even in someone else’s account, it will fail. This behaviour is essential for mapping keys to a Users account. If you need to use multiple SSH keys, see our guide for configuring your local SSH to use multiple keys.

4.1.3. API key Management

In a traditional web application the user authenticates with the server, and then a cookie is incorporated into all subsequent requests sent to that user. RHMAP replaces the traditional method and uses an API key which is similar to a cookie but is sent in a header called X-FH-AUTH-USER. This header must be incorporated into every request sent to the user.

User API keys can be viewed in the My AccountMy ProfileAPI Keys section of the App Studio. In the API Keys section of the App Studio, users can create, list, edit and revoke their user API keys. When accessing the REST API programmatically, a valid user API key must be manually set in the "X-FH-AUTH-USER" header field for each request.

By default, you will have no User API keys (with the exception of any system created keys for example, FH_MBAAS_API_key). Multiple API keys can be created, so its a good idea to give each a unique label. The key value will be generated automatically. Labels can be modified later if required. If you no longer require a specific key or wish to prevent it from being used any more (for security reasons), simple Delete/Revoke it.

4.2. Administration

Overview

The Administration section of the platform allows Users, Auth Policies and Deploy Targets to be managed. It also allows you to control all aspects of distributing apps to end user devices as well as tracking and managing this usage.

Requirements

The user must be a member of one or more teams with the following permissions:

  • Domain — Authorization Policy (View & Edit)
  • Domain — Authorization Policy (View & Edit)
  • Domain — Deploy Target(View & Edit)
  • Domain — App Store (View & Edit)
  • Domain — Administrator (View & Edit)

4.2.1. Users

All aspects of User management from creating Users, assigning Roles, disabling Users to deleting Users are available to Administrators.

A full list of available options:

  • View, create and update a user’s details, be they App users (used in conjunction with our $fh.auth API) or App Studio users
  • Assign roles to users
  • Disable users - rendering them unable to login
  • Mark a user for data purge (used with $fh.auth, this flag can be checked to wipe data from a user’s app/device)
  • Send/re-send an invite email to a user
  • Delete Users

4.2.1.1. Viewing Users

In the User list overview area, details such as the User’s user id, name, email, active status and when they last signed in are shown. There is an option to search for a specific user, which updates automatically as you type. There is an option to create new User’s, or edit a specific User. Additional User details are available in the user edit area.

A user also can be deleted from the list view. You have to confirm the deletion before it’s actually executed. A user can only be deleted if there are no apps in the Studio created by that user. If there are still apps owned by that user, the deletion will throw an error.

4.2.1.2. Creating Users

When creating a new user you need to specify the user id. User id is the unique identifier of the user and it has to be unique in your domain and it cannot be changed. You will get an error message if the user id is already taken. You can also optionally specify email, name and password for the user. If you want an invitation email to be sent to the user, you need to specify the email address for the user. You can allow users to specify their own passwords by checking the "Send Invite Email" option.

Roles can be assigned to a new User as well. More details on User Roles is available below.

Users can also be associated with Auth policies in the "Auth Policies" section.

4.2.1.3. Updating Users

User fields such as their name, email and password can be updated. A User’s password cannot be viewed, but it can be set to be a different value.

In addition, the Teams that the User is a Member of will be displayed. To add a User as a Member of a Team, click into the Teams box and select the team to add.

A user can be disabled or enabled in this view. Once a user is disabled, that user will not be able to authenticate in $fh.auth API. A special value will be returned by the API to indicate that the user has been disabled.

There is another option here called "Purge User Data". If this option is checked, two things will happen:

  • The user will be disabled.
  • Next time when the user login using $fh.auth, a special value will be returned by the API to indicate all the existing app data should be deleted (the data delete function is subject to developers to implement).

For more details, check the $fh.auth API.

4.2.1.4. Invitation emails

An invitation email contains a unique link, which when opened, allows a user to activate their account by inputting the password to use. The text of this email is typically something like:

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

When creating a new user, there is an option to automatically send an invitation email. Alternatively, there is an option in the update user area to resend invitation emails.

4.2.2. User Roles

Note

The permissions system in Red Hat Mobile Application Platform is based around the concept of teams, as opposed to the role-based system previously used in the FeedHenry v2 platform. If the Teams based permissions system is active, your User Profile in Studio will contain a Teams section. If not, the Roles based permissions system is active. For a comparison of Roles and Teams, click here.

User Roles are added to user accounts in order to grant them different privileges within the Platform. Users can perform different tasks, and access different sections of the Platform, depending on what roles have been assigned to their account. For example, only a user with the Analytics role can access the Analytics section of the Platform. Only Admin or Domain Admin users have the authority to add or remove user roles to an account.

4.2.2.1. Analytics (analytics)

  • Can access the Analytics section of the Platform.
  • Can monitor project usage.

4.2.2.2. Forms Editor (formseditor)

  • Can create forms and themes.
  • Can create Form Projects.
  • Can edit forms, themes, and Projects associated with their group(s).
  • Can associate forms and themes with projects in their group(s).

4.2.2.3. Forms Administrator (formsadmin)

  • Can create forms and themes.
  • Can create Form Projects.
  • Can create groups.
  • Can assign users to groups.
  • Can view, access and manage all forms & themes created on a specific domain.
  • Can view submissions from all projects on the domain.
  • Can edit submissions from any project on the domain.
Note

It is the responisiblilty of the Forms Administrator to add users to groups. If a Forms Editor is not associated with a group, they will not be able to see any forms/themes they create, even though they have sufficient privileges to edit them.

4.2.2.4. Submission Viewer (submissionsviewer)

  • Has access to view submissions from any project in their group(s).

4.2.2.5. Submission Editor (submissionseditor)

  • Has access to view submissions from projects in their group(s).
  • Has access to edit submissions from projects in their group(s).

4.2.2.6. Developer (dev)

  • Can create and manage any type of Project.
  • Can build App binaries for all available platforms.
  • Can upload development resources such as private keys and certificates.
  • Can create, edit, and maintain deployment targets.
  • Can add public services to a project.

4.2.2.7. Developer Administrator (devadmin)

  • Can create and manage any type of Project.
  • Can build App binaries for all available platforms.
  • Can upload development resources such as private keys and certificates.
  • Can create, edit, and maintain deployment targets.
  • Can view and access all Projects & Apps on a specific domain.
  • Can view and edit all deployment targets on a specific domain.

4.2.2.8. Service Administrator (serviceadmin)

  • Can provision mBaaS Services.
  • Can manage mBaaS Services.

4.2.2.9. Domain Administrator (portaladmin)

  • Can create and edit Auth Policies.
  • Can update the App Store for their domain.
  • Can create and manage App Store Apps.
  • Can create and manage App Store Groups.
  • Can manage App Store Devices.
  • Can view App Store Logs.
  • Can access the 'Mobile App Management' section on the Admin page.
  • Can add and remove users.
  • Can assign roles to users.

4.2.2.10. Customer Administrator (customeradmin)

  • Can manage users in any domain belonging to this customer.

4.2.2.11. Reseller Administrator (reselleradmin)

  • Can manage users in any domain belonging to any of its customers.
  • Can assign the Customer Admin role to users.

4.2.2.12. Administrator (admin)

  • Can perform any action in the Platform.
  • Can assign Reseller Admin and Customer Admin roles to users.

4.2.3. Auth Policies

The Platform has a feature rich Authentication and Authorization mechanism. At the core of this is the concept of Auth Policies. An Auth Policy allows you to define how your Users will Authenticate themselves when accessing your Applications and App Store Apps, and also allows you to define various Authorization checks.

RHMAP supports the following Authentication providers:

  • OAuth: Specifically, OAuth2, this allows you to authenticate your users against OAuth providers such as Google.
  • LDAP: Both Active Directory and Open LDAP servers are supported, typically used for more 'Enterprise' type integrations.
  • FeedHenry: The RHMAP platform authentication mechanism.
  • MBAAS: Authenticating users via an mBaaS Service, which means you can use any authentication mechanisms.

4.2.3.1. Viewing Auth Policies

In the Auth Policy list overview area, details such as the Policy Id and Authentication Type are shown. There are options to create a new Policy or Edit an existing Policy.

4.2.3.2. Creating an Auth Policy

When you create an Auth Policy you need to specify an Id for the Policy, along with specific information for the Authentication Type.

4.2.3.3. OAuth Auth Type

OAuth Authentication allows for application developers to access user specific information from a third party service without that user having to divulge their username and password for accessing that service. The basic flow is as follows:

  • The user wishes to login to your application and click the sign in with Google option.
  • The application retrieves a request token from the provider and redirects the user with this token to the provider.
  • The user logs in to their account and approves access to requested information and are redirected back to the application.
  • The application receives an OAuth token and a OAuth verifier which it exchanges with the provider for an OAuth access token.
  • The access token is sent with any future requests to access the user’s information.

4.2.3.4. LDAP Auth Type

The following LDAP Authentication methods are supported in the Platform:

  • Simple: Simple Bind, where the users DN and password are sent to the LDAP Server. This option is supported out of the box with Active Directory and OpenLDAP.
  • SASL: Two types of Simple Authentication and Security Layer are supported, Digest MD5 and CRAM MD5. Consult your LDAP servers documentation for information on the type of SASL it supports.
4.2.3.4.1. URL

The URL field is the address of your LDAP server, for example, ldap://foo.example.com:389. Note that '389' is the standard LDAP port.

4.2.3.4.2. DN Prefix

The 'Distinguished Name (dn) prefix' field is the prefix for the full user DN. The format of a Users full DN required for Authentication is typically: <prefix><user><dn>, for example, uid=fred,ou=people,dc=example,dc=com. The prefix is typically 'cn' for Active Directory or 'uid' for Open LDAP. Consult with your LDAP Administrator for what this setting should be. Note that this can also be blank, it is not a mandatory setting.

4.2.3.4.3. DN

The 'Distinguished Name (dn)' field can be used to provide the full directory path to the user, for example, the ou=people,dc=example,dc=com in the example above. Again, this can be blank, consult with your LDAP Administrator regarding this setting.

4.2.3.4.4. DN and DN Prefix

The DN and DN Prefix fields are used together to build the name that the platform uses to Bind to the LDAP server. In the example uid=fred,ou=people,dc=example,dc=com, the prefix could be set to uid= and the dn could be set to ,ou=people,dc=example,dc=com. This would allow users to use fred as the user name. These fields can be left blank and the platform will attempt to bind using the data entered by the user. These fields can be used to construct whatever value that the LDAP server allows for binding, including the userPrincipalName. If the userPrincipleName is an email address, the dn field could be used to add a common domain name, for example, if the dn field is set to @example.com and a user uses a login name of fred the platform will attempt to bind to the LDAP server as fred@example.com.

4.2.3.5. Sample Active Directory Settings

Here are some sample instructions for how to Authenticate Users against your Active Directory (AD) server:

  • First, your server needs to be accessible from the RHMAP Cloud. For private RHMAP deploys this is usually not an issue as all services will be behind the same firewall. For public RHMAP cloud, you will either need to set up a VPN for us to access your AD Server, you will need to contact us to discuss this. Alternatively, ensure your AD Server is publicly accessible.
  • Next, create an Auth Policy and specify the following values:

    • By default, AD supports the 'Simple' Authentication Method out of the box, so choose 'Simple’as the Authentication Method.
    • In the URL field, enter the address of your AD server, for example, ldap://foo.example.com:389.
    • Leave the 'DN Prefix' and 'DN' fields blank. These are not required by default for AD. When a User authenticates, their email address alone is passed on to AD and this is normally sufficient to identify the AD User.

4.2.3.6. FeedHenry Auth Type

You can use the Platform Authentication as a means of Authenticating Users. Using this method, a User must exist in the Platform. See the Users section for instructions on how to administer Platform Users.

There are no additional configurations options if you choose the FeedHenry Authentication Policy Type, simply specify the Authentication Type as 'FEEDHENRY'.

4.2.3.7. MBAAS Auth Type

This type supports user authentication via mBaaS Services. If your application needs an authentication type that is not supported by the Core platform, you can easily create new mBaaS services to support it.

4.2.3.7.1. Service

The name of the mBaaS service this auth policy should use. You should create the mBaaS service first and then select the name from the dropdown list.

4.2.3.7.2. Endpoint

The full path of an endpoint defined by the mBaaS service this auth policy should be calling.

The endpoint will receive the 'params' object specified in the Auth API in the request body, and it should return 200 if authentication is succeeded.

If Authorization is required, this endpoint should also return a JSON response with a userId key. The value of this key will be used to lookup user in the system for authorization checks.

4.2.3.7.3. Default Environment

The environment to use, if the environment value is missing in a request.

4.2.3.8. Authorization

Further to your User Authenticating themselves, you can also specify Authorization measures:

4.2.3.8.1. Check User Exists

This check will ensure the User is a valid User that exists on the Platform. See the Users section for more information on Administering Users in the Platform.

4.2.3.8.2. Check User is Approved

This simply allows you to add specific Users that you want to be Authorized to access your App. If the User is not in this list, they will not be allowed access to your App.

4.2.4. Mobile App Management

RHMAP contains a built-in App Store for distribution of binaries to mobile devices. Integrations for some third-party mobile application management solutions are also supported and listed in the section Third Party MAM/MDM.

4.2.4.1. App Store

The App Store gives end users the ability to install mobile apps for iOS, Android, and Windows directly onto their mobile devices.

4.2.4.1.1. Configuring the App Store

Each domain comes with an App Store. In order to use this App Store you will first need to update some of the details:

  • Name: this name shown to users of the App Store
  • Description: the description to display on the App Store landing page
  • App Store icon: this is the icon that will be displayed along with your App Store
  • App Store Apps: items available to install from the Store
  • Auth Policies: used to configure which users can access the Store, and which Items they are allowed to install
4.2.4.1.2. Using the App Store

To visit the App Store, go to the App Store URL on you mobile browser. This URL can be obtained from the Admin > Mobile App Management > App Store page, and is typically located at domain.feedhenry.com/store.

When you browse to the App Store URL on your device, you will be presented with the login screen of the Mobile App Store. This screen shows some details about the App Store, and a list of available authentication mechanisms for example, OAuth or LDAP. These mechanisms are preconfigured by following other parts of this guide. If no authentication mechanisms have been setup, it will not be possible to log in to the App Store, even if Apps have been added to it.

App Store Login

After logging in, a list of available Apps for your device will be shown.

App Store List

Choosing an app will display more information, including an install button.

App Store Details

There are several possible installation binary types for iOS applications:

  • iPhone - can be installed on iPhone, iPod Touch and iPad.
  • iPad - can be installed on iPad.
  • iOS - universal application which can be installed on iPod Touch, iPhone and iPad in one package.

The options available depend on the package produced at App build time. For Android apps, there is typically only 1 installation option available.

4.2.4.2. App Store Apps

App Store Apps (formerly Store Items) can be added for distribution via the App Store. You can upload native binaries for new and existing Apps for Android, iOS (Universal), iPhone & iPad. You can also assign icons to your App Store Apps which will appear in your App Store, and give your App a name and a description.

Here’s a list of all actions for App Store Apps:

  • Add new App Store Apps (typically mobile apps) for distribution.
  • Upload native binaries for new and existing Apps.
  • View the App binary history for existing Apps.
  • View the Audit Logs for App binary history for existing Apps.
  • Add Auth Policies to be used with the application.
  • Add an icon for your App.
  • Restrict a App to be displayed only to users in the same App Groups.
  • Add a App to a App Group.
4.2.4.2.1. Adding App Store Apps

To create a new App, click on the App Store Apps option in the menu. A form with a Name field will appear. Once the field has been filled out, you can click the "Create Item" button.

4.2.4.2.2. Updating App Store Apps

To update an App, click the Edit button for the App. You will then be on the "Details" tab of the Update App page.

A form with various input fields will appear.

  • The Name field: this is for the unique name of your App.
  • The Icon field: click the "Choose File" button. Choose an appropriate icon and press OK. This icon will now upload immediately and be displayed along with your App.
  • The Auth Token Field: this token is a unique string which is then used with the $fh.auth API to identify your application and perform the authentication checks you have specified in your Auth Policies.
  • The Description Field: this field is for adding a description which will be visible to viewers of your App Store.
  • Auth Policies: This swap select shows the policies you have available for use with your App Store Apps. These policies define authentication methods to be used to authenticate a user who is attempting to access your App application.
  • Restrict to Groups: This check box controls the App Groups functionality for this App. If it is checked then the user must be in one of the same App Groups as the App.
  • App Groups: This swap select shows the App Groups you have available for use with your App Store Apps. These groups restrict the visibility of these items to users who are in the same App Group or App Groups (assuming that "Restrict to Groups" is checked).

Once these fields have been filled out with the required information, you can click the "Update Item Details" button.

Note

If this is the first time you are updating a App after creating it, the Studio will show the Binaries tab on the assumption that you need to add a binary to make this App visible in your App Store.

4.2.4.2.3. Uploading Binaries

In order to upload a binary or view the history, you must first have an existing App.

4.2.4.2.3.1. Upload Binary

Click the edit button on one of your existing App Store Apps and then click the "Binaries" tab of the Update App page. To upload a binary for your App you will need to have a valid binary built either through the Platform or via Xcode or Eclipse etc…​

Select the type of binary you will be uploading and click "Choose File". Select your binary file and the upload should begin. Once it has completed it will then be available as an option for download with that App.

4.2.4.2.3.2. iOS Binaries

Next to the iOS binary options, you will notice an empty configuration field. This field is for the bundle identifier of your iOS app. You can find this identifier in the App Studio under configuration and then iPhone | iPad | iOS Universal. It is labeled under Bundle Identifier.

Also for iOS based apps you will need to upload the .ipa file. If you are building your application using the Platform, you can download this file when you do an iOS build. If you are building the app with Xcode, the .ipa file can be obtained by using the archive option.

4.2.4.2.3.3. Windows Phone 8 Binaries

The Windows Phone 8 binaries uploaded here should be signed with a company certificate. If you want to distribute the AET file along with the binary, you can upload it as the configuration file for the binary. For more details, check out Deploying an App on Windows Phone 8.

4.2.4.2.3.4. Binary History

Click the edit button on one of your existing App Store Apps and then click the "Binaries" tab of the Update App page. To view the current and older binaries click the "[+] History" link of the desired binary. This will cause a list of the binary history to be displayed.

4.2.4.3. Third Party MAM/MDM

You can enable or disable integrations with individual mobile application management (MAM) and mobile device management (MDM) providers. Enabling the integration does not result in all binaries being automatically published. To enable publishing, see Publishing App Binaries to Third-party MAM and MDM providers.

4.2.5. Audit Log

Audit logs are available for information about the number of downloads of App App binaries. In order to view the Audit Log, you must first have an existing App.

Click the edit button on one of your existing App Store Apps and then click the "Audit Logs" tab of the Update App page. This will show the current Audit Log entries for this App. The full list of Audit Log entries for all the Apps can be viewed and more comprehensively processed by clicking the "Audit Log" menu item in the "Mobile App Management" menu on the left hand side of the page.

4.2.5.1. Searching & Filtering

The search box allows you to search through the audit logs. The options at the top of the tab allows you to filter Audit Logs by :

  • App name
  • user email
  • App type (iOS, iPhone, iPad or Android)
  • number of records to display (10, 100 or 1000)

Once the filter options are selected , pressing the "Filter" button will get the matching Audit Logs. Pressing the "Reset" button will get the default Audit Logs.

4.2.6. Groups

App Store groups (formerly Store Item Groups) can be created to restrict Apps to a particular set of users. Apps can be marked as restricted to a particular set of groups, and only users in those groups will be able to view those items in the app store.

The App Groups Administration section of the App Studio allows an administrator to:

  • Create a new App Group
  • Assign users to a group
  • Assign App Store Apps to a group

4.2.6.1. Overview

Create your Users and App Store Apps as usual. When creating App Store Apps, you can mark them as being restricted to groups, you don’t have to select groups at this stage, since you may not have created them yet.

Once your Users and App Store Apps are created you can create your App Groups. The groups that you create could correspond to departments within your organisation, you might create a Sales group containing apps for your sales department, and Engineering group containing apps for your engineering department. Once the groups are created, it’s possible to assign App Store Apps and Users to them.

For example, you could assign your Sales users your Sales App Store Apps to your Sales group, so that when a Sales user logs into your App Store, they can see the Sales App Store Apps. Users and App Store Apps can be assigned to multiple groups, for example, your Sales and Engineering managers might be members of both groups, to get access to both departments App Store Apps. Of course, you don’t have to restrict your App Store Apps to groups, so that they will be visible to all users who log into your App Store.

4.2.6.2. Adding a New Group

To create a new App Group, click on the Groups option in Mobile App Management section of the menu, then click the "Create" button. A form with 2 input fields will appear.

  • The Name field: this is for the unique name of your App Group.
  • The Description Field: this field is for adding a memorable description to help describe the purpose of the group.

Once these fields have been filled out with the required information, you can click the "Create group" button.

4.2.6.3. Editing a Group

Groups can be edited to change the description text, or to assign users or Apps to the group. To edit your App Group, click on the Groups option in Mobile App Management section of the menu, then click the "Edit" button corresponding to the particular group to be edited.

  • App Store Apps: items which are currently assigned to your group.
  • Group Users: users which are currently assigned to your group.

4.2.7. Devices

Active Devices can be viewed, assigned friendly names, blocked or marked for data purge. Active Apps and Users on a Device are also available.

Here are all the actions that can be performed:

  • View Active Devices.
  • Assign friendly names to device Ids.
  • View Apps in use on devices.
  • View Users active on device.
  • Block a device — prevents any apps or users from authenticating from that device.
  • Purge device data - sends a kill pill signal to any app on the device the next time the app attempts to authenticate.

4.2.7.1. Viewing Devices

In the device list view, all the devices that have used $fh.auth to access apps will be listed here. The device label, device id, device status and the last access time will be displayed in the list. Clicking on any of the control buttons will bring you to the device update view.

The device id is a unique identifier of the device and it can not be changed. It is sent from the device and will remain the same across different apps on the same device (for hybrid or native apps). The only exception is web apps loaded in web browsers: the device id is a generated value and it is saved to the cookie. If the cookie is deleted, a new value will be generated.

4.2.7.2. Updating Devices

In this view, you can assign a friendly label name to a device, disable it from authentication or mark it for data purge. You can also check which users on the platform have been using the device and what apps have been accessed from the device.

If a device is disabled from authentication, all the apps on that particular device that are using $fh.auth to authenticate will fail and a special value will be returned to indicate that the device has been disabled. This is useful when a device is lost or stolen.

If the "Mark for Data Purge" option is checked, two thing will happen:

  • The device is disabled from authentication.
  • When apps on that device are using $fh.auth to authenticate, the authentication process will fail and a special value will be returned by the API to indicate all the existing app data should be deleted (the data delete function is subject to developers to implement).

4.2.7.3. Viewing Users of Devices

Every time $fh.auth is called from an app on a device, an access log entry will be created if the authentication process is succeeded and the user is a platform user. Thus you can see which users have been accessing from which devices in the "View Device" area.

There is a "Users" section showing a list of users ids that have been accessing using that device. Hovering on each user id will show more details about the user, and clicking on it will bring you to the user manage view of that user.

4.2.7.4. Viewing Apps on Devices

Similar to capturing user access, app information is captured every time $fh.auth is called. You can view the list of apps in the "App" section in the "View Device" area. You can hover on each App entry to get an overview of the app. If you click on any of them will bring you to the manage view of that particular App.

4.3. Analytics

Overview

Both Aggregated (reporting for all Projects in your domain) and individual Reports are available from the App Studio. Analytics users can access both the Aggregated and individual App reports from the Analytics sub Nav. Additionally, Aggregated Reports can be broken down by individual Project.

Requirements

The user must be a member of one or more teams with the following permissions:

  • Domain — Project (View)
  • Domain — Analytics (View)

Related Resources

4.3.1. Aggregated Reporting

Aggregated reporting provides a high-level cumulative view of all the reports in your domain over the selected date range. For example, the median number of active devices, or total number of app installations.

4.3.1.1. Monthly Active Devices

This is the number of devices that have made a cloud request in a 31-day period within the selected date range. A device, identified with a unique device identifier, is considered active if it makes at least one cloud request (via $fh.act or $fh.cloud) in the given period.

4.3.1.1.1. Device Identifiers

Devices are identified by the Client Unique Identifier (CUID) field, which is added to each cloud request automatically by the RHMAP client SDKs.

The CUID is generated using different APIs on each platform:

  • On iOS, the CUID value is generated using the Advertising Identifier.
  • On Android, the CUID value is generated using the Android ID.
  • For browsers that use the JavaScript SDK, the CUID is a generated random string saved in the browser (through any storage mechanism that is available). If the app data is removed, a new CUID is generated.
Note

Due to the limitations on each platform, it is not guaranteed that the value of CUID remain constant for a given device. Depending on the operating system of the device, the value could change after restarting the device, re-installation of apps, or removing app data on the device.

On iOS, different apps on the same device will get different CUID values. This means the same device will be counted as a new device for each app. This is a limitation of the iOS platform.

4.3.2. Per Project Reporting

There are 4 types of Reporting available for a Project: Device Installs, App Startups, Cloud Requests, and Active Devices. Depending on the configuration of your domain, the Cloud Requests and Active Devices reports may not be available to you.

4.3.2.1. Device Installs

Device Install reports show the number of App installs for a given date range. A Device Install is tracked the first time an App starts up on a new device and makes a call back to the cloud. Note that Device Installs differ from User Installs as tracked by App Stores in the following ways:

  • App Stores count an install as a user account performing a download — regardless of how many devices the user installs the App on. This may vary for the different report types available from the individual App Stores.
  • App stores typically report daily figures in PST timezone (in the case of Google Play and iTunes Connect), while we report in UTC.
  • An App must be started up at least once with a valid Internet connection before we track the App install. We track the install as having happened at the time of the first startup, not the time of download.

4.3.2.2. App Startups

An App Startup is tracked every time an App is launched on a previously seen device with Internet connectivity. Note that App Startups are only tracked for Apps starting up 'from cold' - that is, if an App that is running in the background is brought to the foreground, this is not tracked as an 'App Startup'.

4.3.2.3. Cloud Requests

Cloud Request reports show the number of times an App Client makes a request (using $fh.cloud) to the App Cloud.

4.3.2.4. Active Devices

Active device reports show the median number of active devices for an app over the selected date range. A device, identified with a unique device identifier, is considered active if it makes at least one cloud request (via $fh.act or $fh.cloud) in a 24-hour period (from midnight to midnight in the GMT time zone).

4.3.3. Reporting Charts & Graphs

Each of the report types can be viewed in a number of ways, depending on which chart best shows the data you are looking for. In general, more info on individual chart points and areas is available by hovering over them. If a chart shows multiple items being compared, an item can be toggled on/off by clicking on the name of it in the legend (most charts support this). Chart data can often be exported in CSV, PNG or PDF format by clicking the export button associated with an individual chart.

The from and to date range can be changed for each chart, either by selecting a range using the calendars, or by choosing one of the quick date selections for example, "Last 30 Days", "Last 7 Days", "Previous 30 Days" etc.

The data for these charts is updated daily, so the latest data will be from yesterday.

4.3.3.1. Aggregated Reporting

Aggregated Reporting on the Reporting tab gives a high level view of all the App reports, for example, By Date, By Device, By Location. You can then easily drill down into specific reports by clicking the "View Details" button associated with each analytics type.

4.3.3.2. Per-App Reporting

Per-App Reporting on the Reporting tab allows you to view reporting for an individual App by selecting an App from the list on the left - you can also search this list if you have many Apps. Once an App is selected, you will be presented with an overview of reporting for this particular App. If you’re interested in a particular metric, you can drill down via the "View Details" button.

4.3.3.3. Individual App Analysis

This Individual App Screen provides an overview of reporting for a particular type of analytics (Startups, Installs etc.). Either clicking their Report titles, or switching views via the navigation pills will show individual Charts.

4.3.3.4. By Date Analysis

This chart type shows the increase/decrease of the value over time. The y-axis represents the value (for example, installs) and the x-axis shows the date. The values for each platform series (for example, Android, iPhone) are represented with separate lines.

4.3.3.5. By Platform Analysis

The aggregated values, per platform, can be viewed as a pie chart. The aggregation of values is for the selected date range.

4.3.3.6. By Location Analysis

The total values for a date range, based on User location, can be viewed as a Geo Chart. The value per country is shown, as well as the position of that value on a scale from min to max, when hovering over a country.

4.4. Teams and Collaboration

4.4.1. Overview

The Teams and Collaboration section allows you to restrict access to specific features and entities within the Red Hat Mobile Application Platform (RHMAP).

The functionality in this section includes

  • Creating new Teams.
  • Adding Users to one or more Teams. When a User is added to a Team, they become a Member of that team. All of the Permissions assiged to the team will apply to the user.
  • Assigning Permissions to teams to restrict access to specific features of the Platform.

Teams are split into two categories

  1. Default Teams are Teams created by the Platform. The permissions and details (for example, name and description) of a Default Team are not editable. Only Users can be added/removed as Members of a Default Team.
  2. User Created Teams are teams created by a User. The details and Permissions of a User Created Team are fully editable.

4.4.1.1. Team List

This screen presents a list of currently available teams. In this screen, it is possible to

  • Display a list of Teams in grid or tabular format.
  • Search for a Team by name.
  • Filter the list of Teams by Customer and Domain.
  • Create a new Team by selecting the Create Team button.

4.4.2. Create

A Team can be created by entering a name and description and selecting the Create Team button.

4.4.3. Dashboard

The Dashboard screen displays the details of the Team. In this screen, it is possible to

  • View a list of Users currently assigned to the Team. These are refereed to as Members of a Team.
  • Edit the Members list by clicking on the Edit Members link or the Members tab located on the left of the screen.
  • View the current Permissions assigned to the Team.
  • Edit the Permissions assigned to this team by selecting the Edit Permissions link or the Permissions tab located on the left of the screen.
  • Edit the name and description of a Team.
  • Delete the currently selected team by selecting the Delete this Team button
Note

The name or description of a Default Team cannot be edited.

Note

A Default Team cannot be deleted.

4.4.4. Members

The Members section allows you manage the Members of a Team. In this screen it is possible to

  • View a list of current Members of the current Team.
  • Add a User to the team by clicking into the text area and selecting a User. The selected User is atuomatically added as a Member of the Team.
  • Remove a Member by selecting the "Remove" button beside each Member of a Team.
  • Edit the name and description of a Team by selecting the Edit button.
Note

A User can be a Member of multiple teams.

4.4.5. Permissions

The Permissions section allows you to set the Permissions associated with the currently selected Team. All Members of the team will be restricted to the Permissions associated with this team.

4.4.5.1. Key Terms

Here are key terms used when interacting with Permissions.

  • Business Object: A label describing an Entity in the Platform. (For example, Project).
  • Entity: An instance of a Business Object. (For example, A project called My First Project is an instance of the Project Business Object.) Permission: An Access Level applied to a business object for example (read,write).
  • Team: A collection of permissions that are applied to chosen business objects.
  • Hierarchy: Describes where business objects sit in relation to each other and also describes functional areas of the ui

4.4.5.2. Business Objects

All Permissions are set on Business Object.

Business Objects relate to functional areas of the Platform organised into a hierarchy that describe its structure.

As an example, setting Permissions on the Administrator element under Reseller means Setting Permissions for Administrator features for this Reseller.

4.4.5.3. Access Levels

There are three Access Levels that apply to Business Objects.

  • No Access: The Team cannot access this Business Object.
  • View: The Team can view the Business Object, but cannot perform any action that would modify the Business Object.
  • View & Edit: The Team can view the Business Object and perform actions that would modify the Business Object.

4.4.5.4. Inheritance

Business Objects are organised into a hierarchy. Business Objects can refer to a large functonal area of the Platform (for example, An Entire Domain). Sub-Business Objects refer to a more specific functional area of the Platform (for example, a Project in a Domain).

Using this structure, the Permissions of sub-Business Objects can be inherited from its parent. This is determined by the Inherit Permissions selector. If the Inherit Permissions selector is set to ON, the sub-Business Object will inherit the permissions of its parent. If Inherit Permissions is set to OFF, a specific Access Level must be set for the sub-Business Object.

Note

Business Objects can inherit Permissions from more than one level above as long as the parent level has Inherit Permissions set to ON.

The order of precedence of a Permission is determined by the Access Level set on the Business Object.

The following order is followed when determining what Access Level is set on the Business Object:

  1. Read & Write.
  2. View.
  3. No Access.
  4. Inherit Permissions.

4.4.5.5. Multiple Teams

A User can be a Member of multiple Teams. In this case, the order of precedence above is followed when determining what Access Level applies to the Business Object.

To illustrate this concept, consider the following scenario:

  • Team A sets an Access Level of Inherit Permissions on Business Object A.
  • Team B sets an Acesss Level of View on Business Object A.
  • User A is a member of Team A and Team B.

In this scenario, Business Object A will have an Access Level of View.

4.4.5.6. Filterable Business Objects

Some Business Objects have multiple instances. For example, the Project Business Object relates to any Project available on a domain. As multiple projects can exist in a Domain it is necessary to be able to apply permissions to specific Projects.

A Filterable Business Object can be filtered in two ways

  1. Setting Access All to ON will allow the Team to access all of the instances of the Business Object. For example, setting Access All to ON for the Project Business Object will allow the team to access all Projects in a Domain.
  2. Setting Access All to OFF allows you to select which instances of the Busiess Object the Team has access to.

Any instance of a Business Object created by a User is visible to that user. However the permissions assigned to the Business Object will still apply.

As an example, consider the following scenario:

  • User A is a Member of Team A.
  • The Project Business Object Access Level is set to Read & Write.
  • User A creates a new Project called Project A.
  • For Team A the Project Business Object Access All is set to OFF.
  • No instances of the Project Business Objects are selected.

In this scenario, User A will be able to see Project A only in the Projects section of the Studio.