Index: openacs-4/packages/acs-core-docs/www/permissions-design.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/permissions-design.html,v diff -u -r1.34.2.1 -r1.34.2.2 --- openacs-4/packages/acs-core-docs/www/permissions-design.html 9 Jun 2016 08:44:50 -0000 1.34.2.1 +++ openacs-4/packages/acs-core-docs/www/permissions-design.html 23 Jun 2016 08:32:45 -0000 1.34.2.2 @@ -12,10 +12,10 @@ bans a user from a sub-site is an operation a site administrator is able to assign to a particular user. Or perhaps an application developer might decide that viewing a certain set of pages within the application is an operation to -be individually granted or revoked from a user. It's expected that the +be individually granted or revoked from a user. It's expected that the Permissions system will be seeing a lot of use - almost every page will make at least one permissions API call, and some will make several.

For programmers, the Permissions API provides a means to work with access -control in a consistent manner. If a programmer's OpenACS package defines new +control in a consistent manner. If a programmer's OpenACS package defines new methods for itself, the Permissions API must provide simple calls to determine whether the current user is authorized to perform the given method. In addition, using the Permissions API, queries should easily select only @@ -92,12 +92,12 @@ a member of

  • privileges get associated with the methods of any other privileges they have taken methods from (at any level) (see acs_privilege_hierarchy)

  • objects get access control from direct grants, or inherit permissions -from their context (unless the "don't inherit" flag is +from their context (unless the "don't inherit" flag is set)

    • Legal Transactions

    There are three essential areas in which all transactions in the permissions system fall:

    "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 +system's standard privileges, or new privileges which the package has created. The association step might also happen later, if the site-wide administrator chooses to change permissions policy.

    These steps involve directly manipulating the acs_methods, acs_privileges, and acs_privilege_method_rules tables. A @@ -170,7 +170,7 @@ large sites, some future search mechanism will be necessary.) After choosing privileges to grant, the user is returned to the "edit privileges for 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 +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.

    Configuration/Parameters

    There are no configuration options for the permissions system.

    Future Improvements/Areas of Likely Change

    The most important future changes to the Permissions system are likely to be in the UI: