Permissions

A permission mask is assigned to all application directories, to all EntitySets and relationships, and to all fields in EntitySets and relationships. The permission mask indicates the type of access that particular user IDs are to have to the object.

The possible permissions for EntitySets and for relationships are READ, ADD, CHANGE, and DELETE. ADD, CHANGE, and DELETE automatically enable you to READ the data.

The possible permissions for directories and for fields are READ and UPDATE. UPDATE automatically enables you to READ the data.

Ownership

The creator of each directory, EntitySet, or relationship is the owner of that object and of the fields in it. The owner of the Object Dictionary EntitySets, created when the new application database is initialized, is any user whose UserID is 0.

Owners can set and change the permission mask for the objects they own. Individual permission masks can be set for

For example, the owner of an EntitySet can grant permission for all users in his or her group to ADD data to an EntitySet, but might restrict other users (not part of the group) to READ only. In addition, the owner can restrict access to certain fields in the EntitySet: for example, by assigning READ access for users in the group and no access for other users.

Permission Checking

Each time that a user tries to access the data in a directory, an entity set, a relationship, or a particular field, the permission mask that is in force for the object is checked against the system variables $ZUserID and $ZGroupID.

First $ZUserID is checked to see if the user is the owner of the object. If the user is the owner, the object’s owner permission mask is used to determine if the user can perform the requested operation. If the user is not the owner but is in the owner’s group, the object’s group permission mask is used to determine if the user can perform the requested operation. Otherwise, the object’s others permission mask is used to determine the user’s access.

Effects on Commands

The applicable permission mask has an effect on command execution. You must have READ or UPDATE permission to access an application directory. You must have UPDATE permission to CREATE, ERASE, or RENAME objects in an application directory.

For example, if you enter

access EmployData update
change NewEmps1 from Employees
add NewEmps2 from Employees
create index NewEmps2.FirstName

you must have at least READ permission in order to access the directory EmployData. To make changes to the definitions of the objects in that directory, you need UPDATE permission.

You must have READ permission for the two commands involving the Employees EntitySet. In addition, you must have CHANGE permission for NewEmps2 and ADD permission for NewEmps2. You must also have READ permission for any fields in Employees that you are using, and UPDATE permission for the fields in NewEmps1 and NewEmps2 whose values you are adding to or changing.

When you create an index for NewEmps2.FirstName, you must have UPDATE permission for the directory EmployData (assuming that NewEmps2 is defined in that directory).

If you enter

delete all Employees where LName = Smith

you must have DELETE permission for Employees.

If you lack a required permission at the directory, EntitySet, or relationship level, the command does not execute; an error message is issued. If, at the field level, you attempt to read data from a field for which you do not have READ permission, the result you obtain is $Null; if you attempt to assign a value to a field for which you do not have update permission, the assignment is not made. No error messages are issued.

Changing Default or Established Permissions

When an object (other than a directory) is created, it has all possible permission for the owner, READ permission for the owner’s group, and no permission for all others. By default, newly created directories give READ and UPDATE permission to all users.

To change the permission masks, the owner (or the super user) uses the PERMISSION command. The permissions mentioned in the PERMISSION command are always added to the existing permission mask for that object.

In the following example

permission Employees other read add
permission WorkOn group read add change delete
permission Projects other
permission LName group update
permission Salary group other
permission ENum owner read

Employees and Projects are EntitySets, WorkOn is a relationship, and LName, Salary, and ENum are fields. Note that you can leave permissions blank; the affected users cannot access the objects at all.

Object permissions

There are two types of permissions – object permissions (EntitySets, relationships, and directories) and field-level permissions. Field level permissions take precedence over object permissions. The permissions are set as follows:

The following chart summarizes the permissions needed in order to successfully execute a given form of data manipulation on an object where permissions are currently in place. Definitions are as follows:

• Owner refers to the user who created an object.
• Group refers to any user who shares a common group ID with the object’s owner.
• Other refers to any user who does not share a common group ID with the object’s owner.

Note: Any user with a GroupID equal to 0 is considered to be a superuser. Superusers are not governed by permissions currently in place on objects, fields, or both. Thus, an object is created by a person logged in as superuser, then permissions applied to the Group are ignored since every user in the creator’s group is a super user. It is not advisable to create objects while logged in as a superuser, in order to take full advantage of Zim’s security features. Different permissions can be assigned to objects, fields, or both for users inside the owner’s group (Group) and to users outside the objects’ owner group (Other).

where R = read, A = Add, C = Change, and D = Delete

(1) Null values for all fields with no update permission