AX1060

Security considerations for on-demand file groups

The following additional security considerations apply when using on-demand file groups.

Ability to create new plan files

For on-demand file groups, a user's ability to create new plan files depends on the Create New Records security permission. This permission is located on the File Group sub-tab of the File Groups tab in security, and is only available for on-demand file groups. However, in most cases you do not need to configure this permission in security, because it is already granted via the Everyone role.

By default, when you create a new on-demand file group, the Create New Records permission is enabled on the Everyone role for that file group. Effectively, this means that if a user is otherwise granted access to plan files in that file group (on the Plan Files sub-tab), then that user will be able to create new plan files as well. The Everyone role is used because typically if a user has access to the on-demand file group, then you also want the user to be able to create new plan files in the file group. However, if instead you want some users to be able to create new plan files and other users to only access existing files, then you can remove the permission from the Everyone role and instead assign it to individual users and roles as appropriate.

NOTE: The terminology of the permission refers to creating new records instead of creating new plan files in order to capture the unique "on-demand" process of creating a new record and a new plan file in the same action. By contrast, the Create Plan Files permission refers to the ability to create plan files for existing records using the Create Plan Files utility. The Create Plan Files permission is not necessary to allow end users to create new records and plan files for on-demand file groups.

Keep in mind that once a user creates a new plan file, in most cases you also want the user to be able to save it. One way to accomplish this is to grant the user the appropriate level of plan file access directly (Read/Write and Allow Save Data). Alternatively, if you are using a plan file process (or the legacy workflow feature), then you can set the user's access at No Access or Read-Only and allow the process to "elevate" the user's access as appropriate to the plan file (assuming that Interacts with Process Management is also enabled for the plan file permission set). In order for this to work, the first step of the process must be configured so that the assigned owner is the process initiator / plan file creator.

NOTE: If you want a user to be able to create a new on-demand plan file by cloning another plan file, then that user must have at least Read-Only access to the plan files in Security. Users with No Access plus Interacts with Process Management can create new plan files, but cannot clone existing plan files.

Using a plan file filter

When configuring a user's plan file permissions to an on-demand file group, you can opt to give the user access to all plan files in the file group, or define a filter. If you want to use a filter, then special considerations apply.

When defining a security filter for an on-demand file group, keep in mind that the column used to define the filter must be populated at the point when the new record is created in the plan code table. Otherwise, the user will not be able to create any plan files because their security filter will be applied at the point of creation, and at the point of creation the column will be blank. If Axiom Software detects that the user's security filter will not allow access to the new plan file, then the plan file creation is stopped (and the new record is not created in the table). For more information on this issue and how to collect starting values for the plan code table, see Collecting values for the plan code table when creating an on-demand plan file.

This limitation means that your security requirements may impact how you decide to configure the plan code table, and what approach you decide to adopt for end users to create new plan files. For example, imagine that your users use the Excel Client, and you want to set security filters based on department. You can create a column named Dept in the plan code table, and configure that column to lookup to Dept.Dept. Since the default behavior in the Excel Client is to automatically prompt users to define values for validated columns, then you know this column will be populated when the new record is created. So you can define security filters such as:

However, now imagine that you want to base the security filter on a column named Owner, which is not a validated column. Now the default method of plan file creation will not work, because it will not populate the Owner column. In this case, you must instead use an Axiom form to collect the starting values for the plan code table. You might set up the form with a GetUserInfo function that returns the current user name, and then configure the Add Plan File command to pass that value to the Owner column. Now, you can have a security filter such as PlanID.Owner='jdoe', because the Owner column will now be populated when the record is created.

If your system design is such that you cannot populate a particular column when the record is created, and you must use that column to define security filters, then you can work around this by adding the "null" case to the filter. For example, instead of using PlanID.Owner='jdoe' as the filter, you would use PlanID.Owner IN ('Jdoe','') (where the empty single quotation marks indicate null or blank). This tells Axiom Software that the user can access any plan file that has either "jdoe" or a blank value in the Owner column.