. . .

Application Roles

Customer roles

Applications are managed by customers in ApiOmat. Usually, one customer owns a set of applications with no other customers able to access them. The privilege to access or modify apps is controlled by roles per app for each customer. That is, in the very basic example each customer has the highest role named ADMIN for his own apps. Using a given set of roles, other (existing) customers can be added to a specific app and get access to e.g. writing data or using the SDKs.


Speaking in data structures, the role for an app is stored in a map with the customer and a key 

appname _ systemname  --> [ set of roles ]

Roles are organized hierarchically, which means that a customer with the role WRITE automatically has access to all other roles with lower priority, like READ. Also, a customer may have more than one role like DEPLOY and WRITE_DATA.

The structure of the available roles is explained in the next paragraph.

Structure of roles

Master Role

Sub Roles

ADMIN





GRANT

DEPLOY

READ_OPLOG



WRITE

WRITE_DATA




READ

DOWNLOAD_SDK

READ_DATA

READ_LOGS

READ_HEALTH

Master roles have a set of sub roles. If a customer owns a master role, they automatically have all sub roles belonging to the master role (same line). To the contrary, if a customer has a sub role, this does not necessarily mean that they have access to the other sub roles of the master role.

If a customer has a higher role than nessecary,then they are permitted to execute the action.

Example

A customer with a DEPLOY role granted has the following inherited roles: WRITE, WRITE_DATA, READ, DOWNLOAD_SDK, READ_DATA, READ_LOGS and READ_ANALYTICS.

Application role limitations

The following table shows limitations in detail of the possible customer roles.

Application Role

Description

Effects (yambas)

Effects (dashboard)

ADMIN

Administrator and creator of an app

  • Can do everything with own app

  • can see push, xml csv and restore in My Module tab

  • can do everything

  • Class Editor and My Module depends on module role

GRANT

Customer of an app who can give all roles except ADMIN to that app to further customers

Can not:

  • Delete app

  • similar to admin

  • can see everything, can edit everything

  • can deploy

  • no upgrade, no delete of backend

  • can add other customers to app in Admin screen

  • can see push, xml, csv and restore in My Modules

  • Class Editor and My Modules depends on module role

DEPLOY

Customer who can read & write on app, and can deploy additionally

Can not:

  • Give/revoke roles for app to other customers

  • Delete app


  • similar to admin

  • can see everything, can edit everything

  • can deploy

  • no upgrade, no delete of backend

  • can see push, xml, csv and restore in My Modules

  • Class Editor and My Modules depends on module role

WRITE

Customer who can read & write data structures and data on app

Can not:

  • all actions mentioned in DEPLOY

  • deploy/undeploy app



  • can see everything, can edit everything

  • can not see push, xml, csv and restore in My Modules

  • no deploy

  • no upgrade, no delete of backend

  • Class Editor and My Modules depends on module role

WRITE_DATA

Customer who can only read application structures and write data

Can not:

  • all actions mentioned above

  • change used modules of app

  • change app configuration

  • can see everything, but can only edit data

  • Unable to edit and view the module code

  • can not see push, xml, csv and restore in My Modules

  • can not add, edit, modify or remove modules

  • classEditor is readonly

  • no deploy

  • no upgrade, no delete of backend

  • Class Editor and My Modules depends on module role

READ

Customer who can only read application structures and data

Can not:

  • all actions mentioned above

  • create/update/delete data of app


DOWNLOAD_SDK

Customer who can only download SDKs of app, typically a frontend developer

Can not:

  • all actions mentioned above

  • read data of app

  • read logs

  • can only see the "download sdk" tab

  • can not see log or log icon

  • can not see configuration dialog

  • no deploy

  • no upgrade, no delete of backend

READ_DATA

Customer who can only read the data of an app

Can not:

  • all actions mentioned in READ and above

  • download SDKs

  • read logs


READ_LOGS

Customer who can only read the logs of an app

Can not:

  • all actions mentioned in READ and above

  • download SDKs

  • read data

  • can only see logs

  • Unable to edit data

  • Unable to read anything

  • no upgrade, no delete of backend

  • can not see configuration dialog

  • no deploy

READ_ANALYTICS

Customer who can only view the Analytics information of an app

Can not:

  • all actions mentioned in READ and above

  • download SDKs

  • read logs

  • read data

READ_HEALTH

Customer who can only view the health status of a module

Can not:

  • all actions mentioned in READ and above

  • download SDKs

  • read data

  • read logs

  • can check the health status of modules based on its own app

READ_OPLOG

Customer or Organization who can only read oplogs.

Can not:

  • do everything with app

  • can only read oplogs

  • The yambas returns only usable modules. Usable modules can be configured.

Dashboard 3

Instead of deploying and undeploying your app, you can set your app active/inactive and build each module separately in Dashboard 3. With this new mechanism the application role DEPLOY was removed and WRITE will contain the features of DEPLOY which are not in WRITE_DATA. Setting the app active or inactive requires the role WRITE. The right to build modules is completely independent from the application role and depends only of the role for the specific module.