As a core part of app security, you can restrict access to app data and pages with access controls.
You can set access controls with the following options:
|Admins Only||Only users with the built-in Admin role should have access.|
|Everyone||Everyone who is allowed to run the app has access.|
|Roles||Only members of the specified roles have access.|
|Script||Only users that are given access by a server authorization script have access. The script output must evaluate to a boolean.
Use a script when any of the following are true:
return user.getEmail().split('@') === 'google.com' && userRoles.indexOf('Leads') !== -1
This statement evaluates to true if the user's email domain is google.comand the user is a member of Leads.
|Owner or Roles||For record operations, only owners of records or members of the specified roles have access. To determine if a user is the owner of a record, App Maker compares the user's email address with the contents of a field in the record. You specify which field to use.|
|Inherited||For relations, users who can save records in the data models on both ends of the relation can associate records.|
Roles are developer-defined sets of users that you use to implement role-based access control. You can add users to a role individually or as members of a Google Group. App Maker also has a built-in Admin role that confers special permissions on users.
To use roles to customize access permissions:
- Decide which roles to use for your app.
- Add roles.
- Apply role-based access controls to models, relations, pages, and widgets. Write access controls into server scripts.
- Publish your app and add members to roles.
Best practices for roles
- Add users to the built-in Admin role only if they should have access to all data in an app deployment.
- Create roles that correspond to the groups of users for your app, the tasks that they need to complete, and the data that they need to access.
- Test role-based permissions in a restricted deployment before you deploy your app for widespread use. You can't test role-based permissions in a preview instance.
- Review role membership periodically and update the members as needed.
Use the built-in Admin role with caution
App Maker apps have one role by default, the Admin role. The Admin role is similar to developer-defined roles in the following ways:
- You can use the Admin role for role-based access controls (though it can't be combined with other roles).
- You can add or remove users in the Admin role when you deploy your app.
The Admin role is a powerful because Admins always have access to data, even when other security settings restrict access. All users with edit permission to the app project are potential members of the Admin role because they can preview and deploy the app.
When you preview an app, the app has only the Admin role and you are the only member. To test role-based access controls, you must deploy an app.
When you start to publish an app, App Maker adds you to the Admin role. You can add other users or groups to the Admin role when you publish the app or after it is published. You can remove all users from the Admin role if no one should have access to all data in production.
Define roles based on the following:
- Job roles
- Which tasks people in your organization should be able to do
- Which data people in your organization should have access to
For example, everyone in your organization can edit their own contact information. Only managers can approve vacation requests. Only members of the Finance department can view accounts receivable and accounts payable.
- Open App Maker and open the app.
- Click Settings App settings.
Under Security, locate the Access Roles section and enter names for roles.
Note: Role names can contain letters, numbers, and symbols, but not spaces. Role names are case sensitive—Finance and finance are different roles.
Set access permissions with roles
To use roles to control app security:
Assign members to roles
You create roles in the app project, but specify their members in app deployments. Thus, you can publish multiple versions of your app, such as testing and production deployments, that have different people assigned to roles. You can update the role memberships of a published app without republishing the app.
For instructions, go to Secure app deployments and add users to roles.