Skip to Content

Restrict access to change parameters in SU3

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

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

5 Answers

  • avatar image
    Former Member
    Sep 25, 2008 at 11:53 PM

    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

    Add comment
    10|10000 characters needed characters exceeded

  • Sep 25, 2008 at 07:54 PM

    > 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).

    Add comment
    10|10000 characters needed characters exceeded

    • 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.

  • Sep 26, 2008 at 01:30 PM

    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

    Add comment
    10|10000 characters needed characters exceeded

    • > 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.

  • Sep 26, 2008 at 01:51 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Sep 29, 2008 at 03:20 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded