Data Buckets
Data rules are defined in terms of buckets. A bucket is used to group objects together to synchronize these and/or grant access permissions to one or more users.
The following describes the various configuration options for data buckets, which form the basis of both sync rules and data ACLs.
Data buckets are defined in the data_rules.xml
file in OXIDE.
Global buckets
The simplest data buckets are global buckets.
These buckets are typically used for data that stays fairly constant over time, e.g. categories used in dropdown lists. This data is typically synced to all users and contains little or no access restrictions.
In the below example, all category
and subcategory
objects are synched to all users, and all users have unrestricted read and write access to these objects.
Models can have conditions to only group a subset of their objects:
In some cases, data rules should apply only to some users, e.g. only to admin users or only to technicians. This is possible by specifying a via
attribute on the bucket. In the below example, all part_type
objects are synced to technicians, and these users have read-only access to these objects.
Object-specific buckets
Object-specific buckets each have a bucket root which defines the grouping. All objects inside the group must have a direct belongs-to
relationship to the root object.
Users are then linked to the bucket roots by a path that traverses one or more relationships (belongs-to
or has-many
).
As an example suppose that we want to split data by region. Each user belongs to a specific region, and we only want to provide access to client data to users within the same region.
In this case, we'd define the Region as the root of the bucket. We place clients in the bucket according to the belongs-to
relationship, and sync the region bucket to each user with no access restrictions:
Suppose clients have additional info that we need to include, e.g. contacts. To include this in the region bucket, it needs an explicit belongs-to
relationship to the region.
Here's the updated data model:
And the corresponding data rules:
Same as with global buckets, we can add conditions on the models:
We can also add conditions on the root object:
Or on the user:
Root objects can also be linked to the user via a has-many
relationship:
The via
attribute
via
attributeIn the case of object-specific buckets, the via
attribute indicates the path to take from the user object to the root of the bucket. For each user, this path can result in zero, one or many bucket roots.
Bucket root
The root objects are automatically included in the bucket. It is possible to overwrite their sync and access rules - see this section.
The via
path can contain any number of belongs-to
or has-many
relationships, along with an optional condition as a filter on each.
Here are some examples:
For global buckets, the via
attribute works similarly. However, instead of having separate bucket roots, there is only a single bucket that will be evaluated if the via
field has any results.
Limitation: Number of bucket roots
The number of bucket roots per user may never exceed more than 200.
If it does, the user will not be able to synchronize. Sync performance also degrades as the number of buckets per user increases, so it is recommended to keep this to fewer than 50 per user.
Note: Global buckets are included in this limit - each global-bucket
counts as one bucket toward the limit.
Frequently Changing Bucket Roots - pre v4.24
Older versions of the container (before version 4.24) do not handle changing bucket roots per user efficiently. For this reason, it is recommended to keep the bucket roots mostly static per user. For example, in our earlier example, it is not expected that a user's region
will change often. If however, we use something like current_assignment
as the root, the sync performance will suffer every time current_assignment
changes.
Newer container versions (4.24 and later) handle this more efficiently and do not have this issue.
Here are some examples:
Conditions
Conditions can be applied to any single field for models or relationships specified inside global buckets or object-specific buckets.
Condition limit
Only one condition can be set per model or relationship.
The following operators are available:
The following are valid values to compare against:
Last updated