An access control file is defined by using an access tag with optional tags between open { and closed } braces. Access control files are set at either the project or folder level. Right-click > Edit Access Control on the project or folder, and click the Scripts sub-tab to view the underlying code that the GUI creates. Examples in the following table apply to the project or folder where this access control file resides.
Available tags within the Access Control File
| Tag | Example | Notes |
|---|---|---|
| access | access { } |
Required top-level tag that sets the file type. Defaults to no access if there are no optional tags used. |
| inherit-from-parent-folder |
access { inherit-from-parent-folder } |
Second-level tag when no access has been defined. No other tags should be present. This is the same as a directory with no access file. This is the default access set for all folders in the project except the root folder of the project. NOTE: The inherit-from-parent-folder tag cannot be used at the project root level as there is no parent folder to inherit from. |
| file-access |
file-access { <third-level tags> } |
Second-level tag that can allow or restrict read/write access. |
| allow-read |
file-access { allow-read } |
Allows read access to project or folder. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. |
| allow-write |
file-access { allow-write } |
Allows write access to project or folder. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. |
|
if-group if-property if-user |
file-access { allow-write { if-group "Managers" } } |
Fourth-level tags used to allow or restrict read/write access by group, property, or user. One if statement per block is allowed, though you can have multiple blocks. |
| cbase-access |
cbase-access { <third-level tags> } |
Second-level tag used to allow or restrict access to cBase files. |
| allow-all-rows |
cbase-access { allow-all-rows } |
Allows access to all rows. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. |
| limit-rows-by-filter |
cbase-access { limit-rows-by-filter { <spectre expression> } } cbase-access { limit-rows-by-filter { filter `value("Username") = current_user() } } cbase-access { limit-rows-by-filter { filter ``` user_property_contains("A", value("Dimension A")) or user_property_contains("B", value("Dimension B")) ``` } } cbase-access { limit-rows-by-filter { filter `regexp(value("Sales Manager"), "^[12]0")` } } |
Limits access to rows by an expression. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. Use limit-rows-by-filter to effect the union of access control rules; any Spectre expression can be used for allowing or disallowing each row in the cBase. NOTE: When a custom filter expression includes the user-property_contains() function, and a user lacks any assignments for a particular user property (when assignments are made in an external file), the function returns false when finding an empty set. |
| limit-rows-by-property |
cbase-access { limit-rows-by-property { column "Sales Manager" property "high-clearance" } } |
Limits access to rows by property. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. The following deprecated tags are mapped to limit-rows-by-property: limit-rows-by-property-value, limit-rows-by-property-values, and limit-rows-by-value. |
| limit-rows-by-username-column |
cbase-access { limit-rows-by-username-column { column "Sales Manager" } } cbase-access { limit-rows-by-username-column { column "Primary Surgeon User ID" if-group "Surgery_Provider" } } |
Limits access to rows by username and column. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. |
| limit-rows-by-values |
cbase-access { limit-rows-by-values { column "Sales Manager" } } |
Limits access to rows by column and values. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. |
| column | column "X" | Provides the column name for the limit tag. |
| values | values "A" "B" "C" | Provides values for the column for the limit tag. |
|
if-group if-property if-user |
cbase-access { allow-columns "Profit" "Cost" { if-property "high-clearance" "yes" } } |
Fourth-level tags used to allow or limit access to columns by group, property, or user. One if statement per block is allowed, though you can have multiple blocks. |
| restrict-columns |
cbase-access { restrict-columns "Profit" "Expenses" } |
Restricts access to named columns. Only one tag allowed per cbase-access tag, though you can list multiple columns. |
| allow-columns |
cbase-access { allow-columns "Supplier" "Customer" "Price" } cbase-access { restrict-columns "revenue" allow-columns "revenue" { if property "can-see-revenue" "yes" "executive" } } |
Allows access to named columns. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. Multiple allow-columns tags are allowed so you can allow access to restricted columns for specific users, groups, or those with a certain property applied. |
| divetab-access |
divetab-access { <third-level tags> } |
Second-level tag that can restrict or allow access to areas and IDs within a DiveTab project. |
| restrict-areas |
divetab-access { restrict-areas "Presentations" "Export" } |
Restricts access to the listed areas. |
| allow-area |
divetab-access { allow-area "Supplier Overview" } |
Allows access to the listed area ID. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. |
|
if-group if-property if-user |
divetab-access { allow-area "Presentations" { if-property "Sales Force" "yes" } } |
Fourth-level tags used to allow access to areas by group, property, or user. One if statement per block is allowed, though you can have multiple blocks. |
| model-access |
model-access { <third-level-tags> } |
Second-level tag used to allow or restrict access to classic Model files. |
| limit-dimension |
model-access { limit-dimension { dimension "X" values "A" "B" "C" } } |
Limits access to the listed dimension values. Accepts one if condition tag. If no condition tag, this tag applies to all users. Conditions are applied first. |
| dimension | dimension "X" | Provides the dimension name for the limit tag. |
| values | values "A" "B" "C" | Provides values for the dimension for the limit tag. |
| limit-dimension-by-property |
model-access { limit-dimension-by-property { dimension "Y" property "Allowed Y Values" } } |
Limits access to dimension and values by property. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. |
| limit-dimension-by-username |
model-access { limit-dimension-by-username { dimension "Username" } } |
Limits access to dimension and values by user. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. |
| limit-dimension-by-groups |
model-access { limit-dimension-by-groups { dimension "Group" } } |
Limits access to dimension and values by groups. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. |
| restrict-columns |
model-access { restrict-columns "Profit" "Expenses" } |
Restricts access to named columns. Only one tag allowed per model-access tag, though you can list multiple columns. |
| allow-columns |
cbase-access { allow-columns "Supplier" "Customer" "Price" } model-access { restrict-columns "revenue" allow-columns "revenue" { if property "can-see-revenue" "yes" "executive" } } |
Allows access to named columns. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. Multiple allow-columns tags are allowed so you can allow access to restricted columns for specific users, groups, or those with a certain property applied. Column names can include wildcards (* or ?). |
|
if-group if-property if-user |
model-access { limit-dimension { dimension "X" values "A" "B" "C" if-user "jdoe" } } |
Fourth-level tags used to limit access by user, group, or property. One if statement per block is allowed, though you can have multiple blocks. |
|
delete-columns (Deprecated, use the restrict-columns and allow-columns tags instead.) |
model-access { delete-columns "R" "S" "T" } |
Deletes the named columns from view. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. |
| audit-rules |
audit-rules { <audit blocks> } |
Second-level tag to define auditing rules. |
| audit |
audit-rules { audit { trigger "profit" } audit { trigger "bonuses" } } |
Specifies any number of audit triggers and additional columns to be captured. Multiple audit blocks are allowed. Accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. |
| trigger |
audit-rules { audit { trigger "MRN" trigger "diagnosis" column "employee number" } } |
Defines the dimensions to trigger an audit action. Multiple triggers can be listed in each audit block. Each block accepts one if condition tag. If there is no condition tag, this tag applies to all users. Conditions are applied first. |
| column |
audit-rules { audit { trigger "Patient Account Number" trigger "Patient Name" trigger "Encounter ID" column "Column Name" column "Value" column "Username" column "Access Date Time" column "Application" } } |
Specifies the columns to be captured in the audit column log files. Multiple columns can be listed in each audit block. |
|
if-group if-property if-user |
audit-rules { audit { trigger "Bonuses" column "Employee Name" if-property "Manager" "no" } } |
Fourth-level tags used to qualify audits by group, property, or user. One if statement per block is allowed, though you can have multiple blocks. |
| project-access |
project-access { allow-all-users } |
Top-level tag created anytime a non-administrative user or group has been granted access to a project. NOTE: This configuration is maintained in the GUI at Server Settings > Projects. |
|
allow-user allow-group allow-all-users |
project-access { allow-group "managers" } |
Tags to qualify project access by user or group. |
NOTE:
- Rules that include a conditional tag (if-group, if-property, if-user) are conditional rules. If no condition is set, the rule applies to all users.
- When looking at the access file, before granting or denying access, the DiveLine server scans all the conditional rules and tests each to see if it applies to the current user who is attempting to access data. If the rule does not pass the condition, the rule is removed from consideration—it would be as if the rule were not present at all.
- Only the rules with satisfied conditions, or no conditions at all, are processed to determine effective access.
See also: