An aPriori group is a-named container of aPriori users (or sub-groups) who share the same access requirements.

Groups have permissions, which are discussed in the next section.

Groups can have sub-groups. You can re-use the same name for different groups; uniqueness is determined by the full path of each group. For example, "/USA/Devel" and "/EU/Devel" are both recognized as valid, unique groups. Every user (even administrators) belong to at least one group: the system-defined group "All Users". (Since slashes are used to specify group paths, you cannot create a group with a slash as parts of its name.) System Administrators can also assign users to additional groups as necessary to control the permissions they have. Note that groups are the primary mechanism for modeling your organization's access requirements.

There are four system-defined groups, including one sub-group. The names in parentheses show the internal aPriori name for the group, which you may encounter in different contexts:

These system-defined groups cannot be deleted, though the permissions associated with them can be edited. Note that all users (including members of the "System Admins" and "VPE Admins" groups) are members of the "All Users" group.

All other groups are defined by an administrator or other user who is granted group creation permission.

Groups have a default attribute ("name"), and a membership setting (None, Automated, or Manual), but can also have other custom attributes (not to be confused with User Defined Attributes).

If a user is a member of two groups, one of which allows access to a resource, and a second group that denies access to that same resource, that user will be denied access (although aPriori provides the ability to ignore or override "deny" permissions, which will be discussed later).

Groups can contain sub-groups, and sub-groups can also contain other sub-groups. Adding a user to a group automatically adds the user to any parent groups. Removing a user from a group automatically removes the user from all sub-groups. (Removed users are not removed from parent groups since they may belong to other sub-groups of a common parent.)

Sub-groups allow you to model access control situations where, for example, a given user is an administrative user for one project but just a "regular" user for a different project. In a case like this, the user could belong to the "Project A Admins" and "Project B Team Members" groups.

The System Admins group has a sub-group called "Super Users", which automatically gets created (but not populated) at installation time.

As you might expect, members of the Access Control Super-Users group have powerful permissions that are not granted to other users. Specifically, they have "strongGrant" permissions for groups and permissions (described later in this chapter). In other words, they have Access Control powers over Access Control features.

Only the following Super-User characteristics can be changed, and they must be changed by a Super User:

Note that you cannot remove the last member of the Super Users group. If you need to remove the last user, you must first add another Super User.