Skip to Content

How to disable the default Flavor in Windows GUI when using Screen Personas 3

Hi Experts,

for some personas scenarios ist very important to forbid strictly that a user uses the default flavor.

At the moment we can set the default flavor in the role assignment and permit to use the flavor galery.


But if any user works with a non personas compatible SAP GUI for Windows (wrong patchlevel, wrong theme, set sap logon support bit) he gets nevertheless the default flavor and he can use it.

The goal would be disable a transaction (Flavor) for SAP GUI for Windows and to allow the same for the SICF Personas GUI

or

to disable the default Flavor even a user works with a non personas compatible SAP GUI for Windows.

Thx and best regards,

Thomas

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Apr 11, 2017 at 12:02 PM

    If you use a GUI (native, or web) that does not support Personas, or which allows Personas to be disabled (via Windows registry settings, for example), then you will get the standard SAPgui transactions. There's no way to avoid that.

    Why do you need to prevent users from using the standard transactions?

    Steve.

    Add comment
    10|10000 characters needed characters exceeded

    • Hi Steve,

      I'm glad (actually honored) that our minds work a little alike in situations like this :)

      Well, in SM04 we have the "Application Info" column, which makes a Personas session easily identifiable. So as long as we can establish a link between the current session and the corresponding row in the SM04 list, we should be golden. Trouble is, I didn't investigate yet what this takes. There may even be a better way to make this determination, I don't know... it would take some digging to figure out the easiest method.

      As far as the enhancement goes, I'm not concerned because if all else fails, there is always some implicit enhancement point available at the beginning of a transaction - but of course such a solution would have to be tailored to each selected transaction. Unless we tie this into some code that runs when any transaction is started (if such a thing exists).

      I may play around with this as time permits, because I believe the use case brought up by Thomas is a valid one. But if you have a better idea than this, I'm all ears :)