A user in BW 3.5 is assigned one role that has a few auth objects including S_RS_COMP. He is getting an auth failure that we can see in ST01 trace. But the role gives all values seen in the ST01 error....the user master is compared, and the role is generated and green status. This user should NOT get an auth failure, he definitely has all values seen in the failure. Here is the weird thing, when I edit the role to remove the asterisk in RSZCOMPTP and replace with explicit values (OWZ, REP), it works. I can't explain it. If I put it back to *, it fails. Is this a bug? Has anyone else seen something like this?
Another possible explanation is that the developer reverse engineered the check -> he first read the values in the authorizations (expecting explicit ones) and then used the authorized values to filter the selected ones and only return that which the user is authorized for.
The correct way would be to perform an authority-check on what was selected, filter that which the user is not authorized for (and possibly tell then how many records were not displayed).
It should authorize on the value * and not go looking for a * in the check table...
If you still have the trace, then please post the coding (double-click the line item and use the "Go to source" button).
Authorization Obj. : S_RS_COMP
SY-SUBRC : 4 (No authorization
Program : SAPLRSSB
Row : 783
No.of Auth. Values : 5
from FM: RSSB_AUTHORITY_COMP_CHECK
Goto Source button take me to the line starting with "ELSE"
IF NOT i_infoarea IS INITIAL. IF NOT i_infocube IS INITIAL. IF NOT l_comptype IS INITIAL. IF NOT i_compid IS INITIAL. IF NOT i_actvt IS INITIAL. AUTHORITY-CHECK OBJECT 'S_RS_COMP' ID 'RSINFOAREA' FIELD i_infoarea ID 'RSINFOCUBE' FIELD i_infocube ID 'RSZCOMPTP' FIELD l_comptype ID 'RSZCOMPID' FIELD i_compid ID 'ACTVT' FIELD i_actvt. ELSE. "i_actvt is initial AUTHORITY-CHECK OBJECT 'S_RS_COMP' ID 'RSINFOAREA' FIELD i_infoarea ID 'RSINFOCUBE' FIELD i_infocube ID 'RSZCOMPTP' FIELD l_comptype ID 'RSZCOMPID' FIELD i_compid ID 'ACTVT' DUMMY.
I wonder if this was a role comparison issue. The role was not Yellow status, but there are continual problems in this system with user comparison not working (roles staying yellow) after the PFUD job runs. The only consistent method solution was to use explicit values in the role.... but looking at this code, I wonder why it though i_actvt was initial. The role has always had activities 03,16 and 22 explicitly stated.
I have faced the same kind of issue on R/3 system while doing the Upgrade. What we observed in the same situation, the user had assigned with 2 different roles(say, Role A & Role B) with the same required auth. object is present in both roles. In Role A, that auth Object with restricted values and in Role B, the same auth. object with value "*". In that case, if the user assigned with both roles user is facing the missing authorization. When we tried on trial and error by removing the Role B with auth. obj., it is giving missing auth error as there is no required value and when removing Role A its working. So we conclude that, on the user buffer ifself, the checks are giving priority to extent for the same object with different values from different roles assigned.
I hope this way it can give you some clue for your workaround.