su3-display access

[Former Member]

hi all,

i want SU3 only in display.

in which authorization object we can do this.

<removed_by_moderator>

Regards,

Suganya.R

Edited by: Julius Bussche on Jun 5, 2008 12:57 PM

[Bernhard_SAP]

Hi unfortunately ther eis no check for display/maintain in SU3....

So if a user can execute SU3, he can maintain his own data which is not utreated as critical. Without modification it is not possible.....

Please decide to create your own transaction variant with fields set to 'non modifiyble' (SHD0) or check if SU0,Su1or SU2 meet your demand better....

b.rgds, Bernhard

[JPReyes]

If its urgent you should have called a consultant, this is a discussion forum and we don't work for you.

Regards

Juan

[Former Member]

you can use SU01D. Then you have only display function (but more tabs available than in su3)

[Former Member]

Hello Suganya

Object is S_USER_GRP. but before you need to change the status of this this object to CHECK/MAINTAIN in Su24 for transaction SU3. and in the role select Activity 03.

[Bernhard_SAP]

Hi,

did you really test your suggestion?

there is a check in susr_user_maint_with_dialog if SU3 should be started or SU01. I found no check for s_user_grp in the coding until the start of su3-surface....

b.rgds, Bernhard

[Former Member]

Hi,

I am not too sure what the original post is about......however here is the over view - from experience - on SU3

SU3 is used to maintiain Users Own Data-- however the EMAIL cannot be maintained! ( which is thru LDAP or SU01)

The main purpose of SU3 is that the user can maintain own PERSONAL data, not personel /official

so where is the question of changing meanng changing another users data ??

Menu path is-->system->user profile->owndata

Thanks

G

Edited by: george G on Jun 5, 2008 4:42 PM

[Former Member]

The purpose of S_USER_GRP is to group the users for admin purposes, unless you are accessing yourself (SU3). Granting any access to a user for their own data purposes which at the same time required access to the whole group, would be an incorrect use of the wrong authorzation object.

Perhaps an object S_USER_USR would be the one to look for here (except it does not exist). I guess that is why Bernard suggested SHD0 to change the screen or SU0, SU2 etc to limit the available tabs.

[Frank_Buchholz]

SU0 maintain defaults only

SU1 maintain adress only

SU2 maintain parameters only

SU3 maintain address, defaults and parameters

If you want to further restrict these transactions you have to create transaction variants (= addidional transactions) or transaction standard variants (=modification of the original transactions) using transaction SHD0.

Using SHD0 you can turn input fields into display fields, hide fields or set default values for input fields fon any transaction.

SU01D is not a valid alternative, because SU01D checks for an additional authorization for S_USER_GRP with activity 03 (display).

Kind regards

Frank

[OttoGold]

Hi Frank,

I am now playing with the user self-data access at the client, but the request is rather special. Although I could solve the "issue" with two transactions in the menu, they want something different.

One can go (via the main menu) > System > User Profile > Own Data which points to SU3. And their users know this path and so the manager insist on this way. Is there maybe a switch in PRGN/SSM which would let one switch that path to different transaction? (like SU2, SU0).

Thank you, Otto

[Former Member]

Perhaps SAP will re-consider the CALL SCREEN to be able to use a transaction variant. AFter the first call, the paramter ID tab is no longer visible if you block it in SHD0. But you can make 1 entry on the first call and save it as it calls the standard screen without respecting the screen variant of the user (transaction variant) of the calling tcode ( variant transaction).

I would class it as a very minor bug though, as anything using PIDs is a preference of the user. It should not be used for security control.

In reality it is however sometimes different and even very tempting to us PIDs to avoid roles and org. levels and complexity.

A better option is Personalization Keys. They can be assigned to users (SU01) or roles (PFCG) by admins, without a user being able to influence it as a "own data".

Downside: A few small coding corrections and a good ABAPer is required. Some customers dont have these or want any changes.

Cheers,

Julius