Friday, February 6, 2009

SAP S_TABU_LIN

Question: Hi everyone

I am currently trying to test the limitations of the restrictions that can be enforced by using object S_TABU_LIN, this allows users to only see particular rows of a table depending the restrictions in place.

I am having problems when testing this, as I do not know many table names or what fields lay in what tables - can anyone suggest the values that should sit in S_TABU_LIN and the table/s this relates to?

I dont mind what it does or doesnt let me see because at the moment its simply for testing, i just want it to produce an authorisation error so can see it working and work from that.


Answer:
also does the role have to have access to the authorisation group (in S_TABU_DIS) which the table lies. For example if you are trying to restrict seeing parts of HR master data in S_TABU_LIN would you need authorisation group PA in S_TABU_DIS??

Question: We are creating derived roles, a master role with individual derived roles.
As we know the only values that don't get pushed down are the org. values.
However we are controlling on values that are not org levels. So I would like to make them org levels, for instance company code.

I know you can create org levels in SE38 with PFCG_ORGFIELD_CREATE.
However if you do this will it make company code an org value in every role that it exists?

If so do we have to go into every role or will a value be populated automatically from the role itself?

Is it possible to pick and chose which role you want the new org levels to adhere to?

Any help would be greatly appreciated!!!

Thanks!

Answer:
I know you can create org levels in SE38 with PFCG_ORGFIELD_CREATE.
However if you do this will it make company code an org value in every role that it exists?

Yes

If so do we have to go into every role or will a value be populated automatically from the role itself?

IIRC Values in the fields will become populated as org levels without any further action required from you

Is it possible to pick and chose which role you want the new org levels to adhere to?

No. This is the downside to creating org levels. You can force individual fields in roles to ignore org level behaviour but this is on a role by role basis and not practical to maintain. If you find yourself needing to do this then your design does not suit creating additional org levels.

Answer:
If you create an org level from a field you have already used you may not get the desired results. If you have mixed values in different authorizations where they need to be descrete for different object, the creation of the org level will combine ALL the values into all the authorizations. So be careful and analyse the results of the report BEFORE commiting the results.

Answer:
Test mode

Create org level field KOSTL
Update authorization value proposals (SU24 data)
Conflicts (manual follow-up needed)
Values collected in role: SAP_CA_CL_MAINTAIN
Original values:
Authorization objectAuthorization Values
I_KOSTL T_P092043200
New org level values:
*

Values collected in role: SAP_ESSUSER
Original values:
Authorization objectAuthorization Values
P_TRAVL T_8000022406
P_TRAVL T_8000022407 *
New org level values:
*

Values collected in role: SAP_HR_REPORTING
Original values:
Authorization objectAuthorization Values
P_TRAVL T_P092020100 *
New org level values:
*
01

Thanks so much for your help!!!

Answer:
Looking at my last reply, I didn't get the entire message in.

What is in the last reply is the report that you run PFCG_ORGFIELDS_CREATE, and the results that I get.

My question is why does it say (manual follow up needed) for some of the roles.
All roles affected are at the end of the report. But it lists out conflicts above the list.

Question: With the upgrade version to 4.7 regular transactions, do not work the
same way anymore.

Example transaction VL10H on the Tab ‘General Data’ there is column
named OriginDoc. When you click on one of these fields, it calls the
transaction VA03 (In version 4.6C) but now it is calls VA02 (In Version
4.7).

Why and how can I fix that without giving new roles with transactions
they did not have before and that used to run in the background without
requesting any S_TCODE check?

I have many requests for this kind of problem but for different roles
calling different S_TCODE. If I find a way to fix, one I will know for
all the other roles that call other S_TCODE’s.

Someone told me I could use SE97 to skip S_TCODE check BUT! What if the
transaction really require another transaction to work I do not want to
skip it otherwise we will have another kind of problem? Or I am wrong.

Please help

Nancy

Answer:
Sorry I did not find the one I posted yesterday and I thought I did not saved it.

Sorry for the duplicate of S_TCODE check after upgrade to 4.7

Nancy

Answer:
Dear Nancy,

In higher releases of SAP they are cleaning up their navigation paths. Upgrading, when you business process used a path which has changed (it became stricter to click on), does not mean that the process is any different.

You can call anything what you want. E.g. You can use SE97 to MAINTAIN the check on the CALLED tcode based on which tcode is CALLING it. But if the user can switch their sy-tcode, then the relationship changes. Take a look at table TCDCOUPLES.

SAP also provides other confusing messages though, which might be the case here. SU53 says "no auth tcode" ? But this may be caused by your having "BACK"ed (the ESC or OK problem) or the abap didn´t react sufficiently to the check and met a second auth fail, but gave you a message from either the one, or the other and a SU53 from the last check failed... i.e. the last one before '/nsu53'... not necessarily the one which gave you a "message" or caused your navigation path to change.

The change of the called transaction you mentioned (i.e. from VA03 -> VA02) may also be having an implication based on an application auth object check at tcode start, and not the tcode itself. Check SE93 for VA02.

For this you need to look beyond the tcode and compensate for SAP´s max-confusion-strategy. SU53, PFCG, ST01 and the SoD tools loitering around SAP are fully integrated into this strategy.

Kind regards,
Verne

Answer:
The only thing I found in the table TCDCOUPLES is an entry for
TCODE CALLED
VL10H VA03
VL10 VA02

But I am really in VL10H and I keeps having the message
You are not authorize to use the transaction VA02 !!!

I went in SE97 I created a list of called transactions for VL10H
Do not check VA02
Check Warning VA03
Do I have something else to do after what I did or when I use the role everything will work whitout any other configation.

I really need to know how to configure VL10H to call VA03 instead of VA02. Even with the table TCDCOUPLES or SE97 I am not able to change this setting !!!!

Need help
Nancy

Answer:
You will need to,
1. Call SAP and report the problem, or
2. Search on OSS for a fix
3. Debug the code and see if it is configurable in a table ( probably is not and TDCOUPLES has nothing to do with your want, It must be in the code).

Answer:
The last person who called SAP got 335277 - VL10: VA03 instead of VA02 in display of orders

You will need to work together with your developer and application person for the area.

An afterthought: That is also why, when you have outsourced your development work and application consulting, you will need to get yourself a Miles-and-More card and learn at least one exotic foreign language.

SAP S_TCODE

Question: Is there a way to insure that the values in S_TCODE are only the tcodes assigned to the role thru the menu tree? We are try to prohibit ranges and the value of * in the S_TCODE object.

Thanks,

Mark

Answer:
You can have a look through table AGR_TCODES, and look for * values. That's the way I usually do it

Answer:
This would have to be a manual process. Analyze the data under AGR_TCODES vs AGR_1251 S_TCODE,TCD.

Answer:
I beleive there is a report in SAP that gives you this the report is PFCG_AGRS_WITH_MANUAL_S_TCODE, you cannot prevent them for doing it just after the fact detec

Question: Hello,

I have started to look at the use of S_TABU_LIN to restrict table record maintenance on BUKRS , KOKRS; WERKS and EKORG. What I want is to be able to set these restricitons as organizational levels as we are using template roles which by inheritance will be used at about 200 different companies.

Has anyone tried this ?

Is it possible or not ?



Answer:
You can create orglevels using the report SAP provides (PFCG_ORGFIELD_CREATE) . Note BUKRS already is an orglevel . SO test it before you go too far and read the results of the test results closely before you implement.

Answer:
This is not possible. It would mean 2 fields as OrgLevel:
First defining the field OrgCriteria definition as organzational level, and supplementary to that the needed values.
Both fields are in the object S_TABU_LIN. How would the system know which value belongs to whicht OrgCrit?

Question: Hi All

we are working on 4.7x1.10 SR1.

when we tried to add some transactions in Authorization object S_TCODE

it is showing us only in display mode rather it should be in change mode.

Is there any parameter that we need to add in 4.7 or what is the procedure to make S_TCODE as change mode?

pls help me out ........thanks in advance


Answer:
If you are using PFCG then the tcode needs to be added to the MENU not the authorization. If you are in SU02, Profiles created from PFCG cannot be changed in SU02

Question: Hi Guru's

How to allow user to see only Area Menu and SAp Menu but not the list of transactions asssigned to his role. I tried in 2 ways..

1. I blocked the User menu , which also blocks Area menu.
2. Deleted transaction code list from Menu of User role and generated the profile. So now in usermenu i can not see any transactions. It is worked.
Here problem is S_tcode is in Display mode only, so we can not add any additional transactions in future. I do not like to uncheck transaction codes in SE97.

Apart from these, is their any other ways to solve this.

Thanks in advance

Pranu

Answer:
Pranu

User menu vs Sap menu and restricting views of transaction ahve been discussed oin ths forum many times before. Usually in those discussions the question is asked "Why do you not want users to see transactions they are allowed to use? It does not add to security, so what is the purpose of hiding access?"

The display only status of S_TCODE has been disucssed a lot recently too. I'm not gonig to answer your question here, because the S_TCODE issue and the menu issue could both be answered by you using the search facility.
_________________
Sandi
~~~~

Apparently Father Christmas, the Easter Bunny, the Tooth Fairy and Star Wars aren't real


Answer:
"Why do you not want users to see transactions they are allowed to use? It does not add to security, so what is the purpose of hiding access?"

If you cannot trust your users enough to let them see the transactions they have access to, then your design should be changed to only give them the access that your risk profiling permits.
Security by obscurity is not proper security

;;