Difference between revisions of "Security/Data restrictions"

From TempusServa wiki
Jump to navigation Jump to search
old>Admin
old>Admin
Line 29: Line 29:
=== Differentiated FIELD level access ===
=== Differentiated FIELD level access ===
Fields belong to blocks.
Fields belong to blocks.
A permission with a block specified will ONLY apply to the fields belonging to this block.


=== Differentiated STATE level access ===
=== Differentiated STATE level access ===

Revision as of 10:56, 9 March 2013

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
    • List of users
    • Per group

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)
  • Read permission
  • Write permission

Differentiated FIELD level access

Fields belong to blocks.

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.

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