GL40.2 security error on adding records

Do you get a specific error message or just "Security Violation"?

Do the have the 'R' Form Action ?

Do they have access to IF system code and IFGT token?

I think the security file was corrupt. I ran
secinteg -fuv
secinteg -f
bldsecdict -d productline

and it is fine now.
Thanks

Glad it's fixed!

Is access to IFGT.1 with function code "A" required to Release an entry or otherwise interact with GL40.*? I was under the impression that if you had "R" on GL40.2, for example, that you could release an entry no problem because the decision analytics documentation does not refer to IFGT except for at the very bottom under "Invoked Programs". Would somebody mind explaining to me if users require access to the Invoked Programs listed on the D.A. documentation as well as the specific/respective forms themselves? Thanks all.

If a program invokes another program, then both programs need to be part of the security class. So, yes, in this case if you're giving access to GL40 to release, you would need to also give access to any programs invoked by GL40, such as IFGT.

Ok. Wow. This is a serious blow to my understanding of the whole schema. I had gone through and determined who had access (and what level of access) to a bunch of specific forms based on the Forms, User, Data, and Sec Security Reports but now it seems that there's a whole different layer of security to factor in. Is there anything Else that I'm also not considering? I had the Form, User, Data and Sec reports pulled into a database and had a query built to analyze it, but now it looks like I need to create a new table that has, by Form, the Invoked Program for each and link that in my query as well. Do you believe that to be correct John? Is there anything else (any other tokens (universe or user), etc.) that are required to run specific actions on forms?

Also, is there a more condensed list of forms and their respective invoked programs? I'm thinking of something more in an excel/access format that could be easily imported into a database. Otherwise, I've got a lot of typing ahead of me :) At least I am noticing that the Invoked Programs are similar for many forms.

Thanks you very very much for responses. If there is any documentation out there that I can read to understand this better instead of you having to explain it I'm definitely open to that. I just havent found anything that talked about this stipulation. Also, sorry if this thing replies twice. I can't figure out why it's doing that.

I'm assuming your on v8, and not on LSF9...

You can use rngdbdump against the GEN table PGMCALL to see which programs invoke which programs. You could use rngdbdump -c to put into a CSV file and then import into your database.

As a rule, I would generally recommend granting IF system code in its entirety to any user class, and then IFGT to any security class which creates a transaction that gets posted (IFGT is the program which creates posting transaction in GL).

As for general/overall documentation of this, there might be some CUE presentations that Lawson can provide, but I can't recall ever seeing any ...

 

Interesting. I am confused about a couple things: Does this mean, again for example, that user's all require access to ACAC.1 if they want to run an activity from any form? If that is the case, then I assume you don't required "ALL ACCESS" at the Data layer or any other level of access beyond pure inquiry only (secured = Yes is okay, Function Code "I" only is okay) to ACAC.1. Because I did a query on just ACAC.1 and only 2 people have access above Inquiry only in my system. I queried some of the other invoked programs (ACCL.1, ACTA.1, API4.1, etc.) and they are also pretty well restricted. Meaning, for example, I know people have access to PA52.1 and are using that Form in real life but based on their access to the Invoked Programs, it would seem like they shouldn't, systematically, have access to Personnel Actions.

Thanks for the help. This is sort of a shocker to me and *could* mean that I have to redo a lot of work....

It depends on what the invoked program does--you'd have to look at the function codes available for each one. In the case of ACAC, it is an Inquiry only form used to edit activity/acct category, etc. IFGT is Add-only--invoked by calling programs to post transactions.

Couple questions for the board:

Is it the same for all Lawson implementations as far as what programs call which? Or can this be (or is it always) modified for needs?

Along with the ability to dump all called programs which John explained above, is it possible to create a report which details if the invoked program is an inquiry only or a form which would require All Access (ACAC vs. IFGT). Also, can you show which Unsecured FC's are required to do what? For example, "A" for IFGT.1.

Generally speaking, from the system, can you produce a list of all Forms and list each available function code for the Form and what it does?

Jill, that's a tough question. I would say, theoretically, as long as clients are on the same MSP, that would be the case. However, there are exceptions. A program could easily be updated by a CTP-installed by one client but not the other--that changes the code to call another library or invoke a program. So, I'd never assume that one client's code matches anothers ones.

Securing invoked programs is something clients typically ignore, mostly because they don't even realize they are out there. Some invoked programs simply do lookups, but others are quite powerful. For instance, in the PO rewrite in 8.0.x, most of the processing functionality is accomplished via invoked programs called from shared libraries...

As for getting the info you're looking for, the only report which will provide that information is 'tknsecrpt' (Form ID Security Report), which will tell you which FCs are asssociated with which programs and are secured/unsecured, but as for what the FCs mean...that's a different topic, which I've already covered (see https://www.lawsonguru.co.../1179/Default.aspx).

A few years ago, I created an "Explorer" type approach to "surfing" the LAUA security info (you can see a screen shot here https://www.danalytics.com/guru/letter/archive/2006-08_files/ags1.jpg), but with LSF9 coming into the picture, I decided not to release it.

Thanks very much for your time. I'm sure you're a very busy person.

Do you have any links to a site/document that explains in detail the changes in security when moving to Lawson 9? Google isn't helping and the Lawson website doesn't have specifics.

Specifically, I'd like to find out if the only real difference is the addition of the "Role" level of security which I believe is linked to the Security Classes in a one to many relationship.

Or, are the 4 security reports that we have been using irrelevant now (or not even included in 9.0) :
1) Form ID - "tknsecrpt"
2) Data Security - "?" do you know the names
3) Security Class - "?"
4) User Information - "?"

I appreciate this website so much. I've shared it with my colleagues. Kind regards.

Jill,

With LSF9, you can--on a user-by-user basis--either keep the existing LAUA security, or migrate to the new LSF9 role-based security. Typically, an organization will make a project of developing the rules and migrating a group of users (GL, employee self service, etc.) over to LSF9 security. It's not a light undertaking.

The key differences w/ LSF9 security as far as security with Lawson applications are:
- Rules can be as granular is needed (any object is securable--table, form, function code, drillaround, etc. etc.)
- Rules can even be logic-driven (e..g. Javascript functions) beyond the "data security" offered by LAUA security
- Users can be assigned to multiple roles

LAUA security used a "subtractive" model--upon installation, you have access to everything and security was enforced by taking things away.
LSF9 works in an opposite manner--you don't have access to anything, and you grant security access by giving access to things.

So, to grant access to GL40 for example, you'd need to grant access to the various GL tables, the GL system code, the product line, GL40 itself, etc. etc.

Hence the reason it's a big project to migrate...

In my opinion, Lawson probably made a mistake in opening up security too much. I think what happened is that it was SO limited in LAUA that they got really tired of hearing about it. Consequently, they essentially said, "OK clients, you said you wanted more control over security--here it is--go configure it!" and decided to open EVERYTHING AND ANYTHING for security rules. It's just a disaster waiting to happen, as clients start coding logic / rules into the security.