Access Roles
OpenTera access to REST API is limited depending on the role the currently logged on usertype (user, participant, device, service) has for a specific service.
Since the core module of OpenTera (TeraServer) is a service by itself, it defines its own access levels based on projects and sites objects (see database objects for more information on those objects). Thus, it adheres to the service-role model.
As users, participants, devices and services only have access to their particular API, roles are not defined the same depending on the API.
The tables below use this legend:
: Role has access to that feature
: Role doesn’t has access to that feature
: Role has limited access to this feature. Typically, in case of an update, only certain fields
can be modified.
Users
This table shows the various features that are available according the user groups access level, and for super admin access.
Data access
Data [1] |
Super Admin |
Site Role: Admin [2] |
Site Role: User [3] |
Project Role: Admin [4] |
Project Role: User |
|---|---|---|---|---|---|
Assets: Create |
|
|
|
|
|
Assets: Read |
|
|
|
|
|
Assets: Update |
|
|
|
|
|
Assets: Delete |
|
|
|
|
|
Devices: Create |
|
|
|
|
|
Devices: Delete |
|
|
|
|
|
Participant Groups: Create |
|
|
|
|
|
Participant Groups: Read |
|
|
|
|
|
Participant Groups: Update |
|
|
|
|
|
Participant Groups: Delete |
|
|
|
|
|
Participants: Create |
|
|
|
|
|
Participants: Read |
|
|
|
|
|
Participants: Update |
|
|
|
|
|
Participants: Delete |
|
|
|
|
|
Projects: Create |
|
|
|
|
|
Projects: Read |
|
|
|
|
|
Projects: Update |
|
|
|
|
|
Projects: Delete |
|
|
|
|
|
Services: Create |
|
|
|
|
|
Services: Read |
|
|
|
|
|
Services: Update |
|
|
|
|
|
Services: Delete |
|
|
|
|
|
Sessions: Create |
|
|
|
|
|
Sessions: Read |
|
|
|
|
|
Sessions: Update |
|
|
|
|
|
Sessions: Delete |
|
|
|
|
|
Sessions Types: Create |
|
|
|
|
|
Sessions Types: Read |
|
|
|
|
|
Sessions Types: Update |
|
|
|
|
|
Sessions Types: Delete |
|
|
|
|
|
Sessions Events: Create |
|
|
|
|
|
Sessions Events: Read |
|
|
|
|
|
Sessions Events: Update |
|
|
|
|
|
Sessions Events: Delete |
|
|
|
|
|
Sites: Create |
|
|
|
|
|
Sites: Read |
|
|
|
|
|
Sites: Update |
|
|
|
|
|
Sites: Delete |
|
|
|
|
|
System Services |
|
|
|
|
|
System Service: Logger: Read |
|
|
|
|
|
Users: Create |
|
|
|
|
|
Users: Read |
|
|
|
|
|
Users: Update |
|
|
|
|
|
Users: Delete |
|
|
|
|
|
User Groups: Create |
|
|
|
|
|
User Groups: Read |
|
|
|
|
|
User Groups: Update |
|
|
|
|
|
User Groups: Delete |
|
|
|
|
|
[1] All data are filtered according to the specific user group access. For example, if Sites: Read is done, only sites where the user have access with its user groups are read.
[2] Super admins always have a Site Role: Admin on all sites in the system
[3] Any user group with a role in a project automatically have a Site Role: User access
[4] Any user group with a Site Role: Admin automatically have a Project Role: Admin
Features
Feature [1] |
Super Admin |
Site Role: Admin [2] |
Site Role: User [3] |
Project Role: Admin [4] |
Project Role: User |
|---|---|---|---|---|---|
Data entry forms request |
|
|
|
|
|
Device - Participant assignation |
|
|
|
|
|
Device - Project assignation |
|
|
|
|
|
Device - Site assignation |
|
|
|
|
|
Login |
|
|
|
|
|
Logout |
|
|
|
|
|
Online users list |
|
|
|
|
|
Manage project access |
|
|
|
|
|
Manage services roles |
|
|
|
|
|
Manage site access |
|
|
|
|
|
Service configuration (self) |
|
|
|
|
|
Service configuration (others) |
|
|
|
|
|
Service - Project assignation |
|
|
|
|
|
Session Type - Device Type assignation |
|
|
|
|
|
Session Type - Project assignation |
|
|
|
|
|
Statistics module |
|
|
|
|
|
Managing sessions start/stop/resume |
|
|
|
|
|
[1] All features are limited to data that the user can access. For example, if an user can’t access a specific project, that user won’t be able to use any feature on that project.
[2] Super admins always have a Site Role: Admin on all sites in the system
[3] Any user group with a role in a project automatically have a Site Role: User access
[4] Any user group with a Site Role: Admin automatically have a Project Role: Admin
Participants
Access roles for participants are quite simpler than the users access roles. A participant only has access to objects that are directly linked to them. For example, a participant can only query the devices and sessions that are associated to it.
No write access is provided as of now to those objects, while this will change in the future.
Devices
A device only has access to objects that are directly linked to them. For example, a device can only query the participants associated to it or the sessions into which the device was involved.
Similarly, a device can only create data related to an object linked to it. For example, it can only create assets for a session into which it was involved.
Services
Services don’t have specific roles. As they likely require more access than a user, a participant or a device, they don’t have any specific limitation based on roles on what they can do with their API.
Of course, not all objects are exposed with the service API, and login and authentication mechanisms are still required to access that API to limit access to those features.