Testing interface that with different "loggedInUsers"

I always recommend storing the loggedInUser() to a local variable, and using the local variable throughout the interface.  This way, you can test all interface differences based on the user by temporarily updating the local!user variable in one place:

a!localVariables(
  /*local!user: loggedInUser(),*/
  local!user: touser("user.name"),
  
  ...
)

Further preferred on my end, by using something such as a constant on each server holding the name of your server, this code is safer by preventing unwanted functionality if you forget to change the commenting back prior to deployment (happens..):

a!localVariables(
  local!user: if(
    cons!SERVER_NAME="DEV",
    touser("user.name"),
    loggedInUser()
  ),
  
  ...
)

Thank you Chris - that is what I am doing, however I want to be able to pass in user as logged in User so I can test the interface through different scenarios without having to touch the code itself.

nancyb0004 said:

however I want to be able to pass in user as logged in User

local!currentUser: a!defaultValue(ri!overrideUsername, loggedinuser()),

As Mike notes, you can pass in an override as input, use this value as the user default when present and use loggedinuser() otherwise when empty. (I like the a!defaultValue approach, I do not use that function enough yet ).  All scenarios will involve a local variable for this however (which is good).

While this will work (and could have some cool uses in lower envs), I'm not as big of a fan on this approach since it essentially leaves a 'testing use only' logic in production (for best practices, production footprint should be minimal all around). 

I just prefer to adjust the code until I'm comfortable and allow UAT to iron these things out essentially.  My $.02

As Mike notes, you can pass in an override as input, use this value as the user default when present and use loggedinuser() otherwise when empty. (I like the a!defaultValue approach, I do not use that function enough yet ).  All scenarios will involve a local variable for this however (which is good).

While this will work (and could have some cool uses in lower envs), I'm not as big of a fan on this approach since it essentially leaves a 'testing use only' logic in production (for best practices, production footprint should be minimal all around). 

I just prefer to adjust the code until I'm comfortable and allow UAT to iron these things out essentially.  My $.02