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.
<data-rules version="3">
<global-bucket>
<model name="category" />
<model name="subcategory" />
</global-bucket>
</data-rules>Models can have conditions to only group a subset of their objects:
<global-bucket>
<model name="category" condition="archived != true" />
</global-bucket>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.
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:
via="self"
The user object is the bucket root.
via="self[role == 'admin']"
The user object is the bucket root. The bucket only applies to users that have a role of admin.
via="self/region"
The region is the bucket root. Each user can have zero or one region.
via="self/region/clients"
The client is the bucket root. There can be many bucket roots per user, depending on the number of clients.
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:
no via
The bucket applies to all users.
via="self"
Same as above.
via="self[role == 'admin']"
The bucket applies only to users that have a role of admin.
via="self/settings[role == 'admin']"
Same as above, but where the role field is stored on a separate settings object.
via="self/assignments[active == true]"
The bucket applies to users have one or more assignments that is marked as active.
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