Restrictive Conditions

When an account is shared with other actors, in addition to roles, it is possible to assign attribute-based restrictive conditions to these actors in order to control their access rights on a deeper level.

For example, factory administrators (and associated API keys) can be restricted to a certain place so that they are only able to access data scoped to that place, or a brand inspector restricted to a given brand - which is a base field of a product - will only be able to access products of that brand.

Any admin Operator allowed to manage Operator Accesses is able to apply these restrictions to their subordinates. These restrictions can also be applied to Access Tokens.


📘

Do I need to assign conditions to my actors?

Actors that have no restrictive conditions can access all data within a given resource.
For example, actors with permissions to read products and no conditions will have access to all products in their accounts, whereas actors with the same permissions but that have conditions on productBrand:brand_one will only be able to access products that have brand_one as brand base field.

See Managing Conditions to learn how to manage restrictive conditions.


Available Restrictive Conditions

Our platform currently supports the following restrictive conditions:

Restriction name

Syntax

Supported APIs

Access Policy Id

"accessPolicyId:<ACCESS_POLICY_ID>"

Access Policies API , Operator Access API

Factory Id

"factoryId:<FACTORY_ID>"

None

These can be added to an Operator Access payload and will then be reflected on each supported API interactions. In some cases the returned data will be filtered, whilst in others it will impact the change or creation of resources. Find more about how each condition behaves on their supported API pages under their respective Restrictive conditions sections.

Updated 6 months ago

Restrictive Conditions


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.