Testing interface that with different "loggedInUsers"

Hi nancyb0004 Yes you can do that for buttons you will have showWhen condition, check the loggedInUsser is part that of that group based on that you can display the buttons

Hello nancyb0004 

You would simply have to have a list of usernames in a constant and keep testing it in place of the loggedInUser(). Also you can add/remove yourself in the groups and try it out.

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.

Chris said:

I always recommend storing the loggedInUser() to a local variable, and using the local variable throughout the interface. 

This is what I do too.

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