Changes not getting reflected in back end system due to Authorization check

[Former Member]

Hi All,

We have a situation that a person could do all the changes needed for another person from portal but the same is not getting reflected in Back end R3 system. For example X is the manager of Y, in this case X could change Y's mail id, exit date, etc., from Portal without any issue but it is not getting reflected in the back end R3 system. The changed data is not being saved in back end. Can any one help me with this on what needs to be done. Thanks in advance !

[Former Member]

Hi Arunkumar

if you can login in the backend with manager user details, try to repeat the activity and see if it works (if it doesn't, just run SU53 after the changes), otherwise trace with st01 (authorization flag only) the linked manager backend user and check the return codes

Let me know if you need further details

cheers

a

[Former Member]

Hi Andrea,

Thanks for the reply.

The problem here is that we are not getting any errors while doing the changes, it is being done successfully. The problem is that it is not getting updated in the back end system. So even if I run SU53 I cannot find any missing authorization object. It seems that when any change is being made it checks for AO02 relationship. So is it possible to restrict AO02 relationship by any authorization object ? Kindly let me know how this can be done.

[sairameshc]

Hi Arun,

Please check with BASIS team or Portal admin team. Seems Connector settings issue or Synchronization issue(jobs).

[Former Member]

Hi Ramesh,

Thanks for your help ! Will the portal roles also be responsible for this ? As another person who is having the same authorization in back end is able to do this successfully but that person is having a particular portal role in addition. So will this portal role be the reason for this AO02 relationship check ?

[sairameshc]

In portal also user should have the proper access(User admin rights) and also check the communication user access ABAP and UME config, and also check the is UME is source system or not?

[Former Member]

Hi All,

Regarding this we found that this whole thing works when the user's user group is changed to Dialog from CPIC_USER.

Even if we change the user group the authorization will be the same, so I don't understand why there is no restriction when the user group is Dialog.

Can any one comment on this please ?

Thanks in advance.

[Former Member]

Hi Arun

Ive been busy lately with sps upgrade on my client but i was keeping an eye on this thread

I believe the user group is rarely used, but for some things it's linked to authorization process

Real question is why you assigned that group to your user and last but not least are you really talking about usergroup or usertype?

let me know

cheers

a

[Former Member]

Hi Andrea,

Thanks ! I tried after changing both User group as well as user type which you can find in logon data tab in SU01.

Kindly let me know why this user group change is restricting data getting saved in back end.

[Former Member]

It is probably something which is hardcoded?

[Former Member]

Hi All,

It is just the user type which is making the difference, the user group change is not having any effect in this issue.

Can any one tell me the difference between User group and user type ? as this is what is making the difference. Thanks !

[Former Member]

Hi Arun

i believe Julius von dem Bussche meant that's how sap works

the user group is again linked to authorization process but it's designed to distinguish an user administrator from another one (in case you need that)

the user type is intended to describe what the owner will do (dialog is for an interactive user, system for technical processes and so on, check with F1 on the field if you need more info) and it's completely linked to authorisations as well because (for example) background grants (as the related workflows) are different than the online one

I hope this help

Good luck

a