The "Define Permissions" View
Permissions are used to represent abstract operations or types of usage. A permission may correspond to many low-level object operations. Permissions provide a way to control access to operations without having to list each operation explicitly.
When creating products or ZClasses?, we use high-level objects, like DTML Methods to define operations. These high-level objects have thier own permissions, which define represent abstract operations on the low-level operations of these high-level objects.
When defining permissions for our products and ZClasses?, we need to define what low-level operations these new permissions correspond to. We could enumerate the low-level operations of the high-level objects used to implement the operations of our products or ZClasses?, but this would be:
- Error prone, and
- likely to break as the interfaces of the high-level objects evolve.
What we do instead is to treat the permissions of the high-level objects used to implement a product or ZClass?' operations as the low-level operations that the product or ZClass? operation's abstract.
This is done via the "Define Permissions" view. The "Define Permissions" view is used to define how the operations of this object (or objects that acquire permission settings from this object) correspond to the operations defined by your product or ZClass?.
The view has a table with two columns. The "Permission" column lists the permissions for an object. The second column specifies the permissions that should have this permission in this product or ZClass?. For ZClass? methods, only permissions that are defined for the ZClass? are permitted.
In general, any permissions that include operations that change (mutate) an object should be disabled. Otherwise, a method could be modified when used on an instance, such as a ZClass? instance.