Road Rager AP Power User Security Rules: Examples

This section describes details about some of the rules that Road Rager created. These rules were selected to illustrate some points about Lawson Security. They are not a comprehensive list of all the rules that the security administrator created.

Unconditional access for action rule

For AP25.1, Road Rager wants clerks to be able to view any invoice in either Biloxi or Brownsville, but they cannot add or modify them. This section shows the rule that the security administrator wrote to achieve this. An unconditional access for action rule means that the user has unconditional access to the specific functions he or she is allowed to perform, in this case, Inquire, PageUp and PageDown, but not Add or Change.

It is typical, but not a requirement, that when a user is given view access to a form, they are also given the ability to Page Up (minus symbol) and Page Down (plus symbol). This ensures that the user can view all data that he or she is allowed to see, even when it takes more than one page (screenload) to display.

Note: For the sake of keeping the example simple, this rule does not consider whether programmatic security exists for this program. In a real-world example, you would always check to see if either type of programmatic security was in place and write rules accordingly.
Screen clip: Writing a simple "unconditional access for action" rule for AP25.1

Rule to link the PROCLEVEL element group to objects that are secured by Company and Process Level

Note: This section assumes you are familiar with the concept of element groups, in general, and the Lawson-delivered PROCLEVEL element group, in particular. If you are not, refer to the earlier section of this document where they are explained.

A security rule that makes use of Company and Process Level security needs to know what Company and Process Level means for the securable object the rule applies to. To provide this information, you create a rule that links the PROCLEVEL element group to the objects that you want to secure.

The screen clips that follow show the steps the security administrator performed to create the PROCLEVEL rule for the APClerkBiloxiClass security class.

Screen clip: Selecting the element group object from the Add New Rules screen Screen clip: PROCLEVEL element group rule being edited in Expression Builder Screen clip: Completed PROCLEVEL element group rule Illustration: Additional details about the PROCLEVEL rule

After the PROCLEVEL element group rule has been written, all other rules in a security class can make use of it. The next section describes how to write such a rule.

Note: Because the example in this section specifies the AP system code, the rule only applies to securable objects in the AP system code. It is possible to define PROCLEVEL in a more general way by, for example, adding more system codes to the definition. If more system codes were included in the definition, rules in the security class would apply to all included system codes.

You could also omit SYSTEMCODE from the definition which would result in all system codes being included in the definition. Rules in the class would ignore system code and would grant access to any objects that meet the other criteria that you have defined.

Rule to grant access to a form that is secured by Company and Process Level or another type of programmatic security

When a PROCLEVEL rule exists in a security class, other rules can be added to the class to make use of it.

For example, the Road Rager security administrator wants to write a rule to give AP clerks in Biloxi access to form AP20.1 but with the ability to access only to Biloxi data. The following things are true:

  • The PROCLEVEL rule in APClerkBiloxiClass specifies that Company and Process Level should be checked.

  • Company and Process Level security is in use in form AP20.1.

  • The administrator plans to add the AP20.1 rule to the APClerkBiloxiClass security class.

In this situation, the security administrator can add a simple rule granting all access to AP20.1 (which has Company and Process Level security) to the same class. The result is that Biloxi clerks will be able to access AP20.1 but only view Biloxi data.

Rule to apply element group security to a form that is not secured by Company and Process Level security

Company and Process Level-like security rules can be written even for securable objects that do not make use of either Company and Process Level security. To write them, you would define an element group or, if possible, make use of one of the Lawson-delivered element groups.

The example in this section shows how to write a rule for AP99.9, a fictitious AP form, that has Company and Process Level fields but does not have Company and Process Level processing. (This is obviously not a real-world example but it enables us to make a point while sticking with our example security class, APClerkBiloxiClass. More typically, you would define your own element group in this situation.)

The rule makes use of the global function isElementGroupAccessible that is delivered with Lawson Security. This function is especially intended to be used when writing rules for element groups that you create yourself. It can also be used with the delivered element groups, PROCLEVEL and HREMP. In this example, we are showing it used with PROCLEVEL.

The illustrations that follow provide some details about how to create this kind of rule.

Screen shot: isElementGroupAccessible function being edited in Expression Builder Illustration: Additional details about the isElementGroupAccessible rule for (fictitious) form AP99.9

The security administrator added this rule to the APClerkBiloxiClass security class. As a result of the rule Biloxi AP clerks can run form AP99.9 which does not have either Company and Process Level or 900 API security and they will still only be able to see Biloxi data.