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....