Permissions

Permissions of Netilion objects

A user who created a Netilion object has full ownership over it.
To share objects with other users, the owner grants permissions on this Netilion object. Permissions can be given to a single user or to a user group.
Check your user groups here.

The permission types in Netilion are:

• can_read: the user can read the object, its masterdata and values in detail.
• can_update: the user can change the object’s attributes and masterdata.
• can_delete: the user can delete the object including all its values.
• can_permit: the user can grant permissions to others or remove existing permissions on the object

Each permission stands alone. There is no built in hierarchy. We recommend to implement a logical build-up on the clients side. Such as to add read permission when a user gives permission to update, delete or permit.

See how to grant permissions on existing objects in the Connect Subscription section.

Sample Request

A sample request to the permissions’ endpoint.

POST https://netilion.endress.com/v1/permissions

Body

{
  "permission_type": [
    "can_read"
  ],
  "assignable": {
    "id": 4,
    "type": "Usergroup"
  },
  "permitable": {
    "id": 55,
    "type": "Asset"
  }
}

Assignable

assignable are the recipients of the permissions. We support two types:

• User
• Usergroup

The specified id is either of the user or the user group you want to grant permissions to.

Permitable

permitable is the Netilion object you want to grant access to. The supported types are:

• Asset
• Instrumentation
• Node
• Document
• EDM::EdgeDevice
• Event
• Usergroup
• APIKey
• ClientApplication
• BillOfMaterial
• PurchaseOrder
• Delivery
• Quotation
• RequestOfQuotation
• Recipe

Inherited Permissions

Once Netilion objects are arranged in a plant structure, the permissions will be passed down from top to bottom. Imagine a node at the top, instrumentations underneath with assets installed on it. If you grant full permissions to the top node, the same permissions will be effective on all objects that are placed below it.

Moving an Asset out of its location in Netilion - e.g. removing it from its instrumentation - will remove access for users who only saw it because of its location. This is the case if there is no explicit permission for the asset object.

We guarantee that there will always be an owner of the asset. The last permissions cannot be removed. It must belong to someone.

Inheritence access flows down from top to bottom through the plant structure and from main objects to their attribute objects, as illustrated in this graph.

Inheritance also applies to documents, values and specifications of an asset or an instrumentation. If you can update the asset, you can update its documents. This applies to all attribute objects of an asset, instrumentation or node: they inherit the same permissions.

In short, the permission inheritance applies to
Node > Instrumentation > Asset

It also applies for these examples
Instrumentation > Documents
Instrumentation > Specifications
Instrumentation > Values

Asset > Documents
Asset > Specifications
Asset > Values

and all the way down:
Node > Instrumentation > Asset > Document

Tenant vs Permission

Having a tenant architecture combined with object permissions can be confusing.
Read more about the differences in the tenant section.