Feature privileges i.e. privileges that have a feature as privilege object define permissions users have on a specific feature. The effective permission a user or user group has on a feature may also include permissions that are transformed from view permissions (of all views the feature is member of and all of their parent views) or inherited from the container permission the feature belongs to.
Using feature privileges allows extremely fine grained access control (on a per feature basis). While this might be useful in many cases, a more effective and dynamic way of controlling access to features is defining view privileges with permissions that are transformed to feature permissions for all members of the view.
Table 1 lists the permissions that are available when defining feature privileges
Permission |
No |
Description, Actual actions granted |
|---|---|---|
Read (0) |
0 |
If this permission is given the user can read the data of the feature (base data, type specific data, location data, relations, configuration data, ...). This does not imply read permissions on the observations of the feature. |
Modify (1) |
1 |
If this permission is given the user can modify the data of the feature excluding configuration data. Modification includes deletion of the feature itself, setting of the editing status of the feature, and starting of approval workflows. Modify permission does not include the permission to modify observation results. Note that even if this permission is granted to a user a feature is protected against modification if it is in editing status ready. |
Comment (2) |
2 |
If this permission is given the user can write comments for a feature |
Read observations (3) |
3 |
If this permission is given the user can read the observations of a feature.
|
Modify observations (4) |
4 |
If this permission is given the user can modify observation of the feature. This includes deletion of observations Note that even if this permission is granted to a user an observation is protected against modification if it is in editing status ready. |
Comment Observations (5) |
5 |
If this permission is given the user can write comments for a feature's observations. |
Observation monitoring (6) |
6 |
If this permission is given the user can create observation monitoring definitions on that feature. |
Manage (7) |
7 |
The manage feature permission is kind of an elevated modify permission. Following data changes and functions are protected by this permission: •Delete alarms •Delete comments (on feature and observation, even if comment was issued by other user) |
Modify privileges (8) |
8 |
If this permission is granted the privileges on the feature can be modified. Still the modifying user can only modify feature privileges (add or remove) with a permission that the modifying user is granted himself. |
Manage approval workflows (9) |
9 |
If this permission is granted the user can abort and obsolete approval work flows applied to this feature or to observations of this feature. |
Set approval obsolete (10) |
10 |
Setting started approval work flows to obsolete. |
Modify feature directive |
11 |
Table 1: Permissions that can be granted to feature privilege objects
The permission to read the base data of features is the list permission. This permission is either granted by defining a privilege on a view with permission List features (2) or automatically granted by the system if a user has read permissions on a feature that relates to this feature.
If a feature is member of a platform it also inherits all privileges of that platform feature. Note that the platform relation is the only feature relation that will populate privileges to all related features.
A user creating a feature will be automatically granted the permission Read (0) on that feature.This behavior can be disabled with the instance configuration file.
