| ]project-open[ Core : Permissions
]project-open[ Core

# Permissions

### Requirements

1. ]project-open[ permission requirements include :
   - "User Profiles" which correspond to department membership in a company
   - "Project Roles" which correspond to the function of the user in a specific project and
   - "User Hierarchy" which corresponds to the reporting hierarchy in a company.
2. The complexity of evaluating and storing permission permissions needs to be considerably below O(n * m) with n=number of objects and m=number of users in order to be suitable for organizations with up to 100.000 users and up to 100.000.000 business objects to be managed. (I wouldn't be practical for example to apply the OpenACS permissions system directly to a filestorage with 10.000.000 files and 10.000 users, because its denormalization triggers would build an O(n * m) denormalized index).
3. The access permissions for business objects in ]project-open[ sometimes follow specific rules. For example users may administrate themselfes (Employee self service) no matter if they are "just" freelancers or employees.

### Design

The permissions API in ]project-open[ are implemented using a set of business object specific TCL procedures such as:

- im_project_permissions current_user_id project_id view read write admin
- im_user_permissions current_user_id user_id view read write admin
- ...

The permission primitives mean:

- View (read object name):
  The user may see the name of the business object. This is used for example in a project page where the user may see the name of the company, but not see company details.
- Read (read the object specific data fields):
  This does not mean that the user can see associated information, as in the project-company example above.
- Write (write/edit the object specific data fields)
- Admin (=view + read + write)

The API calls again are calling the underlying permission mechanisms as defined above and in the Permission Requirement Document.

##### User "Profiles"

User "profiles" correspond to department membership in the company and are valid globally throughout ]project-open[.

Profiles are implemented using a number of OACS privileges on the "Main Site" object, that are available to groups of users. These "im_profile" user groups are represented as a subtype of OACS "group" type with the idea to extend their characteristics in the future.

Name | Add companies | View companies | View companies all | View company contacts | View company details | Remove All
--- | --- | --- | --- | --- | --- | ---
Main Site Administrators |  |  |  |  |  |
Main Site Members |  |  |  |  |  |
Accounting |  |  |  |  |  |
Companies |  |  |  |  |  |
Employees |  |  |  |  |  |
Freelancers |  |  |  |  |  |
P/O Admins |  |  |  |  |  |
Project Managers |  |  |  |  |  |

##### Project "Roles"

Project "roles" correspond to the role a user takes in a specific project. For example, Joe Sixpack may be project manager of one project while he only takes an analysts role in another project. These project roles are designed to allow external users to participate in the planning and execution of project ("Extended Company Model").

Project roles are implemented using relationships between users and the "administration group" of a project.

We have prefered the the use of these "admin groups" as oposed to using the default OACS permission system because we have to aks frequently: "Which users are member of this project". This type of query is disencouraged in the OACS permission system.

Currently (February 2004) we only use the "membership_rel" relationship and the "admin_rel", but we are planning to introduce a large variety of business sector specific relations, including "analyst_rel", "developer_rel", "tester_rel" etc. for the IT sector and "translator_rel", "editor_rel", "proof_reader_rel" for translation agencies etc.

##### User Hierarchy

This hierarchy actually implements a kind of "subadministration" functionality which allows certain user "profiles" (for example project managers) to administrate other users (for example freelancers).

| Accounting | Companies | Employees | Freelancers | P/O Admins | Project Managers | Senior Managers
Accounting | v r w a | v r w a | v r w a | v r w a | v r w a | v r w a | v r w a
Companies | v r w a | v r w a | v r w a | v r w a | V R W A | v r w a | V R W A
Employees | v r w a | v r w a | v R w a | v r w a | V R W A | v R w a | V R W A
Freelancers | v r w a | v r w a | V R W A | v r w a | V R W A | V R W A | V R W A
P/O Admins | v r w a | v r w a | v r w a | v r w a | V R W A | v r w a | v r w a
Project Managers | v r w a | v r w a | v R w a | v r w a | V R W A | v R w a | V R W A
Senior Managers | v r w a | v r w a | v r w a | v r w a | V R W A | v r w a | v R w a