Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

BW Query designer security issue

Former Member
0 Kudos

Hi all,

We have a role created for BW power users (ad-hoc queries) which should give them access to open the Z-queries and save them as Y-queries and then be able to change their own Y-queries.

When the power user opens the Z-query using the query designer, the characteristics and the default values are greyed out. And gets an error message "You are not authorized to query XXXXX".

Though the role allows them to save the Z as Y-query, they are not able to edit their Y-query (due to the already greyed out issue while opening the z-query).

When I add the actvity =02, 06 in addition to the previously assigned 03, 16 for both COMP and COMP1 objects, The user is now able to open the z-query without any error message (also the characteristics and dafault values are not grayed out anymore) and is able to save to as Y-query and edit it.

COMP and COMP1 have acvtivity = * for the Y-queries, this will allows the power users to have complete access to their own Y-queries.

======================

Now,

by adding the activity = 02, 06, I end up giving the power users access to change and delete Z-queries, which should not happen.

Can somenow help me understand how to avoid them from changing and deleting the z-queries but at the same time give the right solution.

We are on BI 7.0. I am wondering if this issue is related to an OSS note.

Thanks.

1 ACCEPTED SOLUTION

Former Member

I just discussed this with OSS a few weeks ago. We were also needing S_TRANSPRT display in our QA system. The reason has to do with having a transport open that is gathering queries.

We were transporting some queries from QA to Prod. I believe you can open them based on cube or area. Anyway check with you configurer and ask them if they have a transport open that is gathering queries and have them close it. There is no reason to be doing this in production.

SAP referred to it as having the transport system open.

Thanks,

Mary

5 REPLIES 5

Former Member
0 Kudos

Hi,

try to add S_USER_AGR in a role.

With this you can save your own query in a role.

hope it helps

0 Kudos

Thanks Grevaz, object S_USER_AGR did fix the problem. I had spelled the role name wrong in this object. Your reply made me go and check that object again.

But I still see the pop up message which says "you are not authorized for query xxxx" when I open the Z query using the query designer. When I give 02 and 06 activities for comp and comp 1 objects, the error message doe not appear anymore. I found an OSS note 946027 about this problem which suggest appling SP 9 for BI 7.0 but we are already on SP10 for BI 7.0.

Did anyone ever had this problem?

0 Kudos

Query designer is behaving very strange. The Power user role provides access to all the required InfoAreas, InfoCubes, and Queries. It somehow works for some Infocubes when the power user saves the Z queries as Y queries and further edit the Y queries.

However, saving and changing Y queries for someother infocubes is looking for authorizations to display transport requests S_TRANSPORT. When I give this access, it works. Though there is no risk in giving display access to this object, I wonder why this happens.

Following are the 2 error messages I received when I tried to edit the Y queries

============================================================

Errors: BEx transport request 'DB1K901977' is not available or not suitable [E827(RSO)]

Diagnosis

There are the following possible causes:

No request has been set up as the standard transport request for BEx objects.

The (set up) request 'DB1K901977' (for the package '' ) has already been released.

The (set up) request 'DB1K901977' (for the package '' ) is not of the type 'transportable change request'.

System Response

The request DB1K901977 can not be used to record changes to BEx objects (queries or Excel workbooks). The changes made to objects you are editing will not be logged.

Procedure

If you want to record changes to BEx objects, set up an open transportable change request as the transport request for BEx objects. (If the package '' is not empty, set up a request for this package).

Inform your system administrator of your actions, or enter a new, targeted transport request in the Administrator Workbench in the transport connection by using the 'BEx' pushbutton (Create Transport Requests for BEx).

Procedure for System Administration

============================================================

Errors: You are not authorized to display requests or tasks [E603(TK)]

Diagnosis

As user TEST_QUERY you are not authorized to display requests or tasks in the Transport Organizer.

System Response

The function terminates.

Procedure

Obtain the appropriate authorization for displaying tasks and requests. The display authorization is contained in all authorizations for authorization object S_TRANSPRT.

============================================================

Any insight on why this authorization is required will be very helpful.

Thanks,

Jay

Former Member

I just discussed this with OSS a few weeks ago. We were also needing S_TRANSPRT display in our QA system. The reason has to do with having a transport open that is gathering queries.

We were transporting some queries from QA to Prod. I believe you can open them based on cube or area. Anyway check with you configurer and ask them if they have a transport open that is gathering queries and have them close it. There is no reason to be doing this in production.

SAP referred to it as having the transport system open.

Thanks,

Mary

0 Kudos

Mary you are awesome.

Yes I find the same situation in our system. In our DEV they have a tranport open and the system is trying access it when the user is saving the Y queries.

However, in QA (here we will not have the DEV transport request) system also I need to add this object to allow saving the Y queries.

And I am guessing even in production it will be required. Lets see how it goes after the change moves to the production