Real-world example for Data Rules

Let’s looks at a real-world scenario as a use case for data rules in your app.

As a reminder, data rules let you define (1) which data is synced to users’ devices, and (2) what read and write access users have to data (via DB and OnlineDB).

The scenario: You want sensitive app settings such as pricing data to be readable and writable by global admins, read-only by regional admins and not at all accessible (no read or write access) by normal users. A constraint is that the volume of this pricing data is too large for offline access for global admins, so they will only be able to access this data while online.

Data model and data rules file

We’ll define the following data model:

schema.xml

<?xml version="1.0" encoding="UTF-8"?>
<data-model>
    <model name="user" label="User">
        <field name="name" label="Name" type="text:name"/>
        <field name="role" label="Role" type="single-choice">
            <option key="normal">Normal User</option>
            <option key="regional_admin">Regional Admin</option>
            <option key="global_admin">Global Admin</option>
        </field>

        <!-- Normal users and regional admins belong to a region -->
        <belongs-to model="region" /> 

        <display>{name}</display>
    </model>

    <model name="region" label="Region">
        <field name="name" label="Name" type="text:name"/>
        
        <!-- Explicit relationships which we'll need to define our data buckets -->
        <has-many model="user" name="users" />
        <has-many model="client" name="clients" />
        <has-many model="pricing_template" name="pricing_templates" />
        <has-many model="pricing_item" name="pricing_items" />

        <display>{name}</display>
    </model>

    <model name="client" label="Client">
        <field name="name" label="Name" type="text:name"/>
        
        <belongs-to model="region" />

        <display>{name}</display>
    </model>

    <model name="pricing_template" label="Setting: Pricing Template">
        <field name="version" label="Version" type="text" />

        <belongs-to model="region" />
        <has-many model="pricing_item" name="pricing_items" />
        
        <display>{version}</display>
    </model>

    <model name="pricing_item" label="Setting: Pricing Item">
        <field name="key" label="Key" type="text" />
        <field name="value" label="Value" type="number" />

        <belongs-to model="pricing_template" />

        <!-- Explicit relationship added between pricing_item and region which we'll need to define our data buckets -->
        <belongs-to model="region" />
        
        <display>{key} : {value}</display>
    </model>

    <!-- ... -->

</data-model>

Note the following about the data model:

1. Normal users, regional admins and global admins are distinguished by the role field on a user

2. Normal users and regional admins belong to a region. This relationship will form the root of their data buckets (we’ll talk about this more below).

3. We have several explicit has-many relationships in the region model. These are also necessary for defining the data buckets as we’ll show below.

4. We have a client model that belongs-to a region. Client data is not considered sensitive: normal users, and regional admins will have access to all clients in their region, and global admins will have access to all clients across all regions. We’ll show this in the data rules below.

5. The pricing models, i.e. pricing_template and pricing_item, contain sensitive data. This data will be readable and writable by global admins, read-only by regional admins (for their region) and not at all accessible (no read or write access) by regular users. Additionally, admins will only be able to access these models using OnlineDB, since it’s too much data to sync to their devices.

Given the above, the data rules for this app could be implemented as follows:

data_rules.xml

<?xml version="1.0" encoding="UTF-8"?>
<data-rules version="3">
    <bucket via="self[role == normal]/region">
        <!-- NORMAL USERS: -->
        <!-- The user's region (bucket root) and its clients are synced, and are readable and writable -->
        <has-many name="clients" />

        <!-- The user's region's pricing data is not synced, and is not readable nor writable -->
        <has-many name="pricing_templates" read="none" write="none" />
        <has-many name="pricing_items" read="none" write="none" />
    </bucket>

    <bucket via="self[role == regional_admin]/region">
        <!-- REGIONAL ADMINS: -->
        <!-- The user's region (bucket root) and its clients are synced, and are readable and writable -->
        <has-many name="clients" />

        <!-- The user's region's pricing data is synced, and is read-only -->
        <has-many name="pricing_templates" read="any" write="none" />
        <has-many name="pricing_items" read="any" write="none" />
    </bucket>

    <global-bucket via="self[role == global_admin]" >
        <!-- GLOBAL ADMINS: -->
        <!-- All clients and regions are synced, and readable and writable -->   
        <model name="client" read="any" write="any" />
        <model name="region" read="any" write="any"/>

        <!-- Pricing data is not synced, but is readable and writable via OnlineDB -->
        <model name="pricing_template" read="online" write="any" />
        <model name="pricing_item" read="online" write="any" />
    </global-bucket>
</data-rules>

Let’s dive into these data rules.

Define the data buckets

Note that we have defined two object-specific buckets and one global bucket.

The two object-specific data buckets are for normal users and regional admins respectively, since we need to group their data by the region these users belong to. This can be seen in the via attribute:

    <bucket via="self[role == normal]/region">
        ...
    </bucket>

    <bucket via="self[role == regional_admin]/region">
       ...
    </bucket>

Global admins have access to all data across all regions, so we can define a global bucket for these users:

    <global-bucket via="self[role == global_admin]" >
        ...
    </global-bucket>

Define what data is synced for each user role

For normal users and for regional admins the following data is synced: the region object that the user belongs to (as the bucket root), and all clients belonging to this region (per the <has-many name="clients" /> relationship). These object groups sync because of the implicit read="any" rule on both the bucket (which includes its root object) and the <has-many name="clients" /> relationship. read="any" is the default that is applied if no read attribute is specified.

For regional admins, the pricing data belonging to their region is also synced. This can be seen by the explicit read="any" attribute on these relationships:

        <has-many name="pricing_templates" read="any" write="none" />
        <has-many name="pricing_items" read="any" write="none" />

For global admins, all clients and regions are synced:

        <model name="client" read="any" write="any" />
        <model name="region" read="any" write="any"/>

For global admins, pricing data is not synced, but is accessible via OnlineDB. This is configured with the read="online" attribute on these models:

        <model name="pricing_template" read="online" write="any" />
        <model name="pricing_item" read="online" write="any" />

Define what read & write access each user role has

Normal users and regional admins can read and write to the region they belong to, as well as all clients belonging to that region. This is because of the implicit default rules on the bucket root (read="any" and write="update,delete") and the implicit read="any" and write="any" rules on the <has-many name="clients" /> relationship.

Normal users cannot read any pricing data - as shown by the read="none" attribute on these relationships:

        <has-many name="pricing_templates" read="none" write="none" />
        <has-many name="pricing_items" read="none" write="none" />

Regional admins can read the pricing data belonging to their region, but cannot write to it (write="none"):

        <has-many name="pricing_templates" read="any" write="none" />
        <has-many name="pricing_items" read="any" write="none" />

Global admins can read and write to all data: all regions, clients and pricing data. However, they can only query pricing data via OnlineDB, as is shown by the read="online" rule:

        <model name="pricing_template" read="online" write="any" />
        <model name="pricing_item" read="online" write="any" />

For more info on the read / write syntax, see the data ACL syntax reference here.