Sorry about the cross post - this is both reporting and security related.

We are getting a little bit of run around form Lawson on this - my early suspicion is that what we are trying to do cannot be done with straight Lawson. I'm told that the OLE DB adapter (which we are using to write Cyrstal Reports against Lawson data) does NOT enforce record level security - that is only something that is Token driven. And indeed we have found holes in getting to data the record level securoty does restrict through the application. The example of what we are trying to do is this:

We have a user who can only see certain groups of employees based upon their record level security - but they do have access to payroll/HR info for others - so we can't just restrict something like the PRCHECK or PAYMASTR tables from them, nor can we remove the PR system code. In addition, we can't restrict an entire process level because we have different level of employees within a process level - some they can see and some they can't.

ALL OF THIS can be restricted with success using LAUA out of the box. However, if this user creates a crystal report they have full access to all of the data in the PRCHECK/PAYMASTR/etc... tables.

We can't use a condition on the PRCHECK tables, for example, because conditions in LAUA only allow you to restrict based upon fields local to that table only - I can't link though a condition (that I can see at least) that allows me to limit records fom PRCHECK based upon a field in the EMPLOYEE table...

Basically we are trying to find out if OLE DB -- DOES NOT -- provide all of the same level of security that is provided from within the application - without a "custom" approach (i.e., database views and using standard OLE DB, etc...)

Also, if others are providing Crystal Report capability to their users how are you restricting access for them (any method)? Our development manager does not want to make his developers report writers for all of the users....

The OLE DB Provider for Lawson should retain your Lawson based security. Im not sure I understand your use case scenario, but whatever data they are allowed to see in Portal or LID should translate to the this provider. It use dme.exe which authenticates to IOS which is tied to the RD30 record, I believe.

What you will run into with the OLE DB Provider for Lawson (also referred to as the tool used to write the command statements, OLE DB Lawson Query Builder) is that complex reporting is difficult and performance on the users end is poor.

What method will you be delivering these Crystal Reports, desktop client, Crystal Enterprise, Business Objects Enterprise or LBIs Reporting Services?

hth,
Matt

We're doing "record-level security" within Crystal Reports running in LBI (specifically, Reporting Services). Our method ignores OLE DB -- it's too slow, so we just use ODBC, much faster.

We set up elements and structures within LBI, then set up Rights and tie one user to one right. Each Right has restrictions on what data can be seen, depending on the structure and the elements within that structure. Works great.

What we lose by going this route is the ability to do Drill Around, since we can't Drill Around with security using ODBC.

[For your info, we're on LSF 9 with 9 apps, UNIX servers, LBI running on Windows servers.]

Actually we got a response back that this seems to be a hole in security on 8.0.3, so we are waiting on the PT.

Yes, we just moved from LRS to LBI and have not really looked at elements and rights yet - and, yes, the performance has been an issue, but it was accepted over having to set up all of the access control on the database and to let LAUA handle it. We will be going to LSF9 and Lawson Security soon, so I know we will have more options then. I'm curious on the elements and rights - the users would then have to build all of the table relationships within the reports, correct? That was one other advantage of the Lawson OLE DB adapter - many of our users are not going to have a clue as to what tables are related, etc...

Forgive my ignorance on this - have not been through training on LBI (yet). I can see where you can create a data source and then how you could create elements and rights - but if I'm developing a crystal report, how to I attach to that data source when I'm developing the report? I also can't see that I can override the reports data source with one defined in LBI, if that is how it is done.

Just looking for the right direction to look - the Reporting Services Admin guide leaves a LOT to read between the lines.

georgegraham

First off, you could write an ETL process to extract your LAUA rights into a CSV file that could then uploaded into Reporting Services (RS) that would create a mirror in Rights.

Secondly, when you say "users have to do the table linking" are you referring to the users that will be developing reports or the users that will be running the reports? The former will need to be competent in RDMBS linking but its fairly easy when using the Link Expert in Crystal. The latter wont need this in depth knowledge.

Third, you associate your Rights with your report by going to the Details link of a report and clicking on Bursting Options. From here you match your elements within a Right to a field within the Report.

And finally, to override a reports default data source
>Go to Report Administration
>Click New Datasource from the bottom left side
>Select the data source driver youll be working with, give it a name and click next
>Enter valid parameters for the data source and then save
>Now go to the report you want to override, click on Data source Settings
>From the Override drop down select the data source you just set up, you dont need to fill in the username and password below the drop down, it will user the values in the Override data source

Keep in mind that RS determines what drivers are used in the report and will only allow you select matching Override Data sources.

Milo,

A note about your mention that you cant do Drill Around. You can but there are a couple caveats:
1. Your authentication source for LBI is the same as Drill Around (ie IOS)
2. You have you LAUA definitions set up

If those are both true, all you have to do is authenticate the user with the current token and IDA handles the rest.

hth,
matt