Keep users from deleting own attachments

[Former Member]

Our requirement from management is to allow no one to delete an attachment. We have found a way to keep anyone from deleting another users attachment, however, even though we have not granted them any authorization, they still are able to delete their own. We have checked note 49127 and looked at t-code SGOS, but don't see anything that appears to prohibit attachment deletes. We have removed S_OC_ROLE from all roles, but when we did an authorization trace the authorizations were: S_OC_ROLE=ADMINISTRATOR and S_GOS_ATT= BOROBJTYPE=BSEG;ACTVT=06 (Delete) however, in the the only role the user has S_OC_ROLE does not exist and S_GOS_ATT = BOROBJTYPE= BSEG;ACTVT=02 (Change). Where is the authorization coming from?

[martin_voros]

Hi,

are you on correct SP level? Check OSS note 1293080. If you are on correct level then use without authorization to object S_GOS_ATT for activity 06 shouldn't be able to delete attachments.

Cheers

[arpan_paik]

 in the the only role the user has S_OC_ROLE does not exist and S_GOS_ATT = BOROBJTYPE= BSEG;ACTVT=02 (Change). Where is the authorization coming from 

Check the below points

1. In trace return code is 0?

2. If yes to 1st question then user must have this authorization through a role.

3. As you said that user has only 1 role then check if the user is having any manually added profile in profile tab

4. If yes, then compare user buffer then simulate test again

If all the above option fail then service.sap.com might be the place where you need to go

Reg,

Arpan

[Former Member]

Leo,

We use the authorisation object S_WFAR_OBJ with relevant activity (02 for change, 03 for display, 06 for delete) for managing our attachments - don't know if that will help you.

[ashley_kenealy]

Hi Leo,

I suggest you check out transaction SE93 (Maintain Transaction Codes), you will probably find that your troublesome transaction (SGOS) is linked to transaction SM30 (with an assigned maintainence view). Your user has probably inherited authorisations from SM30.

Regards

Ashley