Common Table Record Permissions

There is a method to associate a set of permissions with every record in the common table. This feature is called "Per-record permissions" is may be enabled or disabled for a particular table by editing basic properties of a table.

Record permissions define which Iotellect Server contexts have access to this record. This feature is used in Master Properties of Group Members use cases. When a group or Data Terminal context retrieves the contents of a common table, it only gets records to which it has permissions.

Example:

Let's say that the common table contains a checklist of actions to be performed with certain hardware devices on startup. This list is written to every device using the Integration with Data Terminals feature, causing the device's operator to complete all checkup items during device startup. Obviously, not all device types need the same items in the checklist. Sure, most of them may need an item such as "Swipe your ID card" (for a vehicle control system), but only some would need an item such as "Verify there are no leaks in hydraulics system". In a scenario like this, per-record permissions come in handy.

For every record in this hypothetical Checklist table, we may specify a list of Devices (Device contexts, to be precise) to which it applies. We can even specify them as groups (see below). A given checkup item (record) will be written only to the Devices which are allowed to access it per this table.

Common table per-record permissions differ from user's permission tables. A user's permissions define which contexts he may access, and which operations he may execute in every such context. In contrast, common table record permissions define which contexts may access a given record. Currently, this is only useful in the following scenarios:

For Integration with Groups, the permission list may contain only Group contexts. Only groups specified in the list will write this record for their members.

For Integration with Data Terminals, the permission list may contain Data Terminal contexts and Group contexts of Data Terminal groups. In the former case, the record will be accessible by a certain Data Terminal. In the latter case, it will be accessible by all Data Terminals in a group.

If you're trying to keep a table secure, you'd better control who can edit the table itself -- don't just set per-record permissions.

When per-record permissions are enabled, every record in table contains two additional fields:

  • Access to record
  • Permissions

The Access to record field has three possible values: Enabled, Disabled and Determined by permissions. When access is Enabled, per-record permissions are switched off for this record, and every group or Data Terminal has access to it. When access is Disabled, no groups and Devices will receive this record when retrieving the table's contents. And when the field it set to Determined by permissions, you can set a list of groups or Devices which will have access to this record. If a user is allowed to edit the table itself, he may modify per-record permissions.

When the Integration with Devices feature is used to work with a common table, the permission list may contain not only ordinary Data Terminal contexts, but also Data Terminal groups. When a Data Terminal group is added to the permissions list of a specific common table record, all of its members will have access to this record.

Was this page helpful?