This page provides an overview of Data Compression.
If you need to manage space within your database, you can set a data compression policy. Currently we allow you to permanently delete versions in the collaboration log. Be aware that the current version of compression is a LOSSY process (data will be permanently deleted). Take that into consideration when configuring a policy.
We recommend you keep more versions rather than less versions. You can think of the above as keep any versions newer than 180 days and keeping the most recent 50 versions. So as long as a version satisfies one of the two keep conditions, we keep it. Using the example above:
A version that’s from 205 days ago but is amongst the most recent 50 versions (e.g. version 22 of 60) will be kept, because it satisfies at least one condition of being in the most recent 50 versions.
A version that’s from 163 days ago but is version 65 of 80 will be kept, because it satisfies at least one condition of being less than 180 days old.
A version that’s from 185 days ago and is version 65 of 80 will be deleted because, it doesn’t satisfy either of the conditions.
The actual compression of data happens during the maintenance window. Please check with your system administrators to confirm when maintenance is scheduled.
The number of versions is based on the major version and not the minor version. This means for a record on version 35.63 with a keep most recent 10 versions, it will keep all versions 26.0 +, rather than all versions 35.44+.
You can find the Data Controls menu on the left-hand navigation bar of a table.
From here you may select to:
Change your Data Entitlements
Data Control Entitlements allow you to set up permissions for who can view, edit, or approve data within a table. Note that this was formerly called "Design Controls"
Table of Contents |
---|
When viewing a table, click on Data Controls > Entitlements from the left navigation menu (Image 1).
2. Currently both the table creator and anyone in the Cinchy Administrators
group has access to perform any action on any objects. You can give granular entitlements at a Group or a User level, for both viewing and editing access (Image 2).
3. In the above scenario, John Smith is part of the Developers group. He is able to view all columns via the entitlement to the Developers group, and he is able to edit both the First Name and Last Name column through different entitlements.
There are certain entitlements in the Data Controls menu that apply to the entire table.
Approving this entitlement enables users to see and serarch for the table in the Marketplace/Homepage.
Approving this entitlement enables users to export data from the table via the Manage Data screen (Image 3).
Approving this entitlement enables users to query the data from the table directly in the Query Builder (Image 4).
Approving this entitlement enables users to alter the structure of the table.
This is a builder/administrative function and should not generally be granted to end users.
Approving this entitlement enables users to change the permissions on a table.
This is a builder/administrative function and should not generally be granted to end users.
There are certain entitlements in the Data Controls menu that apply only to columns.
Approving this entitlement enables users to view all columns within the table.
Note that this applies to any new columns that are added to the table after providing this permission as well.
This is a drop down where you can select the specific columns you want to grant view access to for users.
Approving this entitlement enables users to edit all columns within the table.
Note that this applies to any new columns that are added to the table after providing this permission as well.
Giving a user edit permission will also give them view permission.
This is a drop down where you can select the specific columns you want to grant edit access to for users.
Giving a user edit permission will also give them view permission.
Approving this entitlement enables users to approve all columns within the table. This also allows users to approve Create and Delete requests.
Note that this applies to any new columns that are added to the table after providing this permission as well.
Approve permissions only apply when Change Approvals are enabled.
Giving a user approve permission will also give them view permission.
This is a drop down where you can select the specific columns you want to grant approve access to for users.
Approve permissions only apply when Change Approvals are enabled.
Giving a user approve permission will also give them view permission.
Link columns require both permission to the column within this table, as well as the column in the link column itself.
These are entitlements that apply to specific rows. Used in conjunction with Column Level entitlements this allows for granular cell level entitlements.
Approving this entitlement enables users to create new rows in the table.
Approving this entitlement enables users to delete rows in the table.
This is a CQL fragment that applies a filter to which rows will be viewable or editable. Think of the column entitlements and the fragment as a SQL statement applied to the table.SELECT {Edit Selected Columns} WHERE {Editable Row Filter}
Most of these examples will be with the editable row filter so it is easy to see the underlying data for comparison. However this can be done for viewable row data as well.
(Image 5)
With the following entitlements (Image 6):
Edit Specific Columns: Age
Editable Row Filter: [Age] > 30
(Image 7)
View Specific Columns: First Name, Last Name
Viewable Row Filter: [End Date] IS NULL OR [End Date] > GetDate()
(Image 8)
View Specific Columns: All
Edit Specific Columns: First Name, Last Name, Age
Viewable Row Filter: [First Name] = 'John'
Editable Row Filter: [First Name] = 'John'
(Image 9)
For the All Users group:
(Image 10)
View All Columns: Check
Edit Selected Columns: First Name, Last Name
Editable Row Filter: [User Account].[Cinchy Id] = CurrentUserId()
To allow a user to edit certain fields of their own data, you will need an association from a user to the [Cinchy].[Users]
table. You can then use the following function to allow edit for that user, where [...]
is the chain of link columns to get to the Users table.
[...].[Cinchy Id] = CurrentUserId()
This page provides an overview on data erasure.
Data erasure allows you to permanently delete data in Cinchy. As the data owner, you can set an erasure policy on your table if you need to delete data for compliance reasons (Image 1).
The actual erasing of data happens during the maintenance window. Please check with your system administrators to confirm when maintenance is scheduled.
Once data is erased, any links pointing to erased data will look like this (Image 2):
The time is counted based on the record's modified time stamp, not the deleted time stamp. This means for change approval records it is the time when the pending delete request was approved and moved to the Recycle Bin, not when the delete request was made.