Automatically Update the User Parameter from Role personalization

[Former Member]

Hello all.

Its just nice to be here with all the fellow SAP security stars :). I am the Security consultant working on an implementation here in the UK and have a question on the user parameter.

We are trying to find a solution where when the role is updated with the personalization values (say like approval limit for Purchasing), the same needs to be automatically updated in the user parameter when the user is assigned that role. This would save a lot of time for us in editing the user parameter and changing the default into the actual authorized values.

Any suggestions/past experiences will be much appreciated.

Many Thanks

Raaj

[Former Member]

> This would save a lot of time for us in editing the user parameter and changing the default into the actual authorized values.

Sounds more like a short-cut not to change user-exits which use PIDs...

Cheers,

Julius

[Former Member]

.. Do you know what that user exit might be ? I am trying to search from my end. Or my question may be absurd that there are no user exits for PIDs. Pls .help

Thanks

Raaj

[Former Member]

I think the 3 of us (you, Bernhard and me) have 3 different understandings of what the question is?

Mine: You are already using parameter ID's (GET / SET parameters) in some code which is security relevant, "say like approval limit for Purchasing". However the user can (as a preference) influence the value of the PID, and you have now discovered personalization keys which is an admin task to set and want to use them.

=> Good.

Instead of changing the code to use personalization keys, you want to use some sort of synchronization between the keys and the PIDs.

=> Won't work.

Cheers,

Julius

Edited by: Julius Bussche on Sep 24, 2009 11:59 AM

[Former Member]

Thanks Julius & Bernard. I'm glad I have got a response for my queries. I will go with SPERS_MAINT as suggested by Bernard.

[Bernhard_SAP]

Hello Raaj,

the 3 types of personalization (user,role,system) are completely independent of each other. That means, default values maintained for one type (role in your case) are basically not copied to another type (here user).

The reason for that behaviour is a missing procedure for merging or accumulating default data for the same personalization key. Since it is possible to maintain default values for the same key but for different types the first question is whether data coming from different types should be accumulated or prioritized. If one decides to prioritize which type (user, role or system) should dominate? If one prefers the accumulation what should happen if default data of different types is contradictionary?

Therefore, the default data for all types is kept separated from each other, i. e. you have to maintain the personalization data in SPERS_MAINT explicitly for the requested users if you want to see them in SU01.

Since 7.00 (I think), this has been changed by implementation of the new switch ' Take into account with role changes" .

So the roles Personalistion value is reflected to the assigned users (but i am not sure about the priorisation, if for the user a different value has been maintained already. You should decide, which kind of maintenance you want to use...)

b.rgds, Bernhard

Edited by: Bernhard Hochreiter on Sep 24, 2009 11:51 AM

[former_member102418]

Hi Bernhard,

Any news on this topic? We're currently going through an SRM upgrade and realize that a particular personalization key is mandatory for a shopping cart to be accessible by users while pending for approval (BBP_WFL_SECURITY).

Unfortunately the documentation around this topic is really poor and we're trying to understand how the defferent levels of personalization key values work. You mention a prioritization depending on the level (user/role/system) but how does it work exactly? If I maintain different values for the same key depending on the level (value "X" at user level, value "Y" at role level and value "Z" at system level) which one will prevail and why?

Also if a value is maintained at system level via transaction PERSREG, this value doesn't seem to be transportable. Do you confirm?

Thanks in advance for your help.

Arnaud Marchand

SAP Security Expert @ Nestlé

[Bernhard_SAP]

Hi Arnaud,

using the transport button in persreg does not transport the settings of persreg????

Regarding the priorization I received some more information today. Well, there is no priorization. It depends which setting is used/selected by the application using the personalization object.

Depending on what they select and in which order the application does so, the values are reflected:

GET_DATA -> userspecific

GET_DATA_ROLE -> role specific

GET_DATA_SYSTEM -> system specific

I suggest to ask the guys responsible for the shopping cart functionality of how they verify the settings of BBP_WFL_SECURITY.

b.rgds, Bernhard

[former_member102418]

Thanks for your swift reply Bernhard!

Regarding the transport of settings, when you modify a value at system level, there is no transport button anymore, this button only appears when modifying the settings of a particular personalization key. Nothing else...

Regarding the check used, we use the standard shopping cart processes in SRM therefore I don't really know how to answer the question.

Arnaud.

[former_member102418]

By the way, we just tested the behaviour at assignment level. We set value "low" to the personalization key concerned in a role and after assigning role to the users, they automatically got the same value in their key though before the assignmend, value was set to "not defined"...