History for DefiningPermissionsForZClassesAndProducts

??changed:
-
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:

  - Cumbersone,

  - 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.