2 registered users
in last 24 hours
(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.
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).