Inconsistant (MCU) Row security

We have row security set up for Cost Centres (aka Business Units)(Alias MCU). For the one user in the one session, using P01012/W01012B does not apply the security to F0101.ABMCU, but P0101SL/W0101SLA accessed from P0411 via visual assist does.

This is a repeatable experience for a subset of our users who access our system from the other side of the earth (UAE). All the servers are here (Australia) and access is via the web. Local users do not experience this problem.

Does anyone have any ideas or experience with this?

System Config:

E9.1 TR9.1.2.1, Enterprise Server: Sun, Database Server: Sun, Oracle DB: 11g, WebLogic Server 11g Version 10.3.5.0.

Row security is translated into where clauses that are appended to the SQL statements that pressing find generates.

Therefore to troubleshoot this look in the debug logs - and you can see what SQL statements are being generated and how your row security is and isnt being appended.

I have a white paper if that helps.

Luke,

Thanks very much for your reply.

I was aware of how the security was applied to the WHERE clause of the SQL.

What I need to find out and remedy is the cause of the difference in the two inquiries and the difference between local access and remote access. This will probably mean getting a set of debug logs from a local user to compare with that from a remote user, in addition to analysing the debug logs from the remote user.

One thing I would like to find out, which probably won't be in the debug log, is how much/what type of processing (if any) occurs (in the browser?) on the remote users computer. Especially anything related to the security applied to the SQL.

As yet I have not been able to get debug logs of this for a number of varied reasons. I will have to see if it can be repeated in our test system, as yet I have not done this - another long story. As soon as I can I will get a debug log, hopefully from both test and production.

I am very interested in the SQL to retrieve the address book data (especially the security criteria attached to the WHERE clause) and in the SQLs to retrieve the security information. Both should be available in the debug log (as soon as I can get it).

While I am waiting for the opportunity to get a debug log I want to find out if anyone else has experienced this, or has any idea about the cause.

Peter , are you trying to hide data (View = No)
with the row security and it does not hide when using P01012 ?

Are you using inclusive or exclusive row security and is it a range you are trying to secure or a single value.

What is your Web Server OS platform ? Is it different from your Enterprise Server which you have mentioned is on Sun .

What results do you see from UTB and databrowser.

I presume you have tried deleting all the relevant glbtbl files

Ice,

Thanks, for your reply. Answers to your questions are below.

[ QUOTE ]
are you trying to hide data (View = No)
with the row security and it does not hide when using P01012 ?


[/ QUOTE ]
Yes.



[ QUOTE ]
Are you using inclusive or exclusive row security and is it a range you are trying to secure or a single value.


[/ QUOTE ]
We use exclusive row security. We use 3 values in the address book cost centre say: A, B, and F. Local users get access to A and B and remote users get access to A and F. (There additional MCU row security entries that are applicable for other data.) It is set up for *ALL tables. Remote users are set up like:

A to A Yes Access Allowed
B to E No Access Not Allowed
F to F Yes Access Allowed
G to Z No Access Not Allowed



[ QUOTE ]
What results do you see from UTB and databrowser

[/ QUOTE ]
As the problem is with remote users and we do not allow access to UTB and databrowser for users, we cannot check this. Remember all is as expected for users locally even when they are set up the same as remote users, the see what they should and don't see what they shouldn't.



[ QUOTE ]
I presume you have tried deleting all the relevant glbtbl files

[/ QUOTE ]
I think deleting those files would be irrelevant as this works for local users and not for remote users.

Peter:
A question.
Remote users have the same role as local users?
If not you should see if the role of the remote user does not have security applied exclusive (Type 9) for the P01012 application.

Sorry for my english, is very poor.

Regards

conso,

Exclusive Application security on the P01012 seems to be the cause. Thanks conso for your help. I'm not sure why that is there.