General guidelines for writing rules

Default access principle

In the case of data sources, system codes (categories), programs, forms, and files users have no access until you explicitly grant access.

In the case of objects on a form or fields in a file, the access you grant to the form or the file is applied to the form objects and file fields. This means that you do not have to write additional rules that grant access to objects on a form or file fields.

In the case of elements, if a user has access to a form and the files it uses, access to the elements (such as through the Drill Around feature or a Select list) is assumed.

Containment principles for forms and form objects

In the case of forms, you must be sure to grant access to all of the securable objects that contain the form (data source, system code, and program) in order to write rules that apply to the form. For example, if you write a rule granting access to Employee (HR11.1) but do not write rules that grant access to the data source, the HR system code, and the HR11 program, users will have no access to data on Employee (HR11.1).

In the case of the objects on a form (fields, button, tabs, and so on), you must grant access to the form containing the objects. Whatever access you grant to the form applies to all of the form objects unless you write additional rules that apply to individual objects.

Containment principles for files and file fields

In the case of files, you must be sure to grant access to all of the securable objects that contain the file (data source and system code) in order to write rules that apply to the file.

In the case of the fields in a file, you must grant access to the file containing the fields. Whatever access you grant to the file applies to all of the fields in the file unless you write additional rules that apply to individual fields.

Each rule applies to one securable object

In general, each rule you create within a security class will be for a single securable object. However, if you need many securable objects to have the same rule logic applied to them, you can select the objects in the Object Selector and then write the rule. The Lawson Security Administrator will then create multiple rules, one for each object you selected.

The exception to this principle is that for forms and files, whatever access you grant to the form or the file also applies to the objects the form contains or the fields the file contains.

Rules for elements

If you have granted access to a form and the files it uses, you do not need to write rules that grant access to any elements related to the fields on the form or that might be referenced through the Drill Around feature or a Select list. In this case, access to the elements is assumed.

If you want to restrict access to an element, you can do so in several ways. First, within the context of a specific security class, you can select an element on the Element tab in the Object Selector, and write the rule controlling access. This will affect users to whom the security class applies when they attempt to access fields based on the element in a Drill Around or Select list.

Second, you can write rules for an element that apply to all security classes (unless overridden by a rule for that element within a security class). To do this, you choose Element from the Profile Management option set and then select the element you want to write the rule for.

Third, you can set up element groups (that is, sets of elements) and then write rules against those element groups. This enables you to control access to objects based on the values of multiple elements. Usually these elements will be key fields for a form or file. For example, if you have an element group consisting of company and process level, you can write a rule for a form that grants access to a range of company and process level values.

Use generic rules

Whenever possible, write your rules in as generic a fashion as possible. That is, try to avoid rules that refer to specific users, companies, vendors, accounts, or other values. This may be necessary sometimes, but your security setup will be much more complicated and harder to maintain if you create many rules that each apply to highly specific cases. Note that in some cases your rules can access information about the current user and the current form at runtime. Thus, instead of writing a rule that checks if the user is “John Smith” and the employee data on the form is also for “John Smith,” you can write that compares the employee number of the current user (based on the Employee field of the user's web user record) with the employee number on the form.

Restrict a security class to one task

Make sure that all of the rules for a given security class relate to the same task. Do not try to add numerous rules to a security class so that the security class covers several tasks. This makes re-use of the security less feasible. That is, you will not be able to assign it to multiple roles because all of the tasks covered by the security class will probably be appropriate for only one role. The other roles will require perhaps only a subset of the tasks covered by the security class.

Use the Drill Explorer and Expression Builder aids

To determine which files you need to grant access to so that users can use the Drill Around feature and Select lists on a form, use the Drill Explorer aid. You access the Drill Explorer in the Object Selector by right-clicking on any form field that has a drop-down list associated with it.

When writing conditional rules in the Expression Builder, take advantage of the object lists and Lawson-delivered functions.

Double-check your JavaScript syntax. The Expression Builder does limited syntax checking but some syntax errors could appear at runtime.

• Do not use tabs in the rules.

• Enclose literal values in single quotes.

• Use two equal signs (==) to denote equivalence.