Security
In the section, you can manage:
The access of users to securable objects,
The actions users can perform on securable objects.
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.
Deny first, allow explicitly
In FieldLogs, to understand the access rights to data and functionalities, you need to understand the principle of "deny first, allow explicitly".
The solution is based on an architecture that, at first, denies the access of a user to any data or functionality. To let a user access specific data or functionalities, you must give him the relevant security rule in at least one of his roles. You can also exceptionally allow this access through a data bridge or a security exception approved by a user authorized to give this access.