Access Control Process

Setting access control to ensure your files and data are secure has many parts. The rule settings in the access tab is one of the final steps. To understand prerequisite steps that you might need to prepare, review the Access Control Overview, which discusses the overall process.

Work flow for setting access control rules

At the project level, set file access to allow read and write (if applicable) permissions for non-administrative users.

This allows non-administrative users to see the project files. It allows them to see all of the project directories, so you will need to restrict these users from any directories that you do not want them to see.
Restrict non-administrative users from any directories that you do not want them to see.

This is achieved by clearing the Inherit from ancestor check mark on the Directory Overview tab of the access tab for each folder that you do not want these users to see.

Basically, you first grant full read and write permissions for file access to the entire project, then restrict access to any directories that you do not want the user to see.
Set the data-specific access rules to control what each user and group can see within the data set.

For data sets (cBases and models), you first restrict columns and then allow specific users or groups access, which is most often done through property/values assignments. You can also set limit rules for rows. For DiveTab access rules, you first restrict DiveTab areas (buttons) and then allow specific users or groups access to them. When DiveTab applications access cBases, the row and columns rules apply to the display of DiveTab data pages.
Set audit rules if required.

NOTE:

Rules which include a conditional tag (if-property, if-group, if-user) are considered conditional rules. See Access Control Conditions.
These conditional if tags are only visible as such in the script. In the interface, they are presented as a choice in the Condition column of the rules tables.

The All users choice sets that rule without a condition so that the rule applies to all users. This is the default setting that places no if statement for the rule in the underlying script. For more information, see Underlying Access Control Script.
When looking at the access file, before making access decisions, the DiveLine server scans all of the conditional rules and tests each to see if it applies to the current user attempting to access data. If the rule does not apply to the user, 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 without any condition at all are processed to determine effective access.

Inheritance

Each directory (folder) below the project level defaults to have the Inherit from ancestor check mark selected and does not display any of the category sub-tabs.
To make any changes to the access control rules for this directory, you must first clear the Inherit from ancestor check mark, which then displays all of the sub-tab categories.