Support for Unified Access Control
Access control should be as transparent as possible to the application -developer. Until the implementation of the general permissions system, every +developer. Until the implementation of the general permission system, every OpenACS application had to manage access control to its data separately. Later on, a notion of "scoping" was introduced into the core data model.
"Scope" is a term best explained by example. Consider some @@ -200,10 +200,10 @@ user. This provided a crude way to associate objects with particular scopes in the system, but it was awkward to use and limited in flexibility.
The OpenACS 4 Object Model provides a generalized notion of scope that allows developers to represent a hierarchy of object contexts. These -contexts are used as the basis for the permissions system. In general, if an +contexts are used as the basis for the permission system. In general, if an object has no explicit permissions attached to it, then it inherits permissions from its context.
The context data model also forms the basis of the subsites system, and is -a basic part of the permissions system, +a basic part of the permission system, described in separate documents.
The context data model should provide the following facilities:
50.10 Unique ID
Every context should have a unique ID in the system.
50.20 Tree Structure
The data model should support a tree structured organization of contexts. That is, contexts can be logically "contained" within other contexts (i.e. contexts have parents) and contexts can contain other contexts