AX2595

Defining maximum permissions for subsystems

When defining security settings for a subsystem, you are defining the maximum permission that any user who belongs to the subsystem can have. Users are not granted these permissions by the subsystem; they are restricted to having this level of permission or less. Generally this means that you must define the maximum desired settings on each tab of the dialog, or else no users in the subsystem can have access to the features controlled by that tab.

You can imagine the subsystem permissions as defining an outer boundary of user rights. Users that belong to the subsystem can be assigned to roles and can be granted individual permissions as normal. Any user permissions that fall within the subsystem boundary will be given to the user. Any user permissions that fall outside of the subsystem boundary will be ignored.

At minimum, you must define settings on the following tabs:

  • File Groups tab, to specify which file groups the subsystem can access and the maximum allowed access.
  • Tables tab, to specify which tables the subsystem can access and the maximum allowed access.

  • Files tab, to specify which folders and files the subsystem can access and the maximum allowed access. In most cases this will include defining access permissions to reports. Optionally, you can grant access to scheduler jobs, task panes, and imports.

If users in the subsystem will not need any special permissions, then you can ignore the Permissions tab. Otherwise, you must define the maximum allowed access on that tab.

NOTES:  

  • If a user belongs to more than one subsystem, then the allowed permissions in one subsystem may exceed the permissions allowed in another subsystem. In this case the permissions "boundary" is the combination of the subsystems, where the user is granted the more permissive boundary (not restricted to the less permissive boundary). In this circumstance, you may find it useful to use subsystem-specific roles to grant permissions to users instead of "global" roles.

  • If a system administrator is assigned to a subsystem, the administrator permission takes precedence over the subsystem limitation. Subsystem limitations do not apply to system administrators.

Permissions tab

Select the check boxes for the permissions that you want to be available to users in the subsystem.

For example, if you know that some users in the subsystem need to have access to Scheduler, then you must select the Scheduled Jobs User permission for the subsystem. The users' individual permissions and role inheritance will determine which users in the subsystem actually have the Scheduled Jobs User permission.

If no users in the subsystem need to have any of these permissions, then you can leave the entire tab unchecked.

NOTE: In most cases, you should not select the Administer Security permission for a subsystem. If a subsystem user is granted this permission, they will be able to manage all users and roles in the system, not just the subsystem users and roles. Subsystem administrators do not need to be granted this separate permission in order to manage the users in the subsystem.

File Groups tab

For subsystems, you can define a single permission set for each file group. This maximum permission set will be applied against all permission sets defined for the user and inherited from the user's roles. If no permission set is defined for a file group, then the subsystem does not allow access to that file group.

If you want the users in the subsystem to be able to access plan files in a particular file group, then you must create a permission set and configure it as follows:

  • Set the file access level to the highest level that you need to make available to users in the subsystem. Typically this means setting the access to at least Read-Only. You must also specify whether the subsystem has access to Allow Save Data, Allow Calc Method Insert, and Allow Calc Method Change. Remember that if you are using process management to manage access to plan files, then you do not need to select Allow Save Data because the plan file process will automatically elevate user permissions as necessary.

    NOTE: The setting Interacts with Process Management is not available to subsystem permissions. There is no way to disable process interaction at the subsystem level.

  • Apply the permission settings to the maximum group of plan files that you need to make available to users in the subsystem.

    You must either select All plan files or specify a plan file filter. For example, if you specify a filter such as DEPT.Facility=5, then users in this subsystem can only access plan files for facility 5. Any user or role permission that falls outside of that filter is ignored.

    If the subsystem has a plan file filter, and a user in the subsystem is assigned a plan file filter (either individually or via a role), then the subsystem filter and the user filter are concatenated using AND. This restricts the user to only accessing files that match both the user filter and the subsystem filter. For example, if the subsystem filter is DEPT.Facility=5 and the user filter is DEPT.VP='Jones', then the user can only access plan files that are assigned to VP Jones AND which belong to facility 5.

NOTE: The Create New Records maximum permission is enabled by default for on-demand file groups. This is set automatically on the subsystem whenever a new on-demand file group is created. Also, when you create a new subsystem, this permission is automatically set for any existing on-demand file groups. This behavior is to enable the default permissions for on-demand file groups, which are automatically set to allow creating new records via the Everyone role.

Tables tab

If you want the users in the subsystem to be able to access data in particular tables, then you must define access for the table (at either the table or table type level).

When granting access, you must define the maximum level of access needed for the subsystem. For example, if some users in the subsystem need full access to the GL table type, but other users need filtered access, then you must set the GL table type to full access. The users' individual rights and role inheritance will determine their actual level of rights within this boundary.

If a subsystem has a table filter, and a user in the subsystem is assigned a table filter (either individually or via a role), then the subsystem filter and the user filter are concatenated using AND. This restricts the user to only accessing data that matches both the user filter and the subsystem filter. For example, if the subsystem filter is DEPT.Facility=5 and the user filter is DEPT.VP='Jones', then the user can only access data for VP Jones within facility 5.

NOTE: The default maximum permission for document reference tables Database tables that are managed within an Axiom file. The table structure is created based on the document structure each time the data is saved. Primarily used for driver files in file groups. is full access. This is set automatically in the subsystem whenever a new document reference table is created. Also, when you create a new subsystem, the maximum permission is automatically set for any existing document reference tables. This behavior is to enable the default permissions for document reference tables, which are automatically set to full access via the Everyone role.

Files tab

If you want users in the subsystem to be able to access a particular folder or file, then you must define access to those folders / files.

NOTE: Remember that users do not need to be granted access to files that are configured as startup files. If the user or role is assigned a file to open on startup, that file will be opened as a startup file, regardless of whether the subsystem allows access to that file.

Remember that subfolders and files will inherit any permission set at a "parent" folder level (unless permission is explicitly set for the lower level). For this reason, the effective permissions section displays for the subsystem, so that you can select a folder or file and see any inherited permissions for that item.

Where applicable, you should attempt to specify permissions at a level that accommodates ongoing folder and file additions. For example, if each subsystem will have its own reports folder and that is the maximum access required, then you can define access for just that folder. If the subsystem needs access throughout the Reports Library, then you most likely want to define the maximum access at the Reports Library level (perhaps also explicitly blocking access to certain subfolders and files). The users' individual rights and role inheritance will determine their actual level of rights within this boundary.

Example

This example illustrates how subsystem maximum permissions limit users who are assigned to the subsystem.

The following screenshot shows file group maximum permissions for a subsystem named Facility 5. For file group Budget 2020, the subsystem is limited by the following filter: DEPT.Facility=5. Users who belong to this subsystem can only access plan files that are assigned to Facility 5.

Subsystem maximum permissions

Subsystem settings do not grant any permissions; they only define a maximum boundary of permissions. Therefore users assigned to the subsystem must also be assigned to roles or be granted their own individual security permissions. Imagine that some users belonging to the Facility 5 subsystem are also assigned to the Facility 5 Managers role. This role grants access to all plan files within file group Budget 2020.

Role permissions

Although the role grants access to all plan files, the subsystem is limited to DEPT.Facility=5. The users in the subsystem cannot have greater permission than what is allowed by the subsystem (assuming the users only belong to one subsystem). Therefore the effective permission for this user is DEPT.Facility=5.

User effective permissions once roles and subsystems are applied