Normal user jobs security access needs

Every user who needs to perform even the most basic tasks related to running and managing jobs and reports must have access to at least one job queue, GEN tables that contain jobs and user-related information, and Lawson Environment utilities.

Typically, normal batch users need to perform the following tasks:

  • Define jobs

  • Submit own jobs

  • View and print own reports in Lawson Portal

  • Manage own jobs in Lawson Portal, including changing or deleting existing jobs and print files

To perform these tasks, users need access to the following things:

  • Any report parameter forms, for example, HR211, that the user needs to run.

    For parameter forms, users do not need to be specifically granted access to the tables that contain the underlying data. Access to the data is granted with the parameter form. (Drills that are executed from report parameter forms are treated like any other drill and do need to be granted access to the data, including Company and Process Level tables.)

  • The appropriate job queue.

    If you have not created your own job queues, then the user needs access to the default job queue (********). Typically, you will grant All Access to the queue for the user. You can also write conditional rules to further refine the access rights for normal jobs and reports users.

  • The following GEN tables that contain information about jobs:

    • JOB

    • JOBSTEP

    • QUEUEDJOBS: With restrictions so that normal batch job users cannot kill running jobs and perform other tasks that you might want only system administrators to do. A conditional rule is necessary to make the restrictions.

  • Access to the user's own RDID in the UserName element. This access is accomplished through a conditional rule that validates the current user.

  • Access to a printer.

  • Access to Lawson Portal.

    Typically, this is given through the Lawson-delivered role, PortalBookmarkRole.

  • If your system makes use of report distribution features, then the user must also be assigned to the appropriate distribution groups. This administration is done through the Lawson Environment Group utilities.

Example rules for normal batch job users

The following custom rules are examples of rules you might want to include in a security class for normal batch users and include in a role for normal batch users.

Example Rule 1: Assigning normal access to the QUEUEDJOBS table

The role called BatchRole that is delivered by Lawson provides more access to the QUEUEDJOBS table in the GEN product line than some customers might want. You can write a rule that provides access only to the specific functions that you want users to have. Following are the functions that are available for the QUEUEDJOBS table:

  • Remove a completed job: M

  • Kill a running or needs-recovery job: D

  • Submit a job: A

  • View queued jobs: I

If you want to remove the ability to perform any of the above functions for a normal user, write an Unconditional Access for Action rule that gives access only to the specific actions the user should have. Granting all access to the QUEUEDJOBS table gives access to all of these functions.

Note: "Action types," such as ALL_INQUIRES, ALL_ADDS, ALL_DELETES are available for selection. For a table, granting access to action types causes the same behavior as granting access to individual actions. For example, granting access to "ALL_INQUIRES" is the same as granting access to "I".

To write a rule on the QUEUEDJOBS table, access the GEN profile, in the UN system code, Securable Type = Files.

Example Rule 2: Assigning access to action groups (ALL_INQUIRES, ALL_ADDS, and so on) for the QUEUEDJOBS table

Some securable objects for which multiple actions are available, such as the QUEUEDJOBS table, can be secured through action groups. Action groups let you write a conditional rule for actions of a similar type. For example, when an object has

Example Rule 3: Restricting a batch job user to own records

The following conditional rule, written on the QUEUEDJOBS table (in the GEN profile), ensures that the current user can access only his or her own records. You could add this rule to a class and then assign it to a role that you create for normal batch jobs users.

Note: Following are how the rules look in the Expression Builder window after selections have been made.

For UNIX/IBM i, the conditional rule is as follows:

if(UserName==user.getHostServiceID())
   ALL_ACCESS;
else
	  NO_ACCESS;

For Windows, the conditional rule is as follows:

if(UserName==user.getUserName())
   ALL_ACCESS;
else
	  NO_ACCESS;

In the conditions mentioned, you are comparing the UserName field value to the value the function returns. Therefore, if there is a UserName match, the data will display; if there is no match, the data will not display.

Note: The rules mentioned will only limit the functions, such as inquiring on the User's Print Manager or Job Scheduler. To secure the select/drill options on the UserName field, you can write additional security rules on the tables in the GEN Profile, or utilize the User Group functionality predefined in the Lawson Environment system to limit the list of users within the group.

Custom security role for normal batch job users

Installations that have a lot of batch users might want to create a custom role that they will assign to normal batch users rather than assigning the Lawson-delivered role, BatchRole, to users who do not need it.

Jobs and reports access Lawson Portal

Lawson Portal administrators can hide access to some job-related functions. When functions are hidden, users should not be able to access them. Likewise, if options for running jobs-related functions appear on a user's screen but users have not been granted access to required objects, they will not be able to use jobs functions.

Security and Lawson Portal administrators should work together to ensure that only options that a user should see appear on the system and that the user has been granted access to those options.