A standard user in Ansys Dynamic Reporting can be assigned to a particular group, or more than one group.

A group can also contain multiple users. (A many-to-many relationship between user and group)

A user may or may not belong to a group.

You must add users to the appropriate groups depending on their roles.

In order to make use of ACLs, a user must belong to at least one group.

The ADR server includes a default nexus group with a default nexus user. This user is a superuser (admin).

A superuser or admin is a user who has uncontrolled and unrestricted access to almost every operation and object in Ansys Dynamic Reporting, regardless of which group he/she belongs to. Objects available to a superuser are unfiltered.

Almost any operation that is requested by a superuser will not undergo any permission checks through ACLs. So, create superusers carefully.

Unlike users, a superuser only sometimes may need to belong to a group in order to make use of ACLs and categories, depending upon the operation.

Categories, in addition to being a way of grouping similar kinds of data objects, are also a way of defining access of a user-group over a set of objects.

The permissions of a user-group over an object category applies to all objects assigned that specific category. For example, if a user X belongs to group A and group A has change permissions on an item category C, then the user has change permissions (can edit all items) over all objects that are assigned the category C.

For backwards compatibility, all existing items (that have no categories assigned) from old databases will be visible to any user without restrictions. When filtering occurs, a user is shown all items they have permissions on and also all items that do not have any categories assigned (do not have any permissions assigned through the categories).

Access of user-groups over objects are controlled through several predefined permissions.

Even though users may not belong to a group at all, to make use of the ACL, a user must belong to at least one group. This is because users cannot have permissions of their own.

There are four basic permissions:

There is one super permission, own, which overrides all of the basic permissions.

A group can be assigned one or multiple permissions. Similarly, one permission can be assigned to one or multiple groups. (A many-to-many relationship between group and permissions)

If a user has change permissions, they are automatically assumed to have view permissions as well.

There are two types of permissions, per-category and global.

A per-category permission is permission of a group tied to one specific object category. For example: with an item-category, a permission assigned for a group G to a particular category A is specific to that category (and inherently, the items assigned that category) and is called a per-category permission.

An object-category can have multiple groups/users with multiple permissions assigned on itself. Example: item-category A can be owned by group A and group B, only viewed by group C, only changed by group D, only changed or deleted by group E, and so on. It is very flexible.

Global permissions exist on all objects of a class/type. These are the permissions available through the admin interface while creating/editing a group. This will override any per-category permissions. Example: If the Can delete item category global permission is assigned to a group G through the admin interface, group G (and in turn any user belonging to G) will have delete permissions over all item categories (and in turn all items assigned any category).

A global permission always takes priority over per-category permissions.

Even though the implementation exists, per-category add permissions do not make sense because there will not be any category to check the add permission on, unless you add it. Use global add permissions for these cases.

A user's group must be assigned the global Can add item and Can add item category permissions to create an item and an item-category respectively.

When you create a category, it is saved in the database along with the permissions and the user groups that were specified for the category.

A relation is created in the database between that category and the list of groups through the permissions that were specified, respectively.

The available category may then be assigned to any object: in our case, items.

Whenever you deal with a category, it must be owned by at least one of your groups in order for you to edit, delete or assign it to an object.

Once an object is assigned a category, the permissions specified for the groups initially, will apply to the object as well.

Any access to that object must go through a layer of permission checks which check if any of the user's groups have the required permissions on at least one of the categories assigned to that object. If not, access to that object will be denied. This check makes use of the relation that was stored in the database initially.

The list of objects that a user has permissions on is determined by the categories that the user has permissions on, through the various groups the user belongs to. For example, when querying for items to delete in Ansys Dynamic Reporting, only those items with categories on which the user's group(s) has delete permissions, are returned.

At any point, if a user is not authenticated/logged in, (is Anonymous), and whatever object they are trying to access has no owner-group assigned to any of its categories (the object has no owner), the anonymous user will be given access to it. Objects with categories that have owners need authentication and membership in the corresponding group that owns any of the categories.