BW Navigation Attributes

[Former Member]

Hey, all,

I'm just checking myself here -

We have a BW 3.5 system. We have 0GL_ACCOUNT set as authorizationally relevant. We have a object (Z_GLACCT) created and set with various value ranges for the different GL account sets.

The user reported an issue where she was able to run queries and workbooks without putting any GL account values in and it returned only the data for the GL accounts that she had authorization for. Now, if she runs them without inputting GL account values that she is authorized for, she gets an authorization error on Z_GLACCT. However, if she runs the queries with specific values for GL account that she is authorized for, the query/workbook runs fine.

We have made no changes to the security roles or the roles assigned to the user.

The only change that I can find is that one of our developers turned on the navigation attribute for 0GL_ACCOUNT. In the new 7x systems, there is a checkbox for making navigation attributes auth relevant but we do not have that in our BW 3.5 system.

Am I off base here in thinking that the change to the navigation attribute is probably causing our issue?

Thanks!

[shivraj_singh2]

Melissa,

As long as your system is on BW 3.5 security settings, marking Nav Attr auth relevant will not affect anything.

GL Account issue

- Is GL Account marked neccessary input in the variable screen ? That will cause the user to get error if you try to run query without input

- Please use authorization variable in the query for GL_ACCOUNT

- As a precaution please mention : in the field values for Z_GLACCT along with the value range you have assigned to the user.

Regards.

[Former Member]

Is GL Account marked neccessary input in the variable screen ? That will cause the user to get error if you try to run query without input

My thought is "no". A user who has Z_GLACCT with a value of * can run the query with no input with no issues. It is only the user with specified values in Z_GLACCT who cannot run the query without inputting specific GL accounts that she has access to.

Please use authorization variable in the query for GL_ACCOUNT

We don't want this function working any differently than it was working previously so we don't want to add any levels of security. GL account is relevant but it should not require them to input on queries, it should pull data and then display only that which they have authority for.

As a precaution please mention : in the field values for Z_GLACCT along with the value range you have assigned to the user 

I'm not sure what you are asking for here? We have told the user that if she enters the gl accounts she has access to, the query will run, however, we are in investigative mode. Obviously, a change was made that impacted the security functions. We need to know what it was.

Cheers

[shivraj_singh2]

Melissa,

User with (*) access being able to execute query without authorization variable in query is expected behavior.

User with limited access will need authorization variable added to the query for being able to execute the query successfully

Adding Authorization variable to queries is a standard practice for automatic loading of the authorized object values for the user when executing the query, query developer should be doing it for the secured objects in query.

Adding ( - Z_GLACCT [0001 - 0009, :] add it to the field value in the role. - But you may not need it, from what you have described so far, query is missing authorization variable for GL Account

Regards.

Shivraj

[Former Member]

Is there a way to revert this back? We do not want this behavior. The report developer did something to 0GL_ACCOUNT (since this is impacting all queries and workbooks that have 0GL_ACCOUNT) - I am trying to figure out exactly what was done so I can direct him to change it back. Since it is popping a security error, he is not accepting that he did anything. Theoretically, security is working - she can only see what she is authorized to see provided she runs the report correctly.

(I even used the ABAP developer coding CALL FUNCTION 'AUTHORITY_CHECK_TCODE' example but as far as he is concerned, report development has nothing to do with security.) (which is a whole different issue)

[shivraj_singh2]

Melissa,

Nothing is out of normal, so nothing needs to be reverted.

The query needs a GL account auth variable.

Regards,

Shivraj

[Former Member]

On October 31st, the user was able to run the query with no input and get the data that she was authorized for.

On October 31st, over night, 0GL_ACCOUNT was transported into production with changes.

On November 1st, the user was getting an authorization error if she ran the report with no data.

Something happened

We have the fix - the user needs to run the report with input.

However, we need to know what the change was that was made - I have the change log on 0GL_ACCOUNT and it appears that he turned on the navigation attributes. We need to know if that change is what is causing this issue.

Without knowing what the change was, we have no way to catch this happening again with another characteristic in the futue.

[shivraj_singh2]

Melissa,

You can test by removing the auth relevancy on nav attr and transporting that changes to production again.

Before doing that you many want to review if there was any change in the query.

Regards.