Testing interface that with different "loggedInUsers"

RE: Testing interface that with different "loggedInUsers"

Chris — Fri, 12 Apr 2024 17:56:36 GMT

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 🙂

RE: Testing interface that with different "loggedInUsers"

Mike Schmitt — Fri, 12 Apr 2024 17:10:11 GMT

[quote userid="83375" url="~/discussions/f/user-interface/34656/testing-interface-that-with-different-loggedinusers/133326"]however I want to be able to pass in user as logged in User [/quote]

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

RE: Testing interface that with different "loggedInUsers"

Mike Schmitt — Fri, 12 Apr 2024 17:09:29 GMT

[quote userid="2401" url="~/discussions/f/user-interface/34656/testing-interface-that-with-different-loggedinusers/133323"]I always recommend storing the loggedInUser() to a local variable, and using the local variable throughout the interface. [/quote]

This is what I do too.

RE: Testing interface that with different "loggedInUsers"

nancyb0004 — Fri, 12 Apr 2024 16:56:20 GMT

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.

RE: Testing interface that with different "loggedInUsers"

Chris — Fri, 12 Apr 2024 16:28:21 GMT

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()
  ),
  
  ...
)

RE: Testing interface that with different "loggedInUsers"

Konduru Chaitanya — Fri, 12 Apr 2024 15:03:13 GMT

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.

RE: Testing interface that with different "loggedInUsers"

Karumuru Abhishek — Fri, 12 Apr 2024 15:02:48 GMT

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