AX2580

How role settings are applied to users

Axiom supports role-based security. Each user can be assigned to one or more roles, and that user inherits the security settings defined for those roles. This topic explains how role-level rights are inherited by individual users.

In general, role rights are additive. Users are granted the most permissive set of rights among their own personal security settings and any roles that they are assigned to. Roles are intended to grant permissions, not deny permissions.

Role inheritance works slightly differently for different areas of security, as detailed in the following sections. When configuring security settings for a user, be sure to review the Effective Permissions section that is available in most areas of the dialog. This section displays the user's effective permissions after taking into account all applicable factors, including role inheritance, subsystem restrictions, and administrator status.

NOTE: If subsystems are being used, then role inheritance works in the same way, but users' effective permissions are limited by the subsystem's maximum permissions. For more information, see Security subsystems.

Permissions

The Permissions tab of security defines access rights for specific Axiom features. By default, users inherit security permissions from any roles that they are assigned to. However, you can override role inheritance for a user on a per permission basis.

If a permission is set to inherited, then the user is granted the most permissive set of rights among any roles the user is assigned to. For example, imagine the following settings for the Browse Audit History permission:

User Inherited
Role1 Unchecked
Role2 Checked

If the user is assigned to both Role1 and Role2, then the user inherits the permission and can access the audit history for the system.

If instead you select to Override a permission for a user, then that permission is no longer inherited from roles. The user is granted or denied the permission based on whether the Permission box is checked for the user.

The following screenshot shows what the Permissions tab looks like in all possible states:

Example Permissions tab

In this screenshot, the example permissions are treated as follows:

  • Administer Announcements: Inherited from role. The Budget Process role grants this permission to the user, so the Permission check box shows as checked, and the role name is listed in the details to the right.

  • Administer Axiom Explorer: Inherited from role. None of the roles that the user belongs to currently grant this permission, so the Permissions check box shows as unchecked.

  • Administer Exports: The Override check box is checked, so the user does not inherit this permission from any roles. The Permission check box is not checked, so the user does not have this permission.

  • Administer File Groups: The Override check box is checked, so the user does not inherit this permission from any roles. The Permission check box is also checked, so the user has this permission.

Startup documents

The Startup tab of security specifies files to open when a user starts Axiom, such as the home page, task panes, and ribbon tabs. Users inherit startup files from roles in addition to their own individually assigned startup files.

Each user can have only one home page. If a user has an individually assigned home page, that file will be used and any role settings are ignored. Otherwise, the user will inherit the home page from a role. If no home page is assigned, the default home page is used.

For more information about startup file inheritance, see Assigning startup files (Startup tab), and review the section for the applicable type of startup file.

File groups

The File Groups tab of security defines access rights for plan files in file groups. For file groups, you can configure role inheritance to be handled in a variety of ways. You can specify that role settings are combined with user settings, or that role settings are inherited independently from user settings, or that role settings are ignored entirely and not inherited.

For more information and examples of how role file group permissions apply to users, see Understanding role inheritance options for file group permissions.

All other areas

For all other areas of Security, the user inherits the most permissive set of rights among their own personal security settings and any roles that they are assigned to. This applies to the Tables tab and the Files tab.

For example, imagine the following access level settings for a report folder:

User Read-Only
Role1 None
Role2 Read/Write

If the user is assigned to both Role1 and Role2, then the user has Read/Write access to that report folder, because that is the most permissive set of rights available to the user.

Each tab has an Effective Permissions section where you can view the rights that the user will be granted after taking into account role inheritance, administrator status, and folder inheritance (where applicable).

NOTES:  

  • For table access, if both the user and a role have filtered access, the filters are concatenated using OR. So if a user has a table filter of DEPT.Region='North' and a role the user is assigned to has a table filter of DEPT.Region='South', then that user's full filter is:

    DEPT.Region='North' OR DEPT.Region='South'

    That user has access to data for either the North or South regions.

  • For table access, you can choose to ignore role inheritance. If this option is enabled for a user, then any applicable role access settings for the table are not inherited (including the Full Access setting) and the only filter applied is the user's filter.