Authorization object fotr tables

[Former Member]

hi all,

i have a situation where we have developed a few custom tables.

We need to give authorization to some users to be able to change the existing records only. and to add and delete records to users ......

Can some one help.

Regards,

Tarun Bahal

[Former Member]

Dear,

first of all i din't get you properly.

if you want to give authorization for few tables[ for modifying] to Users then create authorization groups for respective tables and maintain them in the role Under the object S_TABU_DIS with activity 01,02.

[Former Member]

let me explainwe have a table 'A'. with 5 records

Some users shud have the authorization where they can change the existings records but not delete of add Records.

Others can change add and delete records

How do we implement this?

Regards,

Tarun Bahal

[jurjen_heeck]

> Some users shud have the authorization where they can change the existings records but not delete of add Records.

>

> Others can change add and delete records

>

> How do we implement this?

I'd suggest to write a custom maintenance program for this table and build in the proper authority checks. Have a look at existing programs where the authority field ACTVT is used in the statement AUTHORITY_CHECK. That should give you some ideas.

Jurjen

[Former Member]

There are many custom tables for which we need to implement this functionality..... at the moment we are using sm30 and was hoping to find an authorization object that we cud attach to the maintenence view in sm30.

can i create a custom authorization object to resolve this issue. if yes then how??

if we start writing custom programs for these tables.............. then that wud become a project in itself

Regards,

Tarun Bahal

[jurjen_heeck]

> There are many custom tables for which we need to implement this functionality..... at the moment we are using sm30 and was hoping to find an authorization object that we cud attach to the maintenence view in sm30.

>

> can i create a custom authorization object to resolve this issue. if yes then how??

That would imply changeing standard SAP software. Not a favourable road to take.

> if we start writing custom programs for these tables.............. then that wud become a project in itself

It would, yes. How about starting that project with a copy of SM30's programs?

You cannot expect from the system to protect your data for you automatically in every imaginable way...

[Former Member]

thankx Sabs,

We have already tried the obj S_Tabu_dis. all that we want is to seperate the authrorization for change and ADD + DELETE.

Regards,

Tarun

[Former Member]

>

> thankx Sabs,
> 
> We have already tried the obj S_Tabu_dis. all that we want is to seperate the authrorization for change and ADD + DELETE.
> 
> Regards,
> 
> Tarun

You can't do that with tables.

Your developers should create proper maintainence dialogs for the tables.

An alternative would be to copy SM30 and put in additional logic which validate the ability to add or delete a row. It would still be a bodge, the proper solution is to do what Jurjen recommended

[Former Member]

i guess will start with creating z auth objects and then creating customs programs

[Former Member]

If you have (consistently) re-usable fields for the authorizations in the roles or custom fields, then you can take a look into object S_TABU_LIN for a "line by line" authority-check at the table level.

Perhaps if you could describe what these tables do and why / where (which system in the landscape) they need to be maintained, then a more detailed answer is possible....

Cheers,

Julius

[Former Member]

Hi Julius,

I also thought about S_TABU_LIN but I don't think it separates the add/delete functionality. It's not something I have looked into too far though & if the original poster really, really wanted to maintain all those tables directly, S_TABU_LIN could give a fair degree of granular control.

Cheers

Alex

[Former Member]

Hi Alex,

I already made a note to try this out, with 2 S_TABU_LIN fields in the custom table... (one of which is the activity "LIN")....

So it does not have to be in the auth object ... perhaps

Though in this case I think that custom auth objects would come into play, and where avoidable I try to do so (exception: composite auth objects...).

Cheers,

Julius

[Former Member]

Yeah.. we have tried s_yabu_lin as well............ it does not sepersate the funcunality for change and ADD+Delete. all it does is restrict the access to the content of a table.

so only way out is custom auth object.

i ll be doing that today and keep u gys posted and ask for more help if required.

Regards,

Tarun

[former_member248712]

I was just watching this thread.

I am not sure how S_TABU_LIN works, since my understanding is that the existence of organizational criteria is a prerequisite for the use of this authorization object. So HR should be implemented or atleast an Org plan should be in place.

Tarun, keep us posted on what solution you used.

AB

[Former Member]

Hi AB,

I have not got around to testing this yet, but it is just a custom table - there was to my understanding no mention of HR (yet)...

If a custom table has two (custom) fields which are S_TABU_LIN activated, and one of them is activity related (an abuse of the org intention of S_TABU_LIN for activity type "orgs"), then a custom program would certainly be able to determine what the user can do to the fields.

What I wanted to test was whether the standard table maintenance generator will make this possible with 2 S_TABU_LIN fields for the same table.

My guess is that it can be done if the user is first presented with the option of choosing display or maintenance (change) mode.

I will try it next week on a sandbox. Try it out yourself, then we can compare tricks

Cheers,

Julius

[Former Member]

I have created a custom Authoprisation Object ...........

with 3 possible activities.

Change

Add

Display

and created a custom Program where i did authority check at various points for these 3 activities.

Regards,

Tarun Bahal

[Former Member]

CAN I give Ponts to myself

[Former Member]

>

> CAN I give Ponts to myself  
> 

@ Tarun: No. You should give points to Siddhesh Ghag....

... and you should read [the rules|https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/rulesofEngagement] about cross-posting as well before posting any further.

@ Arjun: I will get back to you still on the 2 s_tabu_lin fields for the same table.

Cheers,

Julius

[Former Member]

i was kidding as far as points are concered .. thats why the smily

and dont know what u mean by cross posting??

[Former Member]

and thankx for reminding me about siddesh ghag

[Former Member]

> i was kidding as far as points are concered .. thats why the smily

Ahh.. sorry, I am a bit slow then

Please read "the rules" above anyway (just incase).

Cheers,

Julius

[Former Member]

If by cross posting u mean posting the same issue in various forums.............. then this is as much a basis issue as an ABAP issue.....

thats why this was posted in 2 forums.

[Former Member]

> then this is as much a basis issue as an ABAP issue.....

Maybe... but this is the "security forum". The forum categories and names have to have some structure, so we have this one.

If everybody cross-posted to all possible forums then SDN would be a mess. Please rather resist the temptation to cross-post, as this makes it easier for knowledgable people to visit the most appropriate forums for their areas of expertise and answer the quality questions.

Sometimes we are lenient, mostly we leave only one post (typically the first one), but it cannot be excluded that all are deleted when we see this is being abuse.

Please take this in a positive way, to help you using the forums.

Cheers,

Julius

[Former Member]

Julius,

With all the respect that i have for SDN, trust me, I treat this place as Bible and wud never wish for it to be abused in any ways.

Be rest assured that i wud never post irrelevant questions in any of the forums.

Regards,

Tarun

[Former Member]

Hi Tarun,

Thanks. I did not say that you misused anything. I just did not want to miss out on the opportunity to point out that cross-posting should be avoided as much as possible and that we do keep an eye on this.

I think we have flogged this horse dead now.

Cheers,

Julius

PS: But I will still try out the S_TABU_LIN option for 2 line-by-line fields - my first attempt did not work

[Former Member]

yeah.. and keep us posted on that..

[Former Member]

Hi Tarun,

In order to provide the access to the custom tables which has been developed, first you need to find out the authorisation group to which these tables belong -

1.Run Se16

2.Enter the table name as TDDAT

3.In the tablename field of the table TDDAT enter the custom table name and then Execute.

From the above steps, you will be able to find out the authorisation group.After that you will need to assign these values in the field "authorisation group" along with the desired activity in the authorisation object S_TABU_DIS.

All users who has access to the roles with the above auth. obj and its values will be able to add/modify/delete record of the desired table.

Note: It is not recommended to have users with change access to tables in systems other than the development system.

Thanks,

Saby..