Roles and the Hierarchy
The Roles complement the hierarchy. Together, they define the security authorizations in FieldLogs.
When you create a member, you assign one or more roles to this user. In a role you can add security rules, that are made of a securable object and an access right. These security rules define what the role gives access to.
 |
Note
If a user has the same security rule in two different roles, these security rules are merged.
For example:
A user has the role Planner. This role contains the following security rules:
Web UI - Dashboard, Planning, Tasks, Roles, Security Exceptions, Data
Jobs - Read
Templates - Read
Tasks - All (Read, Write, Assign, Delete)
Roles - Read
Security Exceptions - All (Read and Delete)
Objects - Read
Data - Write
This means that a user with the role Planner:
Can access the sections and sub-sections , , , , and ;
Has the authorization to see jobs, templates, roles and objects;
Has the authorization to edit data;
Has all authorizations on tasks and security exceptions.
For more details about access rights, see the topic Security rules.
What are securable objects?
FieldLogs key internal data structure, graphical elements (such as user interface key elements), or additional functions are securable objects. You can define roles to allow the users to have access and do actions (read, write, exports, etc.) on these securable objects.
Templates, tasks and menu items are examples of securable objects.
You can manage the authorizations on securable objects through the following tabs:
, to manage the roles that you will assign to your users,
Roles are a set of security rules that are grouped together. One or more roles can be assigned to a user.
For example, the Read access on templates is a security rule. This security rule allows the user to see the templates that are visible to him according to its place in the hierarchy. At a larger level, the authorizations granted by roles are combined with the concept of visibility (see Understanding the hierarchy).
, to create an access bridge between two groups or two user sets,
, to create an access right path between a user and a specific content via an authorization request,
, to be used in scripts for external API calls.
How does the role interact with the hierarchy?
Here is an example of hierarchy:
Let's take these two situations:
Situation 1
User | chief_operations@newcorp.com | technician1@newcorp.com |
Role | Planner | Field employee |
Group | Oil&Gas Operations | Oil&Gas Operations |
A template is published in the public template database Operations DB, which is attached to the group Oil&Gas Operations.
chief_operations@newcorp.com assigns this template as a task to technician1@newcorp.com.
technician1@newcorp.com can see and run the task assigned by chief_operations@newcorp.com.
They can see each other and the template published in Operations DB as the two users and the template database are in the same group.
Situation 2
User | chief_contractor@newcorp.com | technician1@newcorp.com |
Role | Planner | Field employee |
Group | Contractor 1 | Oil&Gas Operations |
A template is published in the public template database Operations DB, which is attached to the group Oil&Gas Operations.
chief_contractor@newcorp.com cannot assign this template as a task to the user technician1@newcorp.com.
chief_contractor@newcorp.com cannot see technician1@newcorp.com as they are in two separate groups and technician1@newcorp.com is at a higher level in the hierarchy.
Tip
You can exceptionally bypass the hierarchy by creating a security exception, but the user allowing the security exception and the action must be appropriately authorized.
Note
Roles are also used in the conditions, in lifecycles and in the routing table.