Flavor changing without P

[Former Member]

Hi!

I wanted to ask whether there is a way of separating changing flavors manually and automatically via script, so that they would be  2 authorization objects? Otherwise the script changeFlavors kind of loses its meaning - if user can still open "P" and choose whatever flavor he wants, including the original one, which client would like make unavailable for the end user!

The functionality of this is for users with many functions, like managers, for whom to place all his daily work on one dashboard would look crowded and insane - that's why we want to group his functions in "blocks" - which on the click opens new dashboard with further functions, but in order to do that now, we have to give authorization for user to change flavors - which means he is available to change flavors manually, and that is not how the client would like it to see.

Thanks!

[tamas_hoznek · Accepted solution]

Diana,

It is true that in certain scenarios it would be desired to switch flavor by a script without the user actually being allowed to manually select a flavor via the Personas toolbar. However, the basic premise of Personas scripting is that no action can be perfomed by the script that the user otherwise couldn't do. This will not change.

So it sounds like there should be some authorization value which doesn't show the toolbar even though the flavor switching authorization is granted. Currently there is no such setting. Talk is going on about a solution for this situation but no decision has been made how / if / when will this be possible.

In the meantime, you could do the following:

Copy the personas service to a new name (like z_personas or something). For this service, you can specify the additional parameter sap-personas-hidden with the value X. Then you would provide the Personas URL to your end users for this service instead of the standard. You should certainly grant them the authorization to 'manage flavor'.

This will result in the scripted switch flavor action working but there would be no Personas P shown to these users.

Of course nothing stops the user from changing the service name in the URL to the standard personas and thereby getting the Personas toolbar, but remember that Personas is not a security tool, so it shouldn't be used to control access to the system. A savvy user could manipulate the URL anyway and do certain things you wouldn't want them to do...

[Former Member · Accepted solution]

Tamas, thank you for your help, but I need a little further explanation. so I should copy the ICF service "Personas" and then in GUI configuration specify parameter and value you mentioned and then just change the link provided to users, correct?

But the first I got stuck at copying the service. If I try to copy it under bc where it belong I get alert that service already exists, elsewhere i get this window:

I searched for guides, but found only about creating services. as this is my first attempt to copy the service I would appreciate some more detailed help, please

Diana

[tamas_hoznek · Accepted solution]

You could specify a Z package that's used for other Personas-related development objects, or for testing just use 'Local object'. Be aware that local objects are not transportable so this is really only for testing the concept in that one system.

if you don't know what Z package you should use, ask the ABAP development team.

You could certainly also create a new service manually and enter everything as it is in the standard personas service then make the additional entry in the GUI Configuration settings