NT user group

Garry,

You can create and put in an Role your company for your user needs in LSF9 security. Check the Lawson document "Lawson Administration - Resources and Security 9.0". Great for understanding how many things in LSF9 work.  There are some pre-created roles and groups for you already. Every company is different so it depends on the Roles and Groups your company has decided upon. If you are using LSF9 security (LS Security turned on, and not using LAUA security), then yes, if you want users to "securily" access Lawson, they would need to be put in Groups/Roles.

2. No, you don't need to create rules for invoked programs, unless you very specifically need to. Think of how messy it could get if you needed to secure and write a rule for every single invoked program for a PO20, or HR11 for example.

Roger

Posted By Garry Ferwerda on 01/28/2009 12:56 PM
Hi:   I have a couple of questions about implementing Lawson securtiy:   
1)  I have not found any documentation or seen any discussion on what role the user group that is entered on the security tab of laconfig  has if LS security is being used.   Do all Lawson users still need to be a member of this group if they are using LS security and not accessing the LID command line?

2)  Do rules have to be written for the invoke programs (HPPV, HACV for example) if they are not going to be accessed directly, but only accessed via a calling program?

Thanks

2. I disagree.

I should have been clearer about the word 'role' in my question. I was not talking about a role in as it is used in security, but in the more general sense. In NT, a user had to be a member of the AD group entered on the security tab of laconfig to appear in LAUA. My question is, is there still a requirment for the existence of and membership in this AD group?

John, why do you disagree?

Lawson uses a subroutine technique in some modules that INVOKEs a form within code. The theory behind this technique is that a form contains "business logic", and as such, is a self-contained module. Another program can then INVOKE that form module--programmatically--just like a user entering data in that form. This technique is heavily used in the v8.x Procurement suite. For example, the code to print delivery tickets is not in PO30 or PO130, but rather in an INVOKEd form POIE.

What's interesting about the INVOKEd forms is the security. A user does not have to have laua program access to an INVOKEd form, as long as they have access to the base form that INVOKEs it. In other words, a user can have access to PO30, and not POIE, and PO30 will still INVOKE POIE to print a delivery ticket.

However, the user MUST have access to the INVOKEd form in order to view reports created by the INVOKEd form. In this example, the user can use PO30 to print delivery tickets (and perhaps have them routed automatically to a printer). However, in Print Manager, the user will not be able to see the print files created by POIE unless they explicitly have laua security access to POIE in the product line in which the print file is created.

Yes, you still need to be a member of the AD group. Try running a quick test on a user. Remove them from the AD group and after recycling, see if they can access the system. My guess is not.