Permissions are the key to aPriori access control. A permission is associated with a group, and consists of:

In short, a permission specifies whether a member of the group to which it belongs is granted or denied the ability to perform an action on the specified resource, based on the specified rule.

A permission can also include Grant/Deny behavior modifiers:

aPriori Access Control supports the following actions. Some are self-explanatory, but some require a little background.

Note that Create can be applied to all resources but cannot be combined with any other action.

The other actions may or may not be applicable to various resources but can be combined with other actions that have compatible requirements. For example, Update and Delete require that the Resource already exists, and can be combined in the same Permission. But Create requires that the target Resource does NOT already exist, and therefore cannot be combined with other actions which all require that the target Resource exists.

Similarly, you can create a Permission for Roll-ups that combines any combination of Read, Update, or Delete. But you cannot create a Roll-up permission with a Cost Using action, because Cost Using applies only to VPE resources.

In the case of overlay VPEs, the top-level VPE is the only one that requires Cost-Using access. The underlying ("antecedent") VPEs do not require any access.

A Resource is the target on which the Action operates. As mentioned above, Resources include:

 Component (part and assemblies)

 Rollup (Roll-ups, Dynamic Roll-ups, Cost Comparisons)

 VPE

 Group

 Permission

Rules can use the attributes of a target Resource to fine-tune their behavior (see below).

Note: Group and Permission are provided for "access control of access control", which is an advanced topic. (See Access Control of Access Control)

A Rule is an expression that determines a group member's access to a target Resource. For example:

If a rule evaluates to "true", then access is granted. If it evaluates to false, access is denied. However, there are grant and deny modifiers that determine how conflicting permissions are resolved.

The Grant and Deny permission modifiers give you the ability to fine-tune permissions by strengthening ("strong") access and denial results.

For example, permissions for Super Users who need exceptional access rights over access control feature will have the strong Grant modifier enabled. This means that Super Users are always granted access rights, even if another permission attempts to deny access.

Deny: Normal Deny is the default, Out-of-Box setting for "regular" user permissions and translates to "An action is blocked unless another permission explicitly allows it". In general, when you (an administrator) create a new permission, you should use Normal Deny unless a Strong Deny is required.

This is typically paired with a normal Grant setting (see below). A "normal Deny" is actually not a Deny at all–it is more of an "abstain" setting. This means that if a user is granted access by a permission, other permissions that return a normal Deny are ignored. Only a strong Deny permission will prohibit a user from an action form which they have been granted normal access. A normal Deny that abstains does not equate to granting access, it just means that the user will not be denied access if another permission grants it. This ensures that a user who belongs to multiple groups is not blocked from an action in one group because of a Deny in another group.

For example, assume that multiple groups are defined to correspond to projects. Each project has a Permission associated with it that has a component UPDATE action. The rule for each project might be something like:

Now consider a user who is a member of several of these groups.

Without the normal Deny ("abstain") modifier, this user would not be allowed to update ("save") any scenario, because strong Deny permissions associated with the other projects would prevent it.

By setting normal Deny rather than Strong Deny on these permissions, failure of the rule is treated as if the permission did not exist in the first place. This is not a security hole, since one needs to have at least one Permission that explicitly returns True (i.e., grants access).

Grant – Strong: This modifier can force access to be granted even if there are other permissions that strongly deny access. This is intended for the Super Users group whose members may also be in other groups that have more restrictive permissions. This modifier should be used carefully and sparingly outside of the Super Users group.

The following table explains how combinations of these modifiers affect access and deny permissions: