Project/Open Core : Permissions
Project/Open Core

Permissions

Requirements

  1. Project/Open permission requirements include :
  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:

The permission primitives mean:

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