Hi,

I need a way to devise user security in MRE such that I can control row and column permissions at the MRE user group level.

I can simulate this behavior at the domain level by creating Reporting Objects and limiting the Application Path to only the folder structure for that domain but there are issues when it comes to applying the filter settings defined in the Reporting Object to standard reports. It also creates a lot of management overhead for each distinct user group (domain) because I need to copy the standard reports and reporting objects and make adjustments to the where clauses and such.

I've seen some documentation about the DBA Security feature but it is too sparse for me to fully understand how to implement it. It also seems to me that I have to select either Reporting Objects or DBA but that I can't use both, is that right?

Is there any DBA-for-dummies level documentation out there that I can reference?

In a perfect world I'd have one set of synonyms / business views from which to build reports either in DevStudio or through the MRE. Then, I'd have an interface where I can sepecify the restrictions for MRE User Groups. When a user logged on to MRE their access to data would be limited by virtue of their group membership.

Can this be done - here's the key - in a simple-to-manage way?

Thanks,

Dan

Hi Dan,

Do you have an updated status regarding this issue?

The suggestion from our internal technicals is that, the best channel for assistance would be your local SE's (you may want to contact your local branch) and/or education. The issue will involve a lot more details than providing simple information/directions.

Hope this helps.

Cheers,

Kerry

Dan,
There are a few ways to achieve this, but all require some measure of maintenance.
The best option, in my opinion, is one in which there are already existing tools for the maintenance of the row and/or column level provisioning.

DBA can be used on, but it has no interface that I'm aware of; but is implemented from a file or from within the masters themselves.

You could use database views, segregate them into separate app folders (with the same MFD name), and then set the APP path dynamically for each user as they log in.
You could call a single FOCEXEC from the EDASRPOF.prf to accept the users' ID using GETUSER or CNCTUSR then either do a look up query or decode, etc. to determine which app folder would need to be appended to the app path (APP APPENDPATH appfolderx)

If it's more complicated than that, you might have to contact your local branch about having a WF security consultant brought in to discuss your options/make recommendations.
Doug