More About Access Deny
rules
|
|
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. GAJNJ
5/22/06B-19070
In Version 4, changes to an Access Deny rule
affected only those requestors who logged in after the change. Active
requestors were not affected.
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.