]project-open[ : @This Wiki
Portrait

Welcome, Unregistered Visitor

 ·  ·  ·  Contact ·  Index · Login · Register

Contents

Remote Training
Support
SaaS Service

3 registered users
 in last 24 hours

OpenACS Group


image:group-user-relationships.gif
(An overview about the relationship between groups and user types)
­

Groups represent groups of people. Technically, group is a subtype of Party.

Users become a member of a group by creating a "membership" relationship, consisting of:

  • An entry in acs_rels, mapping the user to the group and
  • an entry in membership_rels (with the same rel_id as the acs_rels), defining the status of the membership (member_state in ('active', 'deleted', 'banned')).

This way of modeling users allows to dynamically extend users, groups and their relations. This is heavily used in ]po[ (for example there is an “employee_rel”). However, it adds a certain overhead (9 tables instead of 3).

Additional aspects of groups:

  • Groups may include sub-groups via the [composition relationship]. A member of the sub-group will automatically become a member of the super-group.
  • Groups or their sub-groups may include persons via the [membership relationship]. 
  • Relationships between Business Objects (i.e. [Project], Company) are modelled similar to groups via acs_rels, but are not part of the group system

 A trigger mechanism in OpenACS maintains a cache tables with group-membership information:

  • group_distinct_member_map(group_id, member_id) contains the most summarized view to memberships, containing only groups and members. This view represents the easiest way for a programmer to check for group membership.
  • group_approved_member_map(group_id, member_id,  rel_id,  container_id, rel_type) contains more detailed information about (approved!) relationships.
  • group_element_index(group_id, element_id, rel_id, container_id,  rel_type, ancestor_rel_type) contains a cached group-membership index maintained by a number of triggers dealing with changes to groups, inter-group relationships and memberships.

 

Predefined Groups

The default configuration of ]po[ contains a number of pre-defined groups. These group names are used in several [packages] and associated with hard-coded semantics. Also, the names of these groups are used to set permissions during the upgrade of ]po[, so please do not try to delete these groups or to change their names. Instead, you can use the localization system to "translate" the names.

  • The Public (group_id = -1, hard-coded ID and name):
    Represents any user in the system, even the users that have not yet been registered.

  • Registered Users group_id = -2, hard-coded ID and name):
    Represents users that have registered. Please note that users may self-register themselves, depending on your configuration.

  • P/O Admins (hard-coded name):
    Represents application administrators of ]project-open[. Please do not modify the name.

  • Customers (hard-coded name):
    Represents members of customer organizations (members of customer companies).

  • Employees (hard-coded name):
    Represents members of the organization running the ]po[ server.

  • Freelancers (hard-coded name:
    Represents members of provider organizations (members of provider companies).

  • Project Managers (hard-coded name):
    Represents users with the rights to manage (some) projects.

  • Senior Managers (hard-coded name):
    Represents users with basically all rights in the application, but which should not be exposed to the Admin functionality.

  • Accounting (hard-coded name):
    Represents member of the financial department, which usually can perform most of the operations in the system.

  • Sales (hard-coded name):
    Represents sales-reps. Members of the "Sales" profile usually can create new companies and users, but may have their access restricted to "their" customers.

  • HR Managers (hard-coded name):
    Represents members of the HR department. HR Managers usually have special rights to create new users of various types.

  • Freelance Managers (hard-coded name):
    Represents members of the provider/vendor/resource management department in charge of creating and maintaining information about providers.

  • Helpdesk (hard-coded name):
    Represents members of helpdesk operations. Helpdesk may have the right to modify a wide range of users in order to change passwords.

 

Please do not change the names of any of these groups. Doing so will cause upgrade errors in the future and may even render your system inaccessible (when modifying Employees of P/O Admins).

 



Please take a moment to complete this form to help us improve our service.

Note:
Please only provide feedback in regards to content this page shows. For support inquiries please refer either to the Community Support forum at Sourceforge or check out our 'Professional Support'

Did this page help you to achieve your goal?

 Yes  No  Don't know

Please provide us with comments to improve this page:

How useful is the information?

 1  2  3  4  5
Not
useful
      Extremely
useful
 
  

Explore

Installers
Demo Server
Modules & Functionality
Packages
Business Processes supported
FAQ's

Help

Getting started
User Manuals
Configuration Manuals
Community Support
Professional Support

News

News
Twitter
RSS Community / Sourceforge
Register for Newsletter

Get in touch

Contact
Register



Creative Commons License This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Generic License - Privacy Policy