Difference between revisions of "Security/Data restrictions"
old>Admin |
m (38 revisions imported) |
||
| (28 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
== Data | == Understanding permissions == | ||
Data access is retricted in two ways | |||
* '''Mandatory''' permissions granting access to | |||
** Certain groups of fields (blocks) | |||
** Records in certain status | |||
* '''Optional''' filters binding certain data to certain users | |||
** Owner user (the user that created the record) | |||
** List of users (dynamic list of users for each record) | |||
** Per group (group property) | |||
If a user has no active permissions, they will not have any kind of access to the solution. Filters on the otherhand is just considered to be additional restrictions, limiting the access granted by permissions. | |||
In both cases the security restrictions allways apply, even during system access, API interaction, intergration etc. | |||
== Permissions [mandatory] == | |||
Permissions to solutions are granted as a sum of multiple permissions. | |||
Each permission contains | |||
* Group | |||
* 0-1 Status (records have status) | |||
* 0-1 Blocks (fields belong to blocks) | |||
* Allow read | |||
* Allow write | |||
Permissions stack in an aggregate like manner, allowing to build complex structures from different fragments. This is also the reason that the Allow read and Allow write properties can be set to empty values (typically for generic permissions). | |||
=== Differentiated FIELD level access === | |||
Fields belong to blocks. Permissions may be bound to such a block. | |||
A permission with a block specified will ONLY apply to the fields belonging to this block. | |||
=== Differentiated STATE level access === | |||
Permissions may be bound to a certain status. | |||
A permission with a status specified will ONLY apply to records in this status. | |||
== Filters [optional] == | |||
All ownership options can be overrided by belonging to a certain group, that ignores all types of filters (3 below). | All ownership options can be overrided by belonging to a certain group, that ignores all types of filters (3 below). | ||
Access to configuration: | |||
Designer > [solution] > Security - Filters | |||
=== Ownership by data exclusive group === | === Ownership by data exclusive group === | ||
[[Fieldtype/ | Designer attribute: Use Exclusive groups for access control | ||
The solution contains a '''[[Fieldtype/Exclusive group|Exclusive group]]''' that defines a group with access to this piece of data. | |||
* Scope: Group | * Scope: Group | ||
* Cardinality: One | * Cardinality: One | ||
Designer | === Ownership by data member lists === | ||
Designer attribute: Use Lists of members for each item | |||
The solution contains a '''[[Fieldtype/Member list|memberlist]]''' field where users can have their access added or removed. Behind the scenes a table with a relation between the record and the user is maintained. | |||
The solution contains a [Fieldtype/Member list|memberlist] field where users can have their access added or removed. Behind the scenes a table with a relation between the record and the user is maintained. | |||
* Scope: User | * Scope: User | ||
| Line 18: | Line 64: | ||
=== Ownership by being the creator === | === Ownership by being the creator === | ||
Designer attribute: Use Creator only restriction (ignore group recommended) | |||
You must have created this record in order to see access it. | You must have created this record in order to see access it. | ||
* Scope: User | * Scope: User | ||
* Cardinality: One | * Cardinality: One | ||
Latest revision as of 12:55, 10 December 2021
Understanding permissions
Data access is retricted in two ways
- Mandatory permissions granting access to
- Certain groups of fields (blocks)
- Records in certain status
- Optional filters binding certain data to certain users
- Owner user (the user that created the record)
- List of users (dynamic list of users for each record)
- Per group (group property)
If a user has no active permissions, they will not have any kind of access to the solution. Filters on the otherhand is just considered to be additional restrictions, limiting the access granted by permissions.
In both cases the security restrictions allways apply, even during system access, API interaction, intergration etc.
Permissions [mandatory]
Permissions to solutions are granted as a sum of multiple permissions.
Each permission contains
- Group
- 0-1 Status (records have status)
- 0-1 Blocks (fields belong to blocks)
- Allow read
- Allow write
Permissions stack in an aggregate like manner, allowing to build complex structures from different fragments. This is also the reason that the Allow read and Allow write properties can be set to empty values (typically for generic permissions).
Differentiated FIELD level access
Fields belong to blocks. Permissions may be bound to such a block.
A permission with a block specified will ONLY apply to the fields belonging to this block.
Differentiated STATE level access
Permissions may be bound to a certain status.
A permission with a status specified will ONLY apply to records in this status.
Filters [optional]
All ownership options can be overrided by belonging to a certain group, that ignores all types of filters (3 below).
Access to configuration:
Designer > [solution] > Security - Filters
Ownership by data exclusive group
Designer attribute: Use Exclusive groups for access control
The solution contains a Exclusive group that defines a group with access to this piece of data.
- Scope: Group
- Cardinality: One
Ownership by data member lists
Designer attribute: Use Lists of members for each item
The solution contains a memberlist field where users can have their access added or removed. Behind the scenes a table with a relation between the record and the user is maintained.
- Scope: User
- Cardinality: Many
Ownership by being the creator
Designer attribute: Use Creator only restriction (ignore group recommended)
You must have created this record in order to see access it.
- Scope: User
- Cardinality: One