![]() |
]project-open[ Core : Permissions | |
|
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" 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" 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.
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 |