Setting table and field permissions

Managing ABL Applications

ABL and R-code Deployment and Management : Maintaining Application Security : Database table- and field-level security : Setting table and field permissions

You can set table and field permissions by using the Change/Display Data Security utility in the Data Dictionary or the Edit Data Security menu option in the Data Administration tool. Note that once security administrators are designated, only they can access this utility. All other users are denied access by the tools with the message, "You must be a Security Administrator to execute this function." For information on designating security administrators, see Designating a security administrator.

To set table or field permissions:

1. Access the Data Administration tool if you are using a graphical interface or the Data Dictionary if you are using a character interface.

2. Choose Admin > Security > Edit Data Security.

If you are using a graphical interface, the Edit Data Security dialog box appears:

If you are using a character interface, OpenEdge alphabetically lists the tables defined for the working database. Choose the table for which you want to specify permissions. The Edit Data Security dialog box appears:

3. Choose the table or field for which you want to specify permissions.

If you are using a graphical interface, use the Permissions for Selected Table and Permissions for Selected Field radio buttons, then choose the table or field from the selection lists.

If you are using a character interface, use the options at the bottom of the dialog box to choose the table or field.

4. Specify the security permissions for the table or field. The following tabel lists the security permissions you can specify for a table or field.

Table 2. Table and field security permissions
Permission	Description
Can-Read	Specifies the users who have permission to read a table or field.
Can-Write¹	Specifies the users who can write to a table or field or update records.
Can-Create	Specifies the users who can create new records. The user with Can-Create privileges automatically has Can-Write privileges.
Can-Delete	Specifies the users who can delete records from a table.
Can-Dump	Specifies the users who can bypass dump trigger security by using DISABLE TRIGGER.
Can-Load	Specifies the users who can bypass load trigger security by using DISABLE TRIGGER.

¹ Setting this permission requires that the Can-Read permission also be set.

Security permissions consist of a list of one or more comma-separated user ID patterns.

The following table lists basic types of expressions you can use to define the permissions for a table or field. This table shows permissions using non-qualified user IDs, as you specify for a non-multi-tenant database.

Note: An empty permission string denies the table and field permissions to every user and is not recoverable.

Table 3. Basic expressions for table and field permissions
Expression	Meaning
[,]<blank>,...	The blank user ID has access.
*	All user IDs have access.
mark	The user ID "mark" has access.
!mark	The user ID "mark" does not have access. Note: The ! permission negation is useful only when the permission list ends with ",*"
,!mark,*	The blank user ID and the user ID "mark" do not have access.
mark*	All user IDs that begin with "mark" have access.
*jones	All user IDs that end with "jones" have access.
db*user	All user IDs that begin with "db" and end with "user" have access.

The following table shows permissions using fully qualified user IDs, as you specify for a multi-tenant database.

Table 4. Table and field permissions using fully qualified user IDs
This expression . . .	Permits access to tables and fields from . . .
	The blank user name in the blank domain
*	All user ID's
mark@acme.com	The "mark" user name in the "acme.com" domain
mark	The "mark" user name in the blank domain
mark*	All user names that begin with "mark" in the blank domain
*jones	All user names that end with "jones" in the blank domain
db*user	All user names that begin with "db" and end with "user" in the blank domain
@acme	The blank user name in the "acme" domain
*@acme	All user names in the "acme" domain
@	The blank user name in the blank domain
mark@*	The "mark" user name in any domain
@	Any user name in any domain
mark@acme.	Any user name that begins with "mark" in any domain that begins with "acme."
@.admins	Any user name in any domain that ends with ".admins"

For a more detailed description of the options available for specifying these permissions, see the sections on configuring and implementing authorization in OpenEdge Getting Started: Identity Management.

Any changes you make to the table permissions do not affect your current session or any other current sessions. This means that if other users are working while you change table permissions, they are not affected. To use the new permissions, you must exit and restart the OpenEdge ABL session.

Note: Do not try to bypass the Data Dictionary or Data Administration tools to modify the permissions for the tables and fields in the database. You might lock yourself out of the database.

In this section:

Example of personnel security