The AppGyver Enterprise Documentation

Welcome to the AppGyver Enterprise Builder Documentation. Information about the different aspects of Enterprise Builder's functions may be found in the guides presented here. More guides and tutorials will be added in the following weeks.

Feel free to suggest edits on any parts of the documentation that feel unclear.

Get Started    

Users and Permissions

Composer supports group-based user roles, with fine-grained permissions (via Access-Control Lists, or ACL for short) down to individual data field level.

For basic information on users, groups and permissions, please see the video below.

Adding and Managing Users

Click on the cog icon in the main top menu and select Application Users to bring up the 'Users* index.

In the top middle is a list of your app's end users. If you are using AppGyver Auth, it will by default have just the auto-generated demo user. The demo user's password is what you set when creating the app.

Let's create a new user. Click on the Add User button. (You can click the Show All Users button in the top right corner to return to the Users index.)

Give the user an email (, full name (Seth Salesguy) and a password (cars are awesome). You can also upload a profile avatar for the user that will be used in certain parts of the app, e.g. by the Tasks or Chat modules. Click Create User.

If you now publish your changes and try to login (the user's email is used as the username when logging in), you won't see any data. That's because we haven't set up any permissions for our new user.

You can also edit and delete users by clicking on them.

Password Best Practices

End users are able to change their passwords from within the app. If you are using AppGyver Auth, you can just use some random passwords for users and tell them to change them when they first log in.

User Permissions

Permissions can be granted for an entire resource in two different ways: individual user permissions and group permissions. In addition, you can define creator's permissions – record-level permissions that are auto-applied for the creator of a record.

Setting User Permissions

Choose an user and click on the Edit Permissions button. You will see a view like the one below.

The dropdown menu lets you select which resource's permissions to edit, and the checkboxes let you change the permissions. The selections are:

  • Read: Users can list and read all records in the collection.
  • Create: Users can create new records.
  • Edit: Users can edit existing records.
  • Remove: Users can delete records.
  • Change ACL: Users can change the access rights of an individual record, e.g. giving a certain customer read rights for a Report record.

The permissions affect the UI of the end app – if an user does not have edit permissions, the Edit button is hidden.

User Groups

User Groups are a useful way of quickly assigning permissions to users that should have similar rights. You can create them using the Add Group button in the Users index.

Group and individual user permissions work the same way. If multiple sources contribute to an user's permissions, they are always added together (i.e. a group cannot remove permissions, just add them). You can see the calculated ACL for each resource for a single user in their details view.

Note that the All Users group, which contains all users of your app, has full rights to all resources by default. You might want to restrict these before publishing your app.

Setting a group permission for the **Customers** resource to have just Read and Create permissions.

Setting a group permission for the Customers resource to have just Read and Create permissions.

Creator's Permissions

The final way to define permissions is via the Creator's permissions section on the Users index page.

The permissions added via the Add Default Permission button apply to all records created by an user. Thus, you can make it so that an user has e.g. the right to edit and remove only the records he himself has created, but view all other records.

Letting an User See Only Her Own Records

A common case is that an user should see only the records he or she has created, but not anyone else's – examples would be expense reports or vacation requests.

To make this possible, you need set up permissions so that all users in the appropriate group have only Create rights for the resource.

Then, the creator's permissions for that resources are set to Read, Edit and Remove.

Now, the users have full access to records they create, but cannot see anyone else's records.

Field Level Permissions

Finally, you have field or column level ACL – being able to hide certain fields or make them read-only. This is managed under the Data tab. After choosing a record, you can click on the Manage Field Permissions to open up the following view.

Field permissions for a **Products** field, set up so that the **All Users** group cannot edit the field, while **Admin Users** have full access.

Field permissions for a Products field, set up so that the All Users group cannot edit the field, while Admin Users have full access.

By default, you have the See field and Edit field permissions checked for the All Users group. You can click on the Add permissions dropdown to bring groups and individual users into the table and set their permissions.

If an user doesn't have Edit field permissions, the field will be hidden when creating a record, and disabled when editing it.

Note that completely hidden fields (i.e. no user groups have See field access) can still be edited and read via the data JavaScript API, allowing you to store e.g. JSON data into hidden fields via the Logic Editor.

Users and Permissions