Offline queries using the now or today filter
In Konect when queries that use the now or today filter are taken offline they are modified to use the the current date and time instead of the dynamic now or today, this is to ensure data integrity is maintained while offline.
Queries in Konect
A query in Konect is generally an immutable subset of records that match the given filter. The only way records can move in and out of the query is by having field data change, this allows Konect to sync records accurately.
Queries that use the now or today filter are the exception to this rule, as the filter is an ever moving time window using the current moment in time. These queries are mutable subsets that records can move in and out of without needing to have field data changed. This makes syncing far more difficult and can produce unwanted side effects for data integrity.
Offline project data
When a project is taken offline in Konect it a snapshot of all the datasets and queries in the project from the cloud. Subsequent syncs will find any new/changed/deleted records since the last sync time and merge them into the offline database.
Queries that use the now or today filter are the exception, because this is a snapshot of the cloud database the query is modified to use the current date and time instead of the dynamic now or today. The decision to modify these queries while being used offline provides a simple fix to data integrity issues that can occur when maintaining the original query. There is an example below showing problems that can occur.
How to use queries that use the now or today filter while offline
If you must use queries that contain a now or today filter while offline, this can still be done by bringing all projects that contain the query back online before taking the projects offline again. This could be performed daily or weekly by field workers to ensure they have the latest cloud snapshot.
Please note: If all projects containing the query are not bought back online the query will not be updated to the latest date and time.
If your projects have layers that contain a large number of records that are taking too long to download regularly you may need to create a reference project that contains just these layers that is always kept offline. This will ensure these large datasets do not need to be entirely downloaded every time a project is taken offline.
Example of a data integrity issue
Here is a slightly contrive example showing how sensitive data could be exposed if we did not modify these queries while offline.
There is a road inspection dataset
That contains a read only form variant that provides a restricted view (hiding sensitive fields) that will be used for all records.
That contains an inspection form variant that allows a field worker to edit the record.
That contains a query for all inspections due in 1 week - (Due date < (today + 1 week))
Road inspection dataset
Field | Read only variant | Inspection variant |
|---|---|---|
Condition | Visible | Visible |
Due date | Hidden | Visible |
Sensitive field | Hidden | Visible |
There is a road inspection project that contains the 2 form variants the full dataset and the query.
Road inspection project
Layer | Dataset/query | Variant |
|---|---|---|
Road inspections due in 1 week | Road inspections due in 1 week query | Inspection variant |
Road inspections | Full Road inspection dataset | Read only variant |
Every week a process runs that updates the sensitive fields for the records that are due the following week, ensuring field workings see a sanitized version
Offline road inspections project
When this project is taken offline all records are downloaded due to the full dataset layer. The due in 1 week query data doesn’t need to be downloaded, but a query is created on the local dataset table.
If this query was created using the current date and time rather then dynamic now or today, we can guarantee the data in this query is the exact cloud snapshot.
If this query was created using a dynamic now or today a number of things will happen after 1 week if the project is not synced
All the records that were due in 1 week will not be in the query (which is probably fine).
Records in the full dataset may now be in this query if they had a due date in the following week. The sensitive data that is normally cleared by the weekly process is now exposed to the field worker.