Can't see good variables in Query Designer BW 7.0

Question

Hello,
The technical name of our caracteristic variables in the Query Designer are prefixed by "OR_" or "SV_". I try to make a filter in this variables (for example: a user must be able to see only "SV_" variable) with the authorization objects S_RS_COMP and S_RS_COMP1. But this filter does not work, even if the ST01 trace shows me a Return Code = 4 for the test in the variable technical name.
Have I made something wrong ? is it a bug ? (we are in BW 7.0 SPS9 with Sapgui 6.40 SP 19 and BEx SP 12).
Thank you for your help

Answer 1

Hi Paul,
If iam not worng, are you asking about Infoobject level security in BW?
If it is, the following are the steps need to be implemented:
<u><b>Steps to Implement InfoObject Security (field-level security)</b></u>
1) Make the InfoObject authorization-relevant.
The Authorization Relevant setting for an InfoObject made in the InfoObject definition on the Business Explorer tab. The business needs will drive which InfoObjects should be relevant for security. Keep in mind that the people using SAP BWare running queries to help make strategic decisions on how to better run the business. The decision makers typically need to see more data on SAP BW than they would need to see in SAP R/3.
2) Create a custom reporting authorization object.
Since there are no reporting authorization objects provided for InfoObjects, you will have to create your own reporting authorization object for any InfoObject you decide to secure. This is done in transaction code RSSM. When creating your reporting authorization object, you select which fields to put in the authorization object from a list of authorization-relevant InfoObjects. Only InfoObjects that have been marked Authorization Relevant are eligible to be put in a reporting authorization object.
3) Add your new authorization object to a role.
Once you have created an new reporting authorization object and linked it to the appropriate InfoCube(s), users will need access to your reporting authorization object. You will need to manually insert your object into a role.
4) Add a variable to the query.
The reason the variable is required is sometimes unclear at first. If we want a  query to only provide results based on the division, for example, then the query itself needs the ability to filter specific division values. Before we can secure on division, the query must be  able to restrict data by division. The only way the query can restrict data dynamically is through a variable.
5) Link the reporting authorization object to an InfoProvider.
Linking your reporting authorization object to an InfoProvider is a very critical step. In this step, you will impact people currently executing queries for the InfoProvider that is now related to your reporting authorization object. This linkage forces your reporting authorization object to be checked when ANY query tied to the InfoProvider is executed.
Hope it helps, please revert back if you are asking for something else.
Please reward points if it is sueful.
Thanks & Regards,
Santosh