S_TABU_NAM not reflecting in USOBX or USOBT

[Former Member]

Hi,

we have implemented the note 1481950, 1522661 and 1516880 (for the new auth. concept with S_TABU_NAM)

Now system is checking for s_tabu_nam when the check on s_tabu_dis fails.This works fine.

But the problem is the object s_tabu_nam is not appearing in tables USOBX or USOBT

I have checked the SAP note 1500054 and the note says "Since this authorization concept is considered to be an

additional option, SAP does not yet provide a comprehensive set of authorization concept authorization default values for this object"

Is this the reason why the object s_tabu_nam is missing in USOBT?

Also why is this object missing in USOBX?

I have checked the function module VIEW_AUTHORITY_CHECK and the authority check statement for S_TABU_NAM is present in this function module.So should S_TABU_NAM be reflecting atleast in USOBX for SE16?

i will be very thankful if somebody can explain this.

thanks

Issac

[Former Member]

No, the objects do not have to be in any USOB* table - the checks are still performed if they are in the coding and that code is executed.

Objects from the Basis and HR modules are anyway always performed. You also cannot turn them off either.

Cheers,

Julius

[Former Member]

Hi and thanks for the input!

Since the check is performed in the coding,i was expecting an entry atleast in USOBX with check flag "X"

And yes,i understand that i cannot turn off basis and HR checks.

I will assign ponits to you and close this thread soon but i just want to keep it open for a couple of days just to hear if anybody else has any information about if SU22 will be updated by SAP for relevant tcodes with S_TABU_NAM

[Former Member]

I guess at some stage they will have to update it, latest when they want to propose S_TABU_NAM for parameter transactions.

Making an entry for S_TABU_NAM now already in SU22 for SM30 etc would have very irritating side effects as it would suddenly popup all over the place... despite being optional.

Removing the S_TABU_DIS check in SE93 (table TSTCA) for SM30 would be a catastrophe for the parameter transactions as they rely on the core transaction proposing the object if they have not proposed it themselves (which is exactly the case most of the time).

So... there are lots of very smart people scratching their heads about how to make an optional and downward compatible concept intuitive for those who want to use it...

While we are waiting, perhaps you want to take a shot at answering that question?

I have some ideas, but would be interested to hear yours and others.

Cheers,

Julius

[Former Member]

Hi Julius

No, the objects do not have to be in any USOB* table - the checks are still performed if they are in the coding and that code is executed.

We're still waiting for S_TABU_NAM in our quaint 4.6C

I sort of understand the idea - this object (almost) replaces/compliments S_TABU_DIS to give a greater degree of control at table level so I think I can see the reason why it's not proposed. Add it and all hell breaks loose/leave it for the auths peeps and this can be used selectively where a problem is found that needs a little more 'tweeking'.

drums fingers on laptop...

Cheers

David

[Former Member]

It is only "backported" to 7.00. You cannot use it in 46C (at all).

Even in 7.00 + systems it enables niche authorizations for new requirements or previously unclassified data access (particularly if your have neglected &NC& (=Not Classified).

In older releases the system defaulted views to this value, so it was interpreted as either "not critical" (are we not all?) or exclusive. Both of these concept when used by everyone are defunct.

The advantage of S_TABU_NAM is that you don't really need a concept and don't have to talk about it with the data owners. They simply need to deliver a list of tables with activities for them and you are set to go (until you reach the limit of 150 (auths) x 1350 (length) /40 (table names) x 312 (profiles, with all consequences for role build)..

The advantage is that you can speak the same language and use DDIC object name ranges.

The disadvantage is that you cannot use object name ranges for types of tables (unless you use the delivery classes of the tables...).

Whether all of this is a good thing or a bad thing I am still not sure, but it cannot be much worse than S_TABU_DIS in the wild so I have a lot of faith in it.

Discussion here on SDN will no doubt also help.

For "bugs" please use www.service.sap.com

Cheers,

Julius

[mvoros]

>

> It is only "backported" to 7.00. You cannot use it in 46C (at all).

Has anyone tried to backport it into older release? 4.6C is too old and SAP don't bother to do backport for unsupported releases. They want you to upgrade I doubt that code has changed a lot since 4.6C. Hence I assume that it shouldn't be that hard.

Cheers

[Former Member]

There are many other locations where S_TABU_DIS is used (without calling the central function) and SE16 is one of them.

You will also be transporting many other changes to the function module back to 46C and will need the auth object and field as well.

I would say that it is only for the very brave...

Cheers,

Julius

[Former Member]

Julius - as i have not heard anything regarding SAP updating the SU22 with S_TABU_NAM for relevant tcodes,i am closing this thread.By the way SAP Note 1500054 explains the SAP approach for updating the SU24 for parameter transactions with S_TABU_NAM

I have had a quick check in the table TSTCP by giving the following range for parameters and it is a lot of transactions

asterisk() SE16 asterisk()

asterisk() SM30 asterisk()

asterisk() SM31 asterisk()

asterisk() SM34 asterisk()

asterisk() SE17 asterisk()

I am not sure how much time consuming is it to follow the note 1500054 and update these tcodes.It may be good to wait till SU22 is updated by SAP so that all the role changes related to S_TABU_NAM can be done in one go.

You may have better ideas?

BR- Issac

[Former Member]

I like your thinking. Perhaps we can still tweak it a bit...

1) You must consider table TSTCA entries for S_TABU_DIS. See (this is also NOT backported to 46c!!)

2) Find all the parameter tcodes WITHOUT an S_TABU_DIS proposal of their own and find the roles with them in the menu with "maintained" status auths. &NC& will be a pain-ponit here and you will probably end up with all users having it somehow assigned.

3) In SU24 you can also use the auth object itself as the entry ponits (2nd tab) and add it as check to all those tcodes which did not have their own indicator (to be able to overwrite the generic core ones).

4) Then add the S_TABU_NAM values as proposals to replace them (here you might as well go directly for the "name" and not the list, because you already know the parameter tcode name.

In some ways this might make sense to do before SAP delivers the SU22 data, and then you can use SU25 to verify them.

It really depends on your mood and not any best practice I can recommend yet...

Good luck and keep us posted how it goes.

Cheers,

Julius

[mvoros]

Running 4.6C is for very brave

[Former Member]

I think Julius should prove a point and devote at least three weeks to this for my client at no cost to prove just how hideous the task is and how to overcome it.

As far as I can remember, he still has at least one hat to eat?

[Former Member]

Important here is that USOBT* has an entry for the parameter tcodes. I cannot see SAP removing S_TABU_DIS from SM30 and toasting most roles currently in existence...

I think a modification for 46C will be less intrusive than a downported transport... but you will eat your hat on other tcodes such as se16 screen generators, se16n is there as well, gtdis, wusltabl, se17_old, and all their sa38 reports.

What about function module rfc_read_table and "uncertifiable" partner products which are not API and package conform, which will quite likely still be in use otherwise they might have upgraded already?

I have often been tempted to post a "black list" on SDN...

Hornet's nest to backport...

--> upgrade --> stable API's is the way to go.

Cheers,

Julius

Edited by: Julius Bussche on Feb 25, 2011 12:31 AM

[Former Member]

It may be good to wait till SU22 is updated by SAP so that all the role changes related to S_TABU_NAM can be done in one go.

This is used in "expert mode" and SAP seems to have chosen the wording carefully.

Unless you are a "gadget guy" and want to dig really deep into this, I would wait for SAP to sort it out, upgrade and wait for someone else to debug the migration tools.

In the interim as of 7.00 you can use it for new roles once available, to start with while considering how many roles you have which the user is already assigned to.

Cheers,

Julius