Impersonation from server-side script

[Shan C]

I am trying to create a custom server-side step config to add groups/roles to an existing user created part of previous steps or reusable tests, and it seems the executing user should have admin or test designer permissions to do groups/roles to users.

So, I did like below, and it is not working or group/roles getting added. Is there any additional points to consider here or missing anything? Appreciate any inputs.

//Get current user
var current_user = gs.getUserID();

//Impersonate user with permissions to alter user record
gs.getSession().impersonate(inputs.admin_or_test_designer_user);

//My Groups addition code

//Impersonate back to original condition
gs.getSession().impersonate(current_user);

[Ankur Bawiskar]

@Shan C 

is this for ATF?

if yes then why to do impersonation in script?

[Shan C]

@Ankur Bawiskar Like I mentioned, the current user should have required permissions to add groups/roles to the user. So, trying to impersonate as an admin user, add the group/roles, and continue to the next step. Hope it helps to understand.

[Tanushree Maiti]

Hi @Shan C ,

I don't think relying on user impersonation in ATF is a good testing practice.

While ATF supports impersonation, it can introduce inconsistent behavior because the test execution context differs from a real user session.

Depending on the scenario, factors such as session context, elevated privileges, or server-side execution can affect the outcome, making tests less reliable.

Instead of depending on impersonation, I prefer these approaches:

• Use the "Create a User" test step. Create a dedicated test user with only the required roles. This makes tests more predictable and avoids issues caused by changes to existing users. ATF also cleans up the test data when the test completes.
• Use Run Server Side Script for ACL validation or privilege checks that are better suited to server-side execution rather than client session behavior.
• Run ATF only in development or test instances. Avoid executing automated tests in production.
• Keep test data modular. Separate test data creation from validation so tests don't fail because of hard-coded records or deleted data.