Authorization for only add records to a Z-table (not to delete)

[Former Member]

Hello friends,

Is it possible to create an authorization object that would allow only adding new records, and change to existing records of a Z-table, but not allow any deletion of records ? Kindly show me how.

Thanks,

- Chetan

[Former Member]

>

> Hello friends,
> 
> Is it possible to create an authorization object that would allow only adding new records, and change to existing records of a Z-table, but not allow any deletion of records ?  Kindly show me how.
> 
> Thanks,
> - Chetan

Yes, it is possible. Associate the Z-table with an authorization group. Set the activities for S_TABU_DIS for the new auth group to 1, 2, 3, 4, do not include 6.

[Former Member]

Edited: I thought you were refering to activities 01, 02 etc.

Edited by: Julius Bussche on Feb 24, 2010 6:47 PM

[Former Member]

Which type of table is this?

For a customizing Z-table I think you can do this as you can add a new custom field to it, with a custom field of course, and a custom flag to show that it exists.

Then promote that Z-field to an S_TABU_LIN org.level, and in the view which you create for the table you insert the flag indicator into the z-field without the user having an option to influence it while still in edit mode.

Then give the user only display authority for S_TABU_LIN. They can create new entries which will then have the org.level indicator, but will afterwards only be able to display them line-by-line.

Cheers,

Julius

[mvoros]

Another solution is to implement additional check in one of the events of table maintenance.

BTW does anybody know why S_TABU_DIS does not have activity 01?

Cheers

[Former Member]

> Another solution is to implement additional check in one of the events of table maintenance.

Yes, that was my thought as well, except of was to write the group for saved entry, after which S_TABU_LIN no longer permits the line-by-line '02'.

> BTW does anybody know why S_TABU_DIS does not have activity 01?

You could edit an exiting entry via the generated maintenance view, thereby creating or deleting it. Same thing, same activity.

The keys in the target system must by unique -> they will be overwritten.

If you want to read up about tables which only have key fields, or no key at all... then see the Funny Threads in the Coffee Corner forum...:-)

As this is a Z-table and we dont know the delivery class and type - we are just guessing...

The original poster needs to provide more infos.

Cheers,

Julius

[mvoros]

>

> The keys in the target system must by unique -> they will be overwritten.

I don't get this. If there is already record with same key then it should not overwrite record when I have authorization just to create records. On the other side now I can image that user with activity 01 only could check if the record exists without display authorization.

Cheers

[Former Member]

>

> Another solution is to implement additional check in one of the events of table maintenance.

>

> BTW does anybody know why S_TABU_DIS does not have activity 01?

>

> Cheers

It shows it when you hit F7 under S_TABU_DIS activity. Does that count?

Edited by: John Navarro on Feb 25, 2010 1:21 AM

[mvoros]

Hi,

if you go to SU21 then you can see allowed activities there (button "Permitted activities"). I don't understand where you hit F7 but I guess that it shows you all possible values for this field. In case of ACTVT you can restrict activities for each authorization object.

Cheers

[arpan_paik]

Me too please....

S_TABU_DIS is having permitted activity 02, 03, BD only

No 01, 06 or any otherthing.....

Here the issue is that admin want a user to edit existing data, append new data but not delete a data....As user will be able to edit data so I assume that admin want to achive a situation that user won't be able to delete enire row.

I doubt whether that will be possible or not. Even if we impose authorization to S_TABU_LIN in that case also this won't be able.

However the requirement is vauge (yes it is) user can edit existing data but not the entire row does not make any sense.

Arpan

[Former Member]

> It shows it when you hit F7 under S_TABU_DIS activity. Does that count?

No. It doesn't count if the code is only checking "actions" for '02' and '03'.

Cheers,

Julius

[Former Member]

> If there is already record with same key then it should not overwrite record when I have authorization just to create records.

But then one would expect such a change to be transported. Perhaps that is the reason why '02' is "changes of all sorts".

Cheers,

Julius

[Former Member]

FYI: This feature is disabled in release 7.01 and I reported all the '01' activities in SU24 which are derived from SE93 setting authorizations which were created using this technique, and force you to grant * authorizations.

Cheers,

Julius