Creating a security model

As a schema developer, you can design a security model that limits the type of records that users can view or modify. For each record type, you can also restrict the actions a user can select, the field values a user can modify, and the fields or pages of a form a user can view, based on the user privilege setting.

A security model is particularly valuable when more than one user group has access to the same database. For example, you can allow more than one group to submit defects to the same database or allow multiple projects share a database. You can permit your customers to submit defects and enhancement requests to your production database and prevent customers of different companies from seeing the records submitted by customers of the other companies or by your internal users.

You can use access control hooks and security contexts for Rational® ClearQuest® records when designing user access to data. An access control hook can prevent users from creating records of a specific record type. A security context can hide records from users by group. Hiding records can prevent users from seeing all records retrieved by a query in the result set, in a reference list, or from the Find Record utility. By restricting the record types that users with specific privileges can view, you can restrict the types of records that these users can create. You can also restrict the list of record types that users can create based on user privileges.

When users can view a record, you might want to control the information that users see and the actions that they can perform. You can use these mechanisms:
To implement these security features, you must know how to perform these tasks:
Note: You can also use workspace security that is not part of a schema but is set for each user database by an Administrator. For more information, see Workspace folder permissions .

Feedback