Problems resulting from this piecemeal approach to permissions and access control were many, the two major ones being inconsistency, and repeated/redundant code. Thus the drive in OpenACS 4 to provide a unified, -consistent permissions system that both programmers and administrators can +consistent permission system that both programmers and administrators can readily use.
The core of the permissions data model is quite simple. Unfortunately, the
hierarchical nature of default permissions entails quite a number of tree
queries which could slow the system down. Since every page will have at least
@@ -94,7 +94,7 @@
acs_privilege_hierarchy)
objects get access control from direct grants, or inherit permissions from their context (unless the "don't inherit" flag is set)
There are three essential areas in which all transactions in the -permissions system fall:
Modification of methods and privileges
Modification of permissions
Queries on permissions
"Modification of methods and privileges." This +permission system fall:
Modification of methods and privileges
Modification of permissions
Queries on permissions
"Modification of methods and privileges." This
refers to actions that happen mainly at package installation time - a package
will create a number of methods for its own use, then associate them with the
system's standard privileges, or new privileges which the package has
@@ -125,7 +125,7 @@
against acs_object_party_method_map, or by calling the Tcl functions
for appropriate methods.
Finally, when administering the permissions for an object, a web page
needs to know all permissions directly granted on that object. This is done
-by querying against acs_permissions.
The API to the permissions system consists of a few well-known tables,
+by querying against acs_permissions.
The API to the permission system consists of a few well-known tables, plus a pair of PL/SQL procedures and a pair of Tcl functions.
Tables
acs_methods, acs_privileges, and
acs_privilege_method_rules manage the set of permissions in the
system. At installation time, a package will add to these three tables to
@@ -159,7 +159,7 @@
permission::permission_p -object_id $object_id -party_id $user_id -privilege $method
If the user_id argument is left out, then the currently logged-in user is checked. To create an error page, Tcl code should call:
permission::require_permission -object_id $object_id -privilege $method -
These procedures are defined in acs-permissions-procs.tcl.
All users of the permissions system are the same at the user-interface +
These procedures are defined in acs-permissions-procs.tcl.
All users of the permission system are the same at the user-interface
level. If you have the administer_privileges method permission on an
object, then you may edit privileges for that object with the UI.
The UI currently provides a list of all granted permissions on the object. If the user wishes to revoke privileges, she may select a set of grants, @@ -171,7 +171,7 @@ one object" screen.
If it makes sense, the system will also display a checkbox which the user may select to toggle whether permissions are inherited from the object's context.
There are a number of potential future enhancements for the permissions -UI, outlined below.
The most important future changes to the Permissions system are likely to +UI, outlined below.
The most important future changes to the Permissions system are likely to be in the UI:
There should be a page displaying a list of all objects for which the current user is allowed to administer privileges.
Users should be able to view the permissions on any object, or perhaps on objects which they have the "read_permissions" method. This would