I am trying to hide a reporting object field name to prevent users from seeing it in Infoassit report for security reason. The hidden field makes the report work as expected but the problem is that the hidden field is still visible to the users in the query window of Infoassist. As its been seen by users, they can remove the field and then render the security invalid.

I used 'NOPRINT' method in the report. Please, is there a way of making a field hidden in Infoassist and at the same time not been seen at all by the users?

This message has been edited. Last edited by: Kerry,

Read up on DBA

Use ACCESS_PROPERTY=(INTERNAL) in MFD

Think that's the right syntax.

Hi,

You can also use the ACCESS=(INTERNAL) property in the MFD, but that will also hide it from Dev Studio.

It also sounds like you want the field to be IN the TABLE request. IA may have an issue with a field in it's query tree that it can not find info about (because of the INTERNAL property). I am not sure how your security system works - but to make sure that the TABLE engine always asks for the field from the DBMS, you can add it to a REPORTING OBJECT as a WHERE.
WHERE HIDDEN EQ 0 or HIDDEN NE 0; will make sure it is an active field in the request (though not part of the output).

I am still having issue with this. My intendtion is add a BY Field to Infoassist Report and make that BY field invisible to all all users. Please, can you let me know how this can be done?

Thanks

To make it a bit clear: I have a BY Field, LOCATION. In Infoassist report, users can add or remove this BY Field. But the business specification is that this BY Field must be added to make the security work well based on LOCATION.

My intention is to "secretly" add this BY Field by default amd make it hidden. This is to ensure that even when users decide to add or remove the "visible" LOCATION BY Field, it won't affect the report security because there is a hidden LOCATION BY Field, unknown to users.

The report security is tied to the LOCATION field. If this field is not in the report, the users will see all location data and I want to avoid this.

Any advice on how this can be achieved will be appreciated. Thanks.

e.g
SUM
amt1
amt2
BY LOCATION ( this needs to be hidden and remain invisible to users )
BY LOCATION ( this is visible and can be added or removed from infoassist by users )
BY DATE

The reason is that even when users remove one LOCATION field, the invisible one will still make the users only see data for their location

.

I ask again - does LOCATION have to be a BY field --- or does simply having in the request do the trick? (I admit that I do not understand what security system you have that is tied to a BY fld).
Does have a where clause like
WHERE LOCATION NE ' ' cause your mysterious security to work?

Brian,
The report does not have to have LOCATION as a BY FIELD but the only way the security works now is to add LOCATION as a BY FIELD. However, if I have a way of making Locations A, B and C see only data for A, B and C respectively, I wouldn't be adding a LOCATION BY FIELD.

Here is the security setup:

1. Security is applied to LOCATION dimension in the Analysis Services Cube.
2. Location(e.g A, B and C) users are suppose to see only their location specific data via an infoassist report. But this is not the case if a LOCATION BY FIELD is not added to the report. This is why I intend to add it to the report and make it hidden so that users can not remove it.

Having it in a WHERE clause, as you suggested, would have been ok if I am only dealing with one location. For example, if I have locations A,B and C, how do I make a WHERE clause to restrict data for location A user, Location B user and that of C while all users run the same report?

I hope this is clear about what I intend to do.

Thanks.

Hey umun,

It sounds like you should look in to using DBA statements and the MFD_PROFILE at the metadata (synonym/master file) layer. This will guarantee that the row level data is filtered regardless of how the synonym is accessed, e.g. InfoAssist, standard reports, etc. Also, you won't have to use hidden fields.

You are on 7.7.02 so you'd have to move to 7.7.03M or later.

The MFD_PROFILE is a statement in the master file that calls a fex.

Example from our SSAS synonym's first line:
FILENAME=FieldReportCubeLocale, SUFFIX=SSAS, MFD_PROFILE=baseapp/ssas_conn_locale.fex, $

That fex alters the locale property of the connection string so SSAS will return the appropriately localized dimension member names (the connection string modification is a 7.7.04 feature that I haven't proven out yet but it's also not germane to your issue).

So, baseapp/ssas_conn_locale.fex is called every time a report or anything accesses that cube. Similar to your situation, I need to filter locations based on the user so I will be creating a fex that builds a HOLD table for each users permitted locations. We'll call it HOLDLOC for now.

The DBA file is used to force filtering of the data (in this use case) and will be coded to filter locations in the synonym by what's in HOLDLOC.

I just started on this implementation in our current sprint and will update this thread once I have a working solution. But, as far as the lab I went to at Summit 2012 and other documentation it should work like a charm.

At least start looking at the documentation for DBA and MFD_PROFILE and go from there. Once implemented, when a user does a BY on Locations they'll only get the locations they have access to (based on the HOLDLOC table in the example above).

Kevin

disclaimer: I've been using WebFOCUS for just a few months so information provided is to the best of my understanding