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.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.xml
<data-rules version="3">
<global-bucket>
<model name="category" />
<model name="subcategory" />
</global-bucket>
</data-rules>
data_rules.xml
<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.data_rules.xml
<global-bucket via="self[role == 'technician']" write="none">
<model name="part_type" />
</global-bucket>
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:data_rules.xml
<data-rules version="3">
<!-- 'via' specifies how we get from the user to the region -->
<bucket via="self/region">
<!-- The root itself (region in this case) is automatically included in the bucket -->
<!-- sync all clients in the region according to the has-many relationship -->
<has-many name="clients" />
</bucket>
</data-rules>
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:
schema.xml
<data-model>
<!-- only relevant fields are listed here -->
<model name="region">
<has-many model="user" name="users" />
<has-many model="client" name="clients" />
<!-- new relationship for contacts -->
<has-many model="contact" name="contacts" />
</model>
<model name="client">
<belongs-to model="region" />
<has-many model="contact" name="contacts" />
</model>
<model name="contact">
<belongs-to model="client" />
<!-- New explicit relationship between contact and region.
Make sure to update this whenever the client changes. -->
<belongs-to model="region" />
</model>
</data-model>
And the corresponding data rules:
data_rules.xml
<bucket via="self/region">
<has-many name="clients" />
<has-many name="contacts" />
</bucket>
Same as with global buckets, we can add conditions on the models:
data_rules.xml
<bucket via="self/region">
<has-many name="clients" />
<has-many name="contacts" condition="number != null"/>
</bucket>
We can also add conditions on the root object:
data_rules.xml
<bucket via="self/region[archived != true]">
<!-- ... -->
</bucket>
Or on the user:
data_rules.xml
<bucket via="self[role == 'manager']/region[archived != true]">
<!-- ... -->
</bucket>
Root objects can also be linked to the user via a
has-many relationship:data_rules.xml
<bucket via="self/jobs"> <!-- In this case each job is a bucket root -->
<has-many name="parts" />
<has-many name="costs" />
</bucket>
In 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:
Path | Description |
|---|---|
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:
Path | Description |
|---|---|
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 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:
==
!=
lt or <
lte or <=
gt or >
gte or >=
The following are valid values to compare against:
true, e.g. "archived == true"
false, e.g. "archived != false"
null, e.g. "region != null"
Numbers (including for single-choice-integer), e.g. "count lte 5"
Text (including for single-choice), e.g. "status != 'completed'"
Last modified 11mo ago