Hi @Matthew,

The privilege allows the authenticated user the possibility to impersonate (run as) some other user. This is a very high privilege and should be used with care.

Hope this helps!

Hi @Himasha Kapugeekiyanage - should have said have read the help. More wondering how to access it. Currently we are able to access log-in details but going forward this may not be possible so need a way to see what the user can see.

HI Matthew,

As per the F1 documentation 

IMPERSONATE USER  :  Allow the authenticated user the possibility to impersonate (run as) some other user. This is a very high privilege and should be used with care.

There are inbuilt permission sets which has been granted with this privilege. 

Eg:  BA_BARS_ADMIN

Here is a use case which might help you understand the usage: (This explains why the permission FND_ADMIN has been granted with the IMPERSONATE USE system privilege) 

The reason why the FND_ADMIN permission set contains the IMPERSONATE USER privilage is so that the IFS System Administrator who is granted this permission set is allowed to perform some framework functionality that they would normally not be allowed to do if they were not granted this system privilage.

For example, one place the IMPERSONATE USER privilage is used is with backgound jobs.  In a situation where an IFS System Administrator wants to run background jobs which have gone to an error or warning state, they must have the IMPERSONATE USER privilege to run the background job as the posted user.

We have seen that application groups also have used this functionality.
 

Hope this helps. 

Thanks,

Kasun

So there are two elements to this - permission sets and profiles.

In order to test out permissions, I simply suggest just having a test user which you can use and change the permissions of as and when you need to. (To copy an existing user’s permission sets)

This way you can copy the users permissions to it and log into the system and have a look to check their permission sets give the correct level of access

The other side is the profile side - You can either copy the users profile to the test user profile or change the profile to the current logged in user (Tools → Options → User Profile Tab → Edit Personal Profiles → Select User and Read Only) to check if they have changed a setting in their profile

Alternatively just maintain another database and then change the user password in that environment and log into that one and test using their account

Impersonate User won’t be useful for what you are trying to do - this is mainly used to post background jobs as a different user or to perform actions as a different user (such as approval routings etc) - impersonate user will not let you log in as that user to “see what the user can see”

But if you still wanted to understand how to use the IMPERSONATE USER privilege, here is some code provided by @dsj in another thread.

begin 
 Dbms_Output.put_line('Session user: ' || Fnd_Session_API.Get_Fnd_User);
 IFSAPP.Fnd_Session_API.Impersonate_Fnd_User('NEW_USER_ID');
 Dbms_Output.put_line('Session user changed to: ' || Fnd_Session_API.Get_Fnd_User);
 -- run the job 
 IFSAPP.Fnd_Session_API.Reset_Fnd_User;
 Dbms_Output.put_line('Session user reset to: ' || Fnd_Session_API.Get_Fnd_User);
end;

@CallumW is 100% correct.  Impersonate User system privilege won’t give you what you are looking for, and can create a security and audit nightmare.

Nick