Restrict access to change parameters in SU3

[krysta_osborn]

Hi!

I'm afraid I already know the answer, but I'm going to ask anyway.

Is there any way to prevent users from changing certain parameters in SU3 while allowing them to change others? I've looked for an auth object for parameters with no luck. I have a sneaking suspicion that the answer is to create a custom version of SU3 with the additional security we're after. Yuck.

I did see the option of setting the parameters as global in our CUA system, but I really don't want to get into the business of maintaining parameters for all users.

Thanks,

Krysta

[WolfgangJanzen]

> Is there any way to prevent users from changing certain parameters in SU3 while allowing them to change others?

Short answer: no (not in the standard).

There are variant transaction (SU1, SU2) - but they only "hide" entire sections (user parameters, etc.). So, it's an either-or thing.

Notice: user parameters should not be used for access control purposes - but only to memorize settings (in order to prefill input fields). An user can always modify the value of such prefilled input fields. If you want to prevent this, you have to define a variant for the effected transaction(s) and create a variant transaction for that transaction variant (sounds funny - but those terms are correct). Then, you have to ensure that your users are only authorized for that new variant transaction.

Sorry, but that's the only way (at least to my knowledge - but I'm keen to hear if someone else knows a better solution).

[former_member248712]

I would concur with Wolfgang. You may use variants to block access to change parameters.

I guess this request had a predecessor issue. May be we try resolve the core issue.

AB.

[Former Member]

Which parameters are these which you want to the users to be able to set and possibly change (or re-set...) themselves?

There are a few which are set by the applications when used which use GET/SET parameters and gives the user the opportunity to set it themselves there, without needing SU3 & Co.

If it is only a small handfull and one of those for which you can find a function in the business application for the user to set it there, then it might work via that route.

Worste case, give then a simple little application to delete a selection of the PIDs you do want them to maintain, and then use the business application again to re-set it to what they want.

Cheers,

Julius

Edited by: Julius Bussche on Sep 26, 2008 1:55 AM

[krysta_osborn]

The problem is that we did what everyone says not to do. We based authorization on a parameter. So it's hard (obviously!) to ensure it's set correctly for everyone and to keep people out of there.

The parameter is EFB, function authorization for buyers. We have it set so that one group of users can only view PO prices and another group of users can change them. So ideally we'd prevent users from changing that parameter while letting them change the rest.

Ironically, the system documenation says to do exactly what we did. Of course, that's not a good excuse because we knew the risks when we decided to use that functionality.

Thanks for your input everyone! It'll help when I talk to the business about what we can do.

Regards,

Krysta

[WolfgangJanzen]

> Ironically, the system documenation says to do exactly what we did. Of course, that's not a good excuse because we knew the risks when we decided to use that functionality.

Can you provide a reference to this?

I'd like to find out who is the author of this documentation (SAP internally) - I think it need to be revised.

[krysta_osborn]

From Performance Assistant on the IMG activity Define Function Authorizations for Buyer:

Define Function Authorizations for Buyers

In this step, you can define certain Purchasing authorizations for one or more users.

Example

You can determine whether a certain user can display conditions.

Activities

1. Define the function authorizations according to your requirements.

Specify the key and the description of the function authorization.

On the detailed data screen, select the authorizations for functions that can be carried out by the user.

2. Enter the desired key as a parameter under the parameter ID EFB in the user master.

Note

If the user master does not include this parameter, the user has authorization for all functions.

[Former Member]

I agree with the "no" answers. We had the same issue with SU3 and wanted to restrict them from changing their names. We ended up asking a developer to write a variant that restricted the Address tab, a good developer should be able to do the same with the parameters tab.

-John N.

[zoltan2_kocsis]

Hi!

Maybe this reply is a bit late (only 15 years :D), but I'm currently in this problem and the solution for us is to use the Transaction code SU0 instead of SU3.

Maybe this will help others in the future.

Best regards,

Zoltan

[krysta_osborn]

Hi Zoltan!

Thanks for your suggestion even if it is 15 years later. 🙂

Unfortunately, we need users to be able to update some parameters but not others. Right now, I just give dirty looks if I bust someone updating the EFB parameter for purchasing.

Krysta