Authorization checks for filter values

[Former Member]

Hi,

I'd need to apply authorization checks to filter values in web reporting. The authorizations should be limited with an attribute of the characteristic, not the characteristic itself.

A practical example:

There are two companies A and B. The companies are not allowed to see any data from each other.

There is a report that displays sales orders. It is used by both companies. The selection of sales orders is limited with the characteristic 'distribution channel', so the initial display is fine.

customer sales order

cust1 so1

cust1 so2

cust2 so3

cust2 so4

...

Users should be able to filter the sales orders by customer. As filter values, the users should only be able to see and select customers from their own company.

Access to customers should be limited with an attribute of the customer, e.g. company code, because it would be impossible to maintain authorization profiles that contain lists of customers.

However, it seems that BEx and web reports don't care about the authorization restrictions applied to the company code. When a user from company A clicks on the characteristic 'customer' and selects filter values (e.g. with F4), he can choose from all customers.

So, how could we apply authorization checks to filter values?

Message was edited by: Arto Pihlaja

[Former Member]

I'd try the following one:

Define company code from 0CUSTOMER as navigational attribute and include it in your cube. Define a variable on the navigational attribute and fill it from authorizations. Drag the variable into the filter.

Best regards

Dirk

[tom_francis2]

If I understand your question well, you have succeeded in setting up authorization correctly. (query RESULTS are filtered based on authorization, but not your F4 selection).

You should use hierarchies to build your authorization. This way you can restrict your selection screen to a variable node (look for the how-to paper on this subject to make it work).

I have used this before and it works perfect, the only disadvantage is that your selection screen is looking different than normal.

If your authorization is not even setup correctly, you should create an authorization object (eg. on company code) and activate it for your cube using transaction RSSM.

Hope it helps,

Tom

[Former Member]

Hi Dirk,

and thanks for your tip!

Unfortunately I haven't yet been able to test it out. Meanwhile, I'll just review the theory and check that I've understood your idea.

Continuing with the customer & sales order example, the report could look something like this:

customer comp. sal.ord.

cust1......A......so1

cust1......A......so2

cust1......A......so3

cust2......A......so4

cust2......A......so5

cust3......A......so6

when a user from company A runs it.

What happens if there is a filter for the characteristic Customer, and the user changes the filter values? What values are displayed as possible filter values? Do you mean that BW limits the values of 'customer' based on authorizations to the attribute 'company'?

Message was edited by: Arto Pihlaja

[Former Member]

Hello Tom and Dirk,

and sorry to keep your points pending for a while more. I don't know yet if you were greatly helpful or even fully solved the problem.

Tom, you've understood my point. However, there are no hierarchies for the characteristic in the source system, and it would be too complicated to maintain them manually in BW.

[Former Member]

Hi Dirk,

your suggestion is OK in the traditional Excel-based BEx, but unfortunately not in web reports.

In fact, I had already a similar solution with user exits in place. I didn't test the traditional BEx until now. Now I see that it works, too. I consider it a bug that the web reports don't work the same way as the traditional, so I'll create a customer message.

Thanks a lot!

Regards,

Arto

[Former Member]

Hi Arto,

authorizations should work the same for Excel- and web frontend. Opening an OSS message seems to be a good idea here.

Best regards

Dirk