Introduction
CATSWeb Functional Restrictions control the actions available to CATSWeb users for a particular form or data entity. Functional Restrictions for Issue, Action, Subtask and Subform forms may be configured to operate in either of the following modes:
- Allow then Deny - All users are allowed full access to the form unless a Functional Restriction is put in place that denies them some or all capabilities.
- Deny then Allow - No users are given any access to the form unless a Functional Restriction is put in place that allows them some or all capabilities.
|
Quick Tip - Terminology
|
|
If you prefer Deny then Allow mode, you can think of Functional Restrictions as being "Functional Permissions". For consistency, AssurX uses the term Functional Restriction throughout CATSWeb and its documentation, regardless of the mode in use.
|
Functional Restrictions are more flexible than Employee Permissions. Employee permissions apply to all forms in the system, while Functional Restrictions only apply to a single form or data entity. Multiple restrictions can be set based on Group, Department, Personality, or Employee Name. If the current user meets any of the Functional Restrictions defined, the functionality available to them is gated by the matching Functional Restrictions. Functional Restrictions for Issue, Action and Subtask forms may also be used to vary the access rights of particular users to particular records by using the Conditions setting.
General Settings
The restrictions available for a particular form or data entity type vary. The following Basic Functionality restrictions are almost always present, and are analogous to Field Access Restrictions:
- Add Restricted - New records cannot be added.
- Edit Restricted - Records cannot be edited.
- Delete Restricted - Records cannot be deleted.
- View Restricted - Records cannot be viewed.
- Drill Down Restricted - Drill down links associated with the record (form) are inactive.
A variety of Workflow, Child Record and Utility Functionality restrictions may be available depending on the type of form or data entity. Child Record restrictions pertain to things like Notes, File Attachments, Signatures, etc. when they are associated with this type of parent record. Workflow Restrictions pertain to the workflow operations that are relevant to the record, such as reassigning, unlocking, etc. Utility Functionality restrictions pertain to miscellaneous capabilities, such as viewing the record in Print View. The Managerial Restrictions button on the Manage page enables functional restrictions to be applied to managerial entities such as forms, employees, personalities, etc.
Applies and Conditions Settings
The Applies and Conditions settings are available for Issue, Action and Subtask functional restrictions. When Applies is set to Always, the Functional Restriction is always active for the form and the specified Group, Department, Personality or Employee. When Applies is set to When Conditions are Met, the Functional Restrictions are selectively applied to only some of the records using the form, based on the values in the record and the specified Conditions. This allows for true role-based security, as a user's rights can be determined by their identity and their relationship to the particular record.
Conditions are specified using SQL WHERE clause syntax, and are similar to Record Access Restrictions. Conditions use the actual table field names from the underlying Issue, Action or Subtask tables or views (including fields color-coded as Only in Filters/Queries in the Field Definition listing), and may use any such field, even if it is not visible in the form. Conditions may also use tokens such as "{My Name}" or "{Today}". Here are some examples:
| Condition |
Applies When... |
| UserAssigned = {My Name} |
The record is assigned to the current user. |
| UDUserCreated <> {My ID} |
The record was not created by the current user. |
| UDUserEdited={My ID} |
The record was last edited by the current user. |
| UserDueDate < '{Today}' |
The record is overdue. {Today} token must be in single quotes. |
| Department='QA' AND UDDateCreated > '04/15/2000' |
The record is from the QA department and was entered after midnight, April15th, 2000 |
| Text4={My Group} OR UserAssigned={My Name} |
The record was created in the current user's Group, or is assigned to them (this assumes that Group is being stored in the Text4 field). |
| (PartNumber <> 'A-123' OR PartNumber Is Null) |
The record does not contain part number A-123. Note that when a '<> ' is used with a field that may contain null (non-entered) values, it is necessary to include the 'Or {Field} Is Null' clause in the SQL. If this is not included, records containing null values in the field will also match the condition. |
| Integer3=2 |
If Integer3 has been designated as a Signature Request Field, the condition is met when signatures are completed. The possible values for a signature request field are:
- 0 - Signatures Not Requested
- 1 - Signatures Requested
- 2 - Signatures Completed
|
When specifying a Functional Restriction on Add, Applies should be set to Always and not When Conditions are Met. A record does not yet exist during the Add process, so CATSWeb has no means of evaluating Conditions. You may use Conditions with child record add restrictions (e.g., Add Notes, Add Links, etc.) since the parent record exists at the time of child record adds, and CATSWeb can successfully evaluate the conditions.
|
Quick Tip - Immediate Updates
|
|
Unlike Employee Permissions where changes may not take effect until the user's next login, changes to Functional Restrictions always take effect immediately. This makes it easy to experiment with their settings. Try the following:
- Open a second browser window and view the record or entity that you wish to restrict. If you don't know how to open a second browser window, refer to this Quick Tip regarding Interface Preferences.
- In the first browser window, set a Functional Restriction for yourself.
- Refresh the page in the second browser window and see the effect of your new restriction.
|
|
