Difference between revisions of "Features/Access control"
(Created page with "== Usages == == Field access == == Data ownership == Data ownership will restrict which record in an entity the user can see. Different access restrictions exists * Group membership * Personal record * Access control lists ** Named users ** Named groups == Other access controls == Many other components in the platform have configuration options to make them available to a single group * Available buttons in the UI * Status available for selection * Widgets displaye...") |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Usages == | == Usages == | ||
TS are based on a principle of building ONE application for MANY users. | |||
Instead of building and maintaining multiple user interfaces, rules declarations restrict what a user can do | |||
* What fields are available | |||
* When records are avaible | |||
* Whet records ara available | |||
Practically any set of rules can be built combining Field access and Dataownership. | |||
== Access policies == | |||
The basic Acccess policies controls the users access to | |||
* Which Fields are available | |||
* Which Status can be accessed | |||
Permission policies statck together and include | |||
* User group | |||
* Field group (optional) | |||
* Status (optional) | |||
This allows for many combination usecases such as | |||
Let Manageres READ all data anytime | |||
Let Manageres EDIT the pricing when Status is Draft | |||
Let Customers READ all data when Status is Order delivered | |||
Let Administrators EDIT anything anytime except Pricing | |||
== Data ownership == | == Data ownership == | ||
| Line 9: | Line 30: | ||
Different access restrictions exists | Different access restrictions exists | ||
* Group membership | * Group membership (aka Exclusive groups) | ||
* Personal record | * Personal record | ||
* Access control lists | * Access control lists | ||
** Named users | ** Named users | ||
** Named groups | ** Named groups | ||
Classic [[Features/Multi_tenancy|Multi tenancy]] is bult by utilizing group data ownership. | |||
Note: Depending on the setup the server can run with single or multiple Exclusive groups. | |||
== Other access controls == | == Other access controls == | ||
Latest revision as of 13:55, 10 November 2024
Usages
TS are based on a principle of building ONE application for MANY users.
Instead of building and maintaining multiple user interfaces, rules declarations restrict what a user can do
- What fields are available
- When records are avaible
- Whet records ara available
Practically any set of rules can be built combining Field access and Dataownership.
Access policies
The basic Acccess policies controls the users access to
- Which Fields are available
- Which Status can be accessed
Permission policies statck together and include
- User group
- Field group (optional)
- Status (optional)
This allows for many combination usecases such as
Let Manageres READ all data anytime Let Manageres EDIT the pricing when Status is Draft Let Customers READ all data when Status is Order delivered Let Administrators EDIT anything anytime except Pricing
Data ownership
Data ownership will restrict which record in an entity the user can see.
Different access restrictions exists
- Group membership (aka Exclusive groups)
- Personal record
- Access control lists
- Named users
- Named groups
Classic Multi tenancy is bult by utilizing group data ownership.
Note: Depending on the setup the server can run with single or multiple Exclusive groups.
Other access controls
Many other components in the platform have configuration options to make them available to a single group
- Available buttons in the UI
- Status available for selection
- Widgets displayed in dashboards