After you save an Access Deny form, active requestor sessions on the current node that are associated with that rule are immediately updated. Requestors at other nodes in a cluster are updated when the next system pulse occurs on their node.
Assume an application includes classes named Data-Refund-Basic, Data-Refund-Silver, and Data-Refund-Gold, all derived from the Data-Refund- abstract class, and two access roles named Refund:Worker and Refund:Super.
You want both types of users to be able to work on all three classes, except that users with the Refund:Worker role may not delete Data-Refund-Gold data instances.
You can accomplish this with three rules:
Rule type |
Key |
Description |
|
Class |
Access Role |
||
| Access of Role to Object | Data-Refund- | Refund:Worker |
Grant full access to all three classes. |
| Access of Role to Object | Data-Refund- | Refund:Super |
Grant full access to all three classes. |
| Access Deny | Data-Refund-Gold | Refund:Worker |
Deny Delete access to this class for workers; no change for others. |
You can achieve the same results without any Access Deny rules, by granting needed Data-Refund-Gold access capabilities one-by-one. However, using one Access Deny rule in this situation is simpler and easier to understand and maintain.